Where are they still used at 'scale'?
They're pervasive in finance, insurance, employee benefits, etc.
They're also a good one-to-many API multiplexer. So many businesses can take a fax and have a human operate on it that many software companies can use them to add actuators to their software without having to bizdev the company into adding an actual API integration.
This is how these marketplaces can confirm someone is there to actually receive the order and provide that feedback to the customer that their order has been received.
I think (but am not sure) that they can provide time estimates through the IVR system as well.
Some restaurants moved towards having tablets and receiving order via an app, but I'd guess that fax is still an option since it's difficult to integrate with a bunch of different POS systems and there are also a fair amount of restaurants that use hand written tickets to communicate orders to a kitchen.
I wouldn't be surprised if this Fax API is the same technology that those companies use to fax orders to restaurants.
I've seen tablets in cafes at the front of the house, and sometimes the cashier (who can't touch food while they're also touching money) copies the order off the tablet and onto a piece of paper and passes it off to the kitchen the old fashioned way, while acknowledging it was received on the tablet.
But holding a PDF of same is not.
So it's easier/cheaper for a restaurant to have a dedicated phone line for faxing (plus fax and supplies) than connect a printer to a PC?
Is this because someone needs to actually print incoming emails or orders? And if yes, is there an opportunity for some kind of software solution that would always print what it receives, with no human intervention?
So they send a lot of them.
For some reason the fax is legally sounder than email.
- sign - scan (usually sent as a weird filename to your corporate email) - save the attachment, rename the file, create a new email, attach the file, send
I suspect that faxes have been around for so long, and tested in court so many times, that by this time they are as good as holding the original if a lawsuit were to happen.
They are viewed as "safe" for credit card information, as opposed to emails.
Unknown as to why these manufacturers don't provide an online payment system. I work with several that want faxes, and they aren't small companies.
I also saw this with companies that provide drug testing, background checks, etc. Same thing...viewed as a secure channel.
The odds of someone obtaining credit card information from a plaintext email is a lot higher than someone decoding a VOIP SIP/T38 stream over the public internet, and reading the secrets out of that.
And if its through a traditional carrier (not an Internet provider), its digital, but almost always over their internal network. It is more secure through obscurity alone than plain text email.
I see all sorts of things I shouldn't see when searching the pile of papers on the fax machine at a large company for my fax.
Also fax is apparently the only way to reserve a table for Oktoberfest in Munich. Or so says a German colleague.
A lot of routine tasks in Japan also require a fax machine.
Also, fax is still used for a lot of financial and legal stuff generally, especially in countries with less developed Internet infrastructure.
Online processes are not yet legal in California.
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.
https://kev.inburke.com/kevin/six-years-of-hacker-news-comme...
The difference in pricing will certainly make them consider a switch.
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 cost.
In any case, their pricing model has been far preferable to their old competitor, Interfax: https://www.interfax.net/en/prices
Is 7 cents per page really that much? I'm not very knowledgeable about this stuff, but are there really that many places out there faxing thousands of pages where 7 cents per page vs 5 cents per page is really going to make a difference for them?
Congrats Twilio!
But after seeing full API docs... is this real? I'm so confused!
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.
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.
(I'm glad 1st April is a Saturday this year so I can mostly not be near a computer for it to avoid the intensely twee irritation of it all.)
[edit]
Even stranger, I can go online and have my bank mail a check to anywhere in the US for free. It's $20 to send it directly to someone's bank account.
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.
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 business that is the limiting factor.
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/
(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.
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
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.
It's a huge value add, if a vendor is going to offer this service.
Plus, I would rather somebody else build doc ID OCR in a language other than Java so I don't have to build it myself. This is going to come up time and time again.
Phaxio has said they can handle any number of simultaneous inbound faxes, but we haven't had a chance to try them yet. It would be nice to know if Twilio is an option.
/s
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 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.
I don't see the problem with it.
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%. This results in repeated fax transmissions and patients waiting days to know whether their insurance company will buy them a wheelchair.
Using an API like this, you can at least digitize one end of the process, error-free, and still deliver the expected fax to the other side which hasn't upgraded yet.
My first reaction was "I have to rewrite one of these in a week or two, is this API easier/cheaper to use than our current vendor?"
I suppose if this post had come up a few months earlier or later, I would not have cared so much. But today, I'm all over it.
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.
If you want places like healthcare to stop using faxes, propose a secure solution that meets their needs and fulfills government requirements / restrictions.
Here's a fun side project for somebody: Make a network tunnel that uses faxes as a way to send packets back and forth. You can encode the packets as a QR code, ship it over via fax, and then reply back with another fax. Be cool to see that in action with a human doing the receipt / transport vs. a fully automated one (two computers using Twilio API).
"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.
As for doctors using faxes,that sounds like a disaster waiting to happen.
I live in Norway, all the health records are online so my GP and any hospital in the country can see my records (if I give consent), prescriptions are electronic and paperless, etc. I still get snail mail letters from the health system but that is simply because I have not got around to applying for a secure email account (the state gently reminds me now and again).
