Comment by Roboprog | Hacker News Reader

Comment by Roboprog | Hacker News Reader

Here's how it looks like it works to me:

(their stuff is of course HTTPS, and I'm assuming the caller's support links would be as well. Each REST call also has authentication tokens, of course)

=== Out: ===

You POST data to their REST resource, including a link to your PDF document, which they pull (as well as phone number data). Presumably, you want to add some kind of temporary security token/nonce to the link that you give them.

Twilio uses the link to pull your PDF, and sends it to the previously indicated number.

=== In: ===

You GET a list of FAX doc IDs. I don't see query parameters for date ranges and/or phone numbers, but presumably you can do so.

You GET the metadata for a FAX ID obtained from the previous list. This includes a temporary link for the image data.

You GET the image data from the indicated "authenticating" temporary link. It's unclear what the format is (accept headers???), but it's likely PDF only.

===

What seems to be missing in this process is a way to associate an inbound FAX with an outbound FAX (e.g. - barcode or other built in OCR index value). This is needed so that you can support "sign this and send it back" workflows. The phone number is not enough: many docs could go to the same phone number, and the remote signer could send the FAX back from any number, anyway.

Your description is right. To give this a visual dimension, here are sequence diagrams showing how outbound and inbound faxing work at another provider (disclaimer: I'm a co-founder at Interfax):

Outbound: https://www.interfax.net/en/dev/dev-guide/using-interfax-for...

Inbound: https://www.interfax.net/en/dev/dev-guide/using-interfax-for...

Your suggestion for a "sign this and send it back" workflow is an excellent idea. Indeed it shouldn't require more than a single fax number per client, leaving the barcode to do any necessary association. But I would say that this functionality is not best placed on the fax service provider's system, but rather in the application that creates the document to be signed and eventually receives it back. Here's what I mean: http://imgur.com/a/JEldx

Thanks for the sequence diagram. That's exactly what we're doing.

Your feeling about outbound is correct, but inbound is more like:

1. Twilio gets a fax call coming in.

2. Twilio asks you if you want to receive it (based on src/dest numbers), and what URL you want Twilio to hit when it completes.

3. If yes, Twilio receives the fax, and hits the URL specified (with metadata and media URL).

4. You download the media from the URL.

Yes, you're correct that there's no good way to associate separate outbound/inbound faxes. Definitely something we'll consider as a feature to add.

Are document-specific replies part of current manual faxing technology? This seems like something that would depend on your own internal document management rather than the fax protocol itself.

Our current vendor supports this. There is a barcode (or on older stuff, just digits) in a "window" on the document which the system OCRs and uses to index incoming documents. This allows the incoming (returning) docs to be routed back into a workflow for the right user. Important due to volume and data privacy issues.

I don't want to implement the OCR code. Most other clients would probably not want to, either :-)

It's a huge value add, if a vendor is going to offer this service.

I have to rebuild one of these in a week or two, so it is VERY MUCH an item of interest to me to support the "sign and send back" workflow.

Reply on news.ycombinator.com