Salesforce Fax Integration: Send Faxes From Your CRM

By Sarah Martinez · Published June 8, 2026 · Updated July 15, 2026 · 11 min read

Quick Answer: Salesforce cannot send a fax on its own — the standard Fax field only stores a number. A Salesforce fax integration means connecting an outside fax provider through one of four routes: an AppExchange package, a no-code automation, a fax API called from Apex, or email-to-fax.

Every Salesforce org already looks fax-ready. There is a Fax field on Lead, Contact, and Account, sitting right next to Phone, filled in by half your sales team. Then someone asks the obvious question — can we send the signed order form to that number? — and the answer turns out to be no.

That gap is what "Salesforce fax integration" actually means. The CRM holds the record, the document, and the fax number; something outside the CRM has to put the pages on a phone line. This guide covers the four routes that work, what each one really costs in 2026, and the two technical walls that stop most in-house builds on day one.

Does Salesforce Have a Built-In Fax Feature?

No. Salesforce has never shipped native fax sending, and it isn't a gap that closed quietly in a recent release. "Send a Fax from Salesforce" remains an open request on the Salesforce IdeaExchange, which is a reliable sign the platform team considers it partner territory.

What Salesforce gives you is storage, not transmission:

• The Fax field on Lead, Contact, and Account — a phone-type field that holds the destination number.
• Salesforce Files (ContentVersion) — where the PDF you want to send already lives, attached to the record.
• Flow, Apex, and Named Credentials — the plumbing to hand both of those to somebody else's fax network.

Everything else is a third-party product. That's not a complaint; it's the design. The practical consequence is that choosing a Salesforce fax integration is really choosing a fax provider, and then choosing how much of the connection you want to own.

The Four Salesforce Fax Integration Routes

There are exactly four ways to get a document out of Salesforce and onto a fax number. They differ mostly in who maintains the connection and what you pay per page.

1. Install an AppExchange fax package

This is the route most orgs take first, and it's the one with published prices. Two listings dominate:

Both prices sit on top of an account with the fax provider itself. That's the detail vendor pages tend to bury: the AppExchange listing is the connector, not the faxing.

What you get for it is real, though. A managed package drops a "Send Fax" quick action onto page layouts, logs sent and received faxes back onto the Contact or Case, and survives Salesforce release upgrades without anyone on your team thinking about it. For a clinic sending twenty referrals a week, that is a fair trade.

Where it stops being a fair trade is volume. At $0.15 per page plus a $50 line fee, a thousand pages a month costs roughly $200 before anyone opens Setup.

2. Automate it without code

Some providers skip the AppExchange entirely and bridge to Salesforce through a general automation tool. Fax.Plus is the clearest example: its CRM page lists native Salesforce support as coming soon, and its own help center documents the integration as a Zapier recipe — Fax.Plus as trigger, Salesforce as action — available on the Enterprise plan.

That pattern works well for one specific job: reacting to an inbound fax. A fax arrives, the automation creates an Attachment on the matching record, done. No Apex, no deployment.

It works badly in the other direction. Sending means pushing a binary PDF through a middleman, and most no-code connectors either can't do it or require the file to be publicly reachable at a URL first — which is exactly what you don't want for a signed contract or a patient record.

Salesforce's own no-code option has the same ceiling. Flow's HTTP Callout action lets an admin call a REST API with no code at all, and it's genuinely useful — but you configure it by pasting a sample JSON response, and it offers no mechanism for attaching a file to the request body. Flow can start a fax and read its status. Flow cannot carry the document.

3. Call a fax API from Apex

This is the route with the best economics and the most control, and it's what the rest of this guide walks through. You keep the document inside Salesforce until the moment of send, you pay only for pages, and the workflow can be anything Apex can express — fax on approval, fax on stage change, fax a generated PDF from a Visualforce page.

The trade is that you own the code. Budget a day for a first working version and a few hours a year for maintenance.

Per-page cost is where this route pays for itself. The mFax API is included on every mFax Business plan, which is usage-based at $3 per seat plus $4 per 100 pages — about $0.04 a page, roughly a quarter of what a connector-plus-provider stack charges. Plans start from about $9/mo billed annually, and a signed BAA comes with them.

4. Fall back to email-to-fax

Every fax provider accepts documents at an address like 15551234567@fax.provider.com. Salesforce sends email natively, so an Email Alert on a Flow is technically a fax integration.

Use it for genuinely occasional sends. Its weakness is that the fax leaves the building through your email server, so Salesforce learns nothing about whether it arrived — no status, no receipt, no record on the Case. Our email-to-fax API guide covers when that trade is worth making.

How to Build a Salesforce Fax Integration With a REST API

Here's the working path, using the mFax API as the concrete example. The shape is the same for any provider that accepts a multipart upload.

The Apex callout itself is unremarkable:

public with sharing class MFaxSender {

    @future(callout=true)
    public static void sendFax(Id contentVersionId, String toNumber) {
        ContentVersion cv = [
            SELECT PathOnClient, VersionData
            FROM ContentVersion
            WHERE Id = :contentVersionId
            LIMIT 1
        ];

        String boundary = '----mfax' + String.valueOf(Crypto.getRandomLong());

        HttpRequest req = new HttpRequest();
        req.setEndpoint('callout:mFax/v1/faxes');
        req.setMethod('POST');
        req.setHeader('Content-Type', 'multipart/form-data; boundary=' + boundary);
        req.setTimeout(120000);
        req.setBodyAsBlob(
            MultipartBuilder.build(boundary, toNumber, cv.PathOnClient, cv.VersionData)
        );

        HttpResponse res = new Http().send(req);
        // 202 -> {"uuid":"...","status":"queued","to":"+15417543010"}
        if (res.getStatusCode() != 202) {
            System.debug(LoggingLevel.ERROR, res.getStatusCode() + ' ' + res.getBody());
        }
    }
}

