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

101–110 of 174 posts

Re: Programmable Fax – API for sending and receiving faxes

#101

Post by nck4222 »

beaconstudios wrote: post #38
tyingq wrote: post #21

Earlier quoted context omitted.

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

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

After reading these arguments I was expecting something in the range of dollars per fax.

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?

Re: Programmable Fax – API for sending and receiving faxes

#102

Post by hughes »

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…

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.

Re: Programmable Fax – API for sending and receiving faxes

#103

Post by Roboprog »

bizzleDawg wrote: post #3

The shocking thing about this is that there must still be enough Faxes being sent to actually justify this new product. Where are they still used at 'scale'?

Doctor sign-off on cause of death, as well as other medical related stuff.

Online processes are not yet legal in California.

Re: Programmable Fax – API for sending and receiving faxes

#104

Post by Johnny555 »

Edmond wrote: post #96
viggity wrote: post #88

Earlier quoted context omitted.

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

There are lots of ways to securely transmit data -- which is a large part of the problem, there are so many ways to do it that there's no standard way that you can count on all of your clients/customers having access to... or trusting.

But everyone trusts fax since it goes over "secure" voice lines.... even though in many cases it doesn't.

Re: Programmable Fax – API for sending and receiving faxes

#105

Post by Roboprog »

hughes wrote: post #102
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…

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.

Re: Programmable Fax – API for sending and receiving faxes

#106

Post by sorenjan »

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'm guessing it's an American thing. I think they still use checks too.

Re: Programmable Fax – API for sending and receiving faxes

#107

Post by bambax »

beamatronic wrote: post #45
bambax wrote: post #39

Earlier quoted context omitted.

> food-delivery 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?

What would your software run on? A PC? Who is going to keep it up and running, make sure it is connected to the Internet, etc. It requires a lot less employee training to maintain and operate a fax machine. Can you build a better mousetrap?

I would have thought the PC was already there -- but maybe not in the right place.

Re: Programmable Fax – API for sending and receiving faxes

#108

Post by Roboprog »

Roboprog wrote: post #105
hughes wrote: post #102

Earlier quoted context omitted.

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.

Re: Programmable Fax – API for sending and receiving faxes

#109

Post by bambax »

ybot wrote: post #62
bambax wrote: post #39

Earlier quoted context omitted.

> food-delivery 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?

The short answer is 'yes' — fax machines are actually a pretty great solution to this problem. If you think about it, there isn't really that much overhead for having a fax line and a $40 fax machine vs running a full computer + printer combo, set up is trivial, faxes have a very well-understood track record, and the 'sender' gets direct feedback on whether or not the physical document was successfully delivered. If…

I'm not looking for startup ideas in this domain, I was just wondering "in general". If the PC + printer is already there (surely it has to be for accounting, etc.) why have a fax.

But ok, if the fax and the phone line cost next to nothing and it "just works", then sure it makes a lot of sense.

Re: Programmable Fax – API for sending and receiving faxes

#110

Post by Roboprog »

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%.…

No :-)

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.

Post reply on HN