Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programmable Fax – API for sending and receiving faxes

twilio.com

Post reply on HN
Print view View original

91–100 of 174 posts

Re: Programmable Fax – API for sending and receiving faxes

#91

Post by iamatworknow »

apeace wrote: post #76

If anyone's first reaction was along the lines of: "Faxing in 2017?" or "Is this an April Fool's joke?", consider that the healthcare industry still uses faxes frequently. I once interviewed at a company that was building software for ordering durable medical equipment in hospitals. They told me that all orders were faxed to the insurance companies, and the error rate for copying data to the faxed form was about 90%.…

A lot of the personal financing industry still does too, particularly for car loans. There are some web solutions but they always involve some third party service that both the car dealership and bank has to sign up (and pay) for.

Re: Programmable Fax – API for sending and receiving faxes

#92

Post by viggity »

j_s wrote: post #77
travelton wrote: post #72

This is neat! But I have to expose the PDF to the internet for Twilio to pick up the file and send it? https://www.twilio.com/docs/api/fax/quickstart#send-a-fax

https://www.twilio.com/docs/api/security#validating-requests Twilio cryptographically signs its requests Not sure on the specifics of a GET vs the normal POST callbacks but they definitely are aware this is an issue.

I'd be surprised if it wasn't similar to (or exactly like) their POST auth. They concatenate the URL, the post variables (alphabetically sorted) and your twilio account id and hash it with your auth key. They put that hash into an auth header on the post.

I had to dig into it because we had a reverse proxy in front of our app and the hash generated by their client .net library was understandably different than what they sent because the domains were ultimately different.

Re: Programmable Fax – API for sending and receiving faxes

#93

Post by fragmede »

coffeedoughnuts wrote: post #7

I just assumed from first glance that this was an early April Fools (I guess it must be April 1st in Australia by now) But after seeing full API docs... is this real? I'm so confused!

A corollary from William Gibson's famous quote, "The future is already here — it's just not very evenly distributed.", is that just because you're living in the future where you, and all your friends have smartphones, doesn't mean that everyone does.

In fact, there are huge swaths of people that don't even have broadband Internet access, even in the US, even using the FCC's antiquated definition of broadband of 2 Megabit. Meanwhile, I can get 20 Mbit with my cellphone on 4G LTE on a good day.

Be careful when extrapolating from things you don't use because it doesn't necessarily follow that others don't.

Re: Programmable Fax – API for sending and receiving faxes

#94

Post by karlmdavis »

nojvek wrote: post #90
kelnos wrote: post #80

Earlier quoted context omitted.

I'd be surprised to see more than a couple minutes for even a complicated fax page. I've seen 45-70 seconds average for a not-too-complicated page. It also depends on the baud rate (never thought that term would come back, eh?) negotiated between both ends. A 14400 baud transmission will of course be faster than 9600.

I paid $10 to send a 28 page fax. I absolutely believe utility and govt companies still use fax because they want to make somethings very hard for the average customer. There's no reason why I shouldn't be able to send an email a pdf to show good credit so they don't charge me a deposit fee. Twilio please build a mobile app so those of us who don't live with typewriters and fax machines can deal with our nasty govt.

Where in the government do you still have to fax things?

Re: Programmable Fax – API for sending and receiving faxes

#95

Post by Roboprog »

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.

Re: Programmable Fax – API for sending and receiving faxes

#96

Post by Edmond »

viggity wrote: post #88
tdeschamps wrote: post #59

Earlier quoted context omitted.

They might have not considered this to be a big enough business opportunity when they penned this section.

I'm in healthcare. I'm not kidding you, we got an 800 page fax last month from one of our clients. It wasn't a generated e-fax either, we received it electronically (we use sfax), but the lady who sent it literally printed 800 pages and put them on her fax machine. It isn't the business opportunity that is the problem (that is huge), it is the all of the HIPAA/HITECH regulations which creep into every part of your bu…

can you elaborate on the HIPAA concerns related to faxing/transmitting health data?

Faxing is a transport service... is the concern around security and privacy while en route from the API to the destination?

If there was a way to facilitate that transfer without compromising privacy or security en route would that address HIPAA concerns?

We've developed a privacy preserving trust relay protocol which might be applicable to use cases like this that's why I am asking: https://www.cipheredtrust.com/

Re: Programmable Fax – API for sending and receiving faxes

#97

Post by kevinburke »

tyingq wrote: post #21
kevinburke wrote: post #2

This has been kicked around for a really long time and I'm happy they finally launched it. Around 2013 or so, one of the junior engineers on the Twilio Voice team pitched his innovation week project with a single slide saying "Fax: The time is now." The time has finally arrived! Congrats John.

Guessing this will kill Phaxio. Compare the pricing: https://www.twilio.com/fax/pricing https://www.phaxio.com/pricing/

Rumors of the demise of telecom services based on their competitors' feature set and pricing are greatly exaggerated.

https://kev.inburke.com/kevin/six-years-of-hacker-news-comme...

Re: Programmable Fax – API for sending and receiving faxes

#98

Post by Roboprog »

Roboprog wrote: post #95

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…

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.

Re: Programmable Fax – API for sending and receiving faxes

#99

Post by Roboprog »

Artemis2 wrote: post #84
Roboprog wrote: post #79

Earlier quoted context omitted.

"Wet signature" being a term with some legal standing. DocuSign, not so much, other than for preliminary real estate actions.

Could you elaborate on the "not so much"? A lot of companies (including law firms and Fortune 100 corps) have had me sign documents with DocuSign/HelloSign with no reservation. What would be the potential legal differences compared to an actual signature?

I'm working on the California death certificate automation system. DocuSign is not legally accepted for a doctor to sign off on cause of death for a decedent.

Laws for your use case will be different. That's mine.

Re: Programmable Fax – API for sending and receiving faxes

#100

Post by giarc »

viggity wrote: post #88
tdeschamps wrote: post #59

Earlier quoted context omitted.

They might have not considered this to be a big enough business opportunity when they penned this section.

I'm in healthcare. I'm not kidding you, we got an 800 page fax last month from one of our clients. It wasn't a generated e-fax either, we received it electronically (we use sfax), but the lady who sent it literally printed 800 pages and put them on her fax machine. It isn't the business opportunity that is the problem (that is huge), it is the all of the HIPAA/HITECH regulations which creep into every part of your bu…

I work in healthcare, we get about 200-300 pages per day.
Post reply on HN