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

151–160 of 174 posts

Re: Programmable Fax – API for sending and receiving faxes

#151

Post by zAy0LfpBZLC8mAC »

WTF?

"Programmable Fax" - as if fax was somehow not accessible to computers before twilio invented a proprietary API for it. Yes, it was, believe it or not: You can indeed send faxes from software, via a fax modem connected to a landline, or an ISDN TA connected to an ISDN line, via a GSM MT connected to a GSM network ...

Or, if you like your internet and don't want to deal with older communications networks directly, there even is a frickin non-proprietary API for it that was standardised nearly two decades ago: T.37 and T.38. And there have been companies offering gateway services that allow you to send faxes to the PSTN using those APIs for about as long.

Re: Programmable Fax – API for sending and receiving faxes

#152

Post by cordite »

rsync wrote: post #150

Ugh. How can it be possible that my favorite technology service in 2017 is perpetuating something that absolutely must die ? Common decency dictates that we must do everything possible to make faxing as hard as possible . When someone asks you to fax something, pretend you have no idea what they're talking about . Then ridicule them.

Not everyone that demands a fax wants it through fax. Making someone's job harder socially won't get a business, organization, or agency to change their ways.

If you want places like healthcare to stop using faxes, propose a secure solution that meets their needs and fulfills government requirements / restrictions.

Re: Programmable Fax – API for sending and receiving faxes

#153

Post by cordite »

pg_bot wrote: post #26

If Twilio will sign a business associates agreement, this could be huge in the healthcare field. EMRs have terrible interoperability so doctors and health systems typically fax health records to one another. However, this service does not look HIPAA compliant based on the sparse documentation. It doesn't look promising that they will sign a BAA according to this document. https://support.twilio.com/hc/en-us/articles/…

Unless a sandboxed version can be run on site within a private network, OR they make a secure HL7 service, I do not expect healthcare to adopt this over other products like RightFax.

Re: Programmable Fax – API for sending and receiving faxes

#154

Post by [deleted] »

Roboprog wrote: post #99
Artemis2 wrote: post #84

Earlier quoted context omitted.

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.

[deleted]

Re: Programmable Fax – API for sending and receiving faxes

#155

Post by supertrope »

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?

47 states (New York, Washington and Illinois the outliers) have passed an Uniform Electronic Transaction Act that confers electronic signatures with equal weight. A federal law has existed since 2000. Unfortunately a self-fulfilling prophecy of people not accepting the validity of electronic agreements because no one else does has kept usage low. Even faxed contracts are often followed up with Fedex delivered versions. The only electronic agreement I've done is FAFSA's PIN blessed submission. The recent high profile payment card breaches and politician email doxxing have further decreased public confidence in all things computerized.

Re: Programmable Fax – API for sending and receiving faxes

#156

Post by sjg007 »

pg_bot wrote: post #122
Edmond wrote: post #96

Earlier quoted context omitted.

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 applica…

I can elaborate since I own a business that requires HIPAA compliance. The main issue is not transmission, it is storage. According to their documentation "We store a list of your sent and received faxes, along with the media, for 180 days". This line opens you up to the privacy/security rules of HIPAA since your health records are littered with protected health information (duh). These regulations are not unreasonab…

The fines are the issue.

Re: Programmable Fax – API for sending and receiving faxes

#157

Post by noer »

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!

I got a snotty reply from someone at Twilio when I suggested it might be an April Fool's joke on Twitter.

Amazon prime buttons were announced on 3/31/15 or 4/1/15 (I forget which date it was) and I remember a bunch of buzz around my office wondering if it was an April Fool's stunt or not. I don't really see the harm in waiting a few days to launch some kind of new/potentially unbelievable product so you don't do it on 4/1, since the internet tends to go nuts on that day.

Re: Programmable Fax – API for sending and receiving faxes

#158

Post by joering2 »

rabidonrails wrote: post #54
beaconstudios wrote: post #38

Earlier quoted context omitted.

it's amazing that phaxio have gotten away with such high prices for so long.

Phaxio founder here. Our pricing might seem higher (and may be in certain situations), but it works a bit differently that Twilio's. Twilio charges you the 1c _plus_ the costs of the call. Phaxio is an "all in" rate _including_ retrying the call. And, at Phaxio, if the calls all fail there's no cost to you. I'm not saying that we won't adjust our pricing (#competition), but there's a difference in the actual unit cos…

Long time user of Phaxio. We tried many other services and your seems the be the best when it comes to crunching documents - Word, PDF, Images, you name it.

I don't know how Twilio does it, but unless one day in 100 years from now we will be sending 1 million faxes, we will be reluctant to switch and probably save ourselves a headache just to save few bucks a month.

Re: Programmable Fax – API for sending and receiving faxes

#159

Post by faxman »

pg_bot wrote: post #26

If Twilio will sign a business associates agreement, this could be huge in the healthcare field. EMRs have terrible interoperability so doctors and health systems typically fax health records to one another. However, this service does not look HIPAA compliant based on the sparse documentation. It doesn't look promising that they will sign a BAA according to this document. https://support.twilio.com/hc/en-us/articles/…

You might want to take a look our service, Interfax, an API-powered internet fax service provider, which addresses HIPAA and offers BAA's.

In fact, we cover a range of regulatory/standard requirements such as PCI-DSS (Tier 1) and EU GDPR.

We're now also looking at the Oz equivalent of these types of legislation.

https://www.interfax.net/en/hipaa_compliance

Re: Programmable Fax – API for sending and receiving faxes

#160

Post by faxman »

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…

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

Post reply on HN