What should developers check when evaluating a HIPAA-compliant fax API? Two layers. For security and compliance: encryption in transit and at rest, a signed BAA, an independent attestation like SOC 2 Type II, audit logging, and access controls. For integration: a documented REST API, webhooks, a sandbox, SDKs, reliable retries, documented throughput, and a path for inbound documents.
Key terms, defined
- PHI (Protected Health Information): individually identifiable health data. Assume anything a fax API sends, receives, or stores for a healthcare customer is PHI.
- BAA (Business Associate Agreement): the contract HIPAA requires before a vendor handles PHI for a covered entity. It sets out permitted uses, safeguards, and breach-notification duties.
- SOC 2 Type II: an attestation in which an outside auditor checks whether a vendor’s security controls actually held up over a stretch of time, not just on the day of the review.
- IDP (Intelligent Document Processing): the layer that reads an inbound fax and turns it into structured data by classifying the document, running OCR, pulling out the key fields, and routing the result.
- FoIP / T.38: fax over IP, and the protocol that carries it. Fax reacts badly to poor network conditions, which is why carrier quality shows up in deliverability.
Why evaluating a HIPAA fax API is different from a normal API review
Most API reviews come down to whether the docs are clean, the responses are predictable, and the SDKs save you time. A fax API needs all of that. It also moves protected health information, so it has to clear a security review and a compliance review on top of the usual checks. Teams that skip those and start building anyway tend to find out the hard way, either by rebuilding or by stalling in their customer’s procurement.
The way to avoid that is to work two checklists at once: one for security and compliance, one for integration and developer experience. Everything below is something you can confirm from the docs, a sandbox, or a direct question to the vendor before you spend a sprint on it.
The security and compliance checklist
| What to verify | Why it matters | What “good” looks like |
|---|---|---|
| Encryption in transit | PHI on the wire must be protected | TLS 1.2 or higher on all API and transmission paths |
| Encryption at rest | Stored faxes and metadata contain PHI | AES-256 for at-rest storage |
| Signed BAA | Legally required before a vendor handles PHI | A BAA available and signed before any PHI, including test data |
| Independent attestation | Confirms controls actually operate | SOC 2 Type II (an auditor observed controls over a period, not a point in time) |
| Audit logging | Needed for compliance, investigations, reporting | Logged fax activity, delivery status, and metadata you can query |
| Access controls | Limits who can touch PHI | Authentication, least-privilege roles, intrusion detection, SSO for admins |
| Breach notification terms | Defines who reports what, and when | Clear obligations and timelines written into the BAA |
| Subcontractor disclosure | HIPAA obligations flow down to sub-processors | Vendor discloses sub-processors and binds them to equivalent terms |
Encryption is the gate, not the finish line
TLS for data in transit and AES-256 for data at rest are your baseline. Clear them and keep moving, because encryption on its own does not make a system HIPAA-compliant. The Security Rule expects a full set of administrative, physical, and technical safeguards, including a documented risk analysis and real access management. Encryption is the first check, not the last one.
A BAA is mandatory, and it comes before test data
A Business Associate Agreement has to be signed before a vendor touches PHI on your behalf, and “before” includes the test and read-only stages people tend to wave through. Storing encrypted PHI with a vendor still requires one, even when that vendor cannot read the data. Running without a required BAA is a HIPAA violation on its own, breach or no breach, and the agreements have real teeth. North Memorial Health Care settled for $1.55M in a case tied to a missing BAA with a contractor. Raleigh Orthopaedic Clinic settled for $750K after handing PHI to a partner without one.
Two things trip teams up here. A vendor that won’t sign a BAA when PHI is in play is simply off the list. And a certification is not a stand-in for the agreement: HITRUST or SOC 2 tell you something useful about a vendor’s security program, but the signed BAA is what makes the relationship lawful, and it is the document your customer’s security team will ask to see.
SOC 2 Type II means something specific
A Type II report says an outside auditor watched the controls run over a sustained window and signed off on how they behaved in practice. That carries more weight than a Type I report, which only confirms the controls were designed sensibly on a single date. For anything handling PHI, ask to see the current Type II report, or at least its scope, while you are still evaluating.
Log everything, and be able to query it
In healthcare, audit logging earns its keep. You want a durable, queryable record of fax activity, delivery status, and metadata to fall back on during a compliance review or an investigation. Find out what the API logs, how long it keeps it, and how you pull it back out programmatically.
The integration and developer-experience checklist
| What to verify | Why it matters | What “good” looks like |
|---|---|---|
| REST API + JSON | Predictable, easy to integrate | A documented REST API returning JSON |
| Webhooks | You need real-time delivery status | Event webhooks plus a status trail per fax |
| Sandbox | Test safely before production | A sandbox environment separate from live faxing |
| SDKs / code samples | Faster integration, fewer support tickets | Samples in your stack’s languages |
| Retry handling | Faxes fail and must be re-sent | Built-in retries plus delivery confirmation |
| Carrier reliability | Deliverability of mission-critical documents | A purpose-built fax carrier network, not commodity VoIP |
| Throughput / rate limits | High volume can’t bottleneck | Documented limits and high-volume support |
| Inbound + IDP | Receiving is half the workflow | OCR, classification, extraction, and routing for inbound faxes |
| EHR integration | Documents usually land in an EHR | Connectors or a documented path to EHR/EMR systems |
Real-time status is a requirement, not a convenience
In healthcare and legal work, “did it actually go through?” is a compliance question, not idle curiosity. Check that the API reports delivery status over webhooks and keeps a status trail for every transmission, so your application never has to guess whether a referral or an authorization landed.
Sandbox before production, with synthetic data
A sandbox lets you build and test without touching live faxing or real PHI. Keep your test data synthetic until the BAA is signed. A vendor that hands you a free sandbox account is usually one that built its developer experience on purpose, rather than bolting an API onto a consumer product after the fact.
Don’t stop at outbound
Sending is the easy half. The documents that come back, the referrals and authorizations and signed forms, arrive as inbound faxes that someone, or something, has to read and route. Pair the API with intelligent document processing and that inbound fax gets classified, OCR’d into searchable text, stripped of its key fields, and routed automatically. If inbound is part of your product, hold the IDP layer to the same standard as the send path.
Why retries and carrier quality belong on a developer checklist
Fax is picky about the network it rides on. Push it over a cheap VoIP or SIP path and you inherit the latency, jitter, and thin error correction that degrade fax in particular, which is why serious providers run dedicated fax carrier networks instead of commodity voice lines.
The reliability gap is measurable. A 2025 JMIR Medical Informatics study found that fax transmissions failed 37.7% of the time (1,023 of 2,712) when automatic retry was turned off. Switch retry on and the failure rate fell to 9.9% (304 of 3,082), with automatic retries lifting delivery success to roughly 97%. The takeaway for an integration decision is blunt: if the API doesn’t handle retries and surface status, your application will have to, so find out where that responsibility lands before you build.
How to run the evaluation in practice
A repeatable order keeps the review quick and easy to defend:
- Confirm the BAA path first. If the vendor won’t sign one, you can stop here.
- Verify the security baseline: TLS 1.2+, AES-256, SOC 2 Type II, audit logging, access controls.
- Read the API docs end to end for REST/JSON, webhooks, error handling, and rate limits.
- Spin up the sandbox and test send, receive, and status handling with synthetic data.
- Probe reliability: retry logic, carrier network, documented delivery performance.
- Evaluate the inbound/IDP path if your product processes received documents.
- Check the EHR route your customers will need.
- Collect the compliance artifacts (BAA draft, attestation scope) for your own security review.
How Documo maps to this checklist
Here is how Documo lines up against both checklists, pulled from its developer and security documentation. Treat it as a yardstick rather than a shortcut, and confirm each line against current docs.
- Encryption: AES-256 at rest, TLS 1.2 in transit.
- Compliance: SOC 2 Type II certification, plus a signed Business Associate Agreement available on its plans (requested through sales).
- Security features: built-in audit trails, user authentication, and intrusion detection, with the API logging fax activity, delivery status, and metadata for auditing and reporting.
- API and developer experience: a documented REST API that returns JSON, code samples in cURL, Python, Node.js, PHP, and Ruby, and a developer sandbox for testing before production.
- Reliability: a proprietary, fax-only carrier network built on direct tier-1 carrier relationships, with automatic retries, real-time delivery confirmation, and a status trail per fax. Documo publishes 99.9% uptime and a 99.8% delivery rate. Those are vendor-reported figures rather than a contractual SLA, so read them as the target the platform manages to.
- Inbound + IDP: inbound and outbound faxes handled by the API can feed straight into IDP for classification, OCR, extraction, and routing.
- EHR: integrations with EHR/EMR systems, including ModMed, PointClickCare, and NextGen.
Common mistakes when evaluating a fax API
- Treating encryption as proof of compliance. It is one control among many. Confirm the BAA and the attestation too.
- Building before the BAA is signed. Test data is still PHI in plenty of setups, so the agreement comes first.
- Ignoring the inbound side. Outbound is straightforward. The value, and the complexity, usually sit in receiving and routing.
- Skipping the reliability questions. With no retries and no status, your app inherits the failure handling.
- Confusing a certification with a contract. HITRUST and SOC 2 are signals. The BAA is the legal requirement.
Frequently asked questions
What makes a fax API HIPAA-compliant?
A combination of controls plus a contract: encryption in transit and at rest, audit logging, access controls, and the broader HIPAA Security Rule safeguards, backed by a signed Business Associate Agreement. No single feature makes an API compliant on its own.
Do I need a BAA to test a fax API with PHI?
Yes. A BAA must be in place before a vendor handles PHI, and that includes test data. Use synthetic, non-PHI data in a sandbox until the agreement is signed.
What’s the difference between SOC 2 Type I and Type II?
Type I assesses whether controls are designed appropriately at a point in time. Type II evaluates whether those controls operated effectively over a period, which is the stronger signal for a vendor handling PHI.
Does a security certification replace a BAA?
No. Certifications like SOC 2 Type II or HITRUST are useful evidence of a vendor’s security program, but a signed BAA is separately required before any PHI is handled.
How reliable is fax transmission, and why do retries matter?
Fax fails often without retry handling. A 2025 JMIR study measured a 37.7% failure rate with retry disabled, falling to 9.9% once retry logic was enabled. Confirm the API handles retries and exposes delivery status so your application doesn’t have to.
Can a fax API process inbound documents automatically?
Yes, when paired with intelligent document processing. IDP can classify an inbound fax, OCR it into searchable text, extract key fields, and route it, which removes most of the manual handling on the receiving side.
Which languages should the API support?
At minimum, the ones your stack uses. Common coverage includes cURL, Python, Node.js, PHP, and Ruby. Good code samples in your language meaningfully speed up integration and cut support load.
What throughput should I confirm for high volume?
Ask for documented rate limits and confirmation that the platform is built for high-volume sending and receiving, since hospitals, health systems, and software vendors can move large daily volumes.
Key takeaways
- Run two checklists at once: security/compliance and integration/developer experience.
- Encryption (TLS 1.2, AES-256) is a pass/fail gate, not proof of compliance. Confirm the BAA and an independent attestation too.
- A BAA is required before any PHI, including test data, and no certification replaces it.
- Retries, carrier quality, and delivery status are reliability requirements. Fax fails 37.7% of the time without retry logic, per a 2025 JMIR study.
- Hold inbound and IDP to the same standard as outbound, since receiving is half the workflow.