Note the @future(callout=true). Apex refuses to make a callout after a DML operation in the same transaction — the "uncommitted work pending" error — so a fax triggered from a record update has to run asynchronously, in a @future method or a Queueable. This catches almost everyone once.

MultipartBuilder is the part that isn't unremarkable.

The Two Walls Most Salesforce Fax Builds Hit

Apex has no native multipart/form-data support

HttpRequest will happily send JSON. It has no built-in way to compose a multipart body with a binary file in it, and that has been a standing request on the IdeaExchange for years. You have to build the body yourself, byte by byte.

The naive approach — concatenate the boundary text, the headers, and EncodingUtil.base64Encode(fileBlob), then decode the whole thing back to a Blob — produces a corrupted file. The reason is Base64 padding: when a segment's length isn't a multiple of three bytes, its encoding ends in one or two = characters, and Apex's decoder silently ignores padding that appears mid-string. Every character after that point shifts, and the PDF arrives as garbage.

The community fix, worked out by Enrico Murru and refined by Grant Wickman, is to pad the segments deliberately: adjust each part so its byte length lands on a multiple of three, borrowing the \r and \n characters that legitimately separate the file bytes from the closing boundary. Do that and the concatenated Base64 decodes cleanly.

Flow HTTP Callout can't carry a file

The second wall usually appears in a planning meeting: can't an admin just do this in Flow?

Partly. Flow's HTTP Callout is a real integration tool — it generates a reusable action from a sample JSON response and needs no code. But that JSON-shaped design is the limit. There is no file input, no binary body, no way to say "attach this ContentVersion." A flow can decide that a fax should go, pass the record and file IDs to an invocable Apex method, and later read the delivery status back as JSON. The document itself always travels through code.

Plan the split that way from the start and the build stays clean: Flow owns the business logic, one Apex class owns the transmission.

Salesforce Limits That Cap Fax Volume

Salesforce's callout governor limits shape what a fax integration can do more than any fax provider's limits do.

Three consequences worth designing around:

1. The request size limit is a page-count limit. A Base64-inflated multipart body is roughly a third larger than the raw PDF, so a 6 MB synchronous ceiling is closer to 4 MB of actual document. Run sends asynchronously to double the headroom, and compress the PDF before it goes near the callout.
2. Bulk faxing needs batching. A hundred callouts per transaction sounds generous until a trigger fires on a 200-record import. Queue the work — a Queueable chain or Batch Apex — rather than looping callouts in a single transaction.
3. A 120-second timeout is not a delivery window. The send request returns in under a second; the fax itself takes 30–90 seconds on the provider's side. Never hold a transaction open waiting for delivery, and never poll in a loop. Use the webhook.

mFax rate-limits with a 429 and a Retry-After header, so a Queueable that respects it will drain a backlog cleanly instead of hammering the endpoint. For a wider view of automating fax at this level, see our guide to fax automation.

HIPAA, Health Cloud, and the Second BAA

Healthcare orgs are the largest group searching for Salesforce fax integration, because referrals, prior authorizations, and lab results still move by fax. The compliance detail that trips people up is simple:

Your Salesforce agreement does not cover your fax vendor. The moment a PDF leaves the org and enters a fax network, the provider is handling PHI and becomes a business associate in its own right. You need a second signed BAA, from them.

Before PHI moves, confirm:

• A signed BAA from the fax provider, not a marketing page that says "HIPAA-compliant."
• Encryption in transit and at rest for the document while the provider holds it.
• An audit trail you can produce — who sent what, to which number, and when it was confirmed.
• A number-verification step in the workflow, because misdialed faxes are a genuine, reportable breach category.

The AppExchange packages built for this market clear that bar — Concord lists Health Cloud and Government Cloud support, and the eFax Connector targets healthcare and financial services. So does mFax Business, which includes a signed BAA, AES-256 at rest, and TLS 1.2+ in transit on every plan alongside the API. Our HIPAA-compliant fax API guide covers the full checklist, and BAA for fax services explains what the document itself has to say.

Which Route Should You Choose?

Match the route to your volume and your appetite for maintenance, not to the feature list:

One more option deserves naming, because it quietly fits a lot of orgs: don't integrate at all. If faxing is occasional and nobody needs it logged against a Contact, a team fax app running next to Salesforce beats a connector subscription and a maintenance burden. mFax runs on the web, iPhone, Android, Mac, and Windows under one account with shared history — copy the number out of the Fax field, drop the PDF in, send. Zero build, zero governor limits.

The same reasoning applies to other business tools that lack native fax; we covered the equivalent question for Microsoft Teams.

Start Building

Salesforce fax integration has no native shortcut, but it has a clear cheapest path: keep the connector out of the stack and call a fax API directly, so you're paying for pages instead of plumbing.

Create an API key in the mFax dashboard and read the reference at developers.mfax.to — send is one POST /v1/faxes with to and file. API access is included on every mFax Business plan, along with a signed BAA and usage-based pricing you can size with the live calculator.

Want to see what the request looks like before you write a line of Apex? Our send-fax API guide has it as a single cURL command, and fax API pricing compares per-page and subscription models across providers.