Dropbox Fax API alternative

The Dropbox Fax API is a REST/JSON fax API on v3 endpoints at api.hellosign.com/v3. It sits under the Dropbox Sign brand (formerly HelloSign), uses the Dropbox Sign authentication scheme, and pairs with the Dropbox Sign eSignature product when a buyer needs signature and fax in one integration. Its SDKs live under the dropbox-sign-* repositories on GitHub. For a team already running on Dropbox Sign, or already procured with Dropbox, the Dropbox Fax API is a natural addition.

mintfax is a developer-first fax service. It is outbound only. Signup runs through the API, per-page pricing is published on /pricing, webhooks are signed with HMAC-SHA256 under the Standard Webhooks specification, POST /v1/faxes accepts an Idempotency-Key header, and the BAA is a click-through in the dashboard.

Feature comparison

API access and pricing

The Dropbox Fax API is not self-serve. To use it, a would-be customer contacts the Dropbox Sign Support team, then sets up the API. Its published pricing lives on a Dropbox help article: a $100 monthly minimum, $2 per additional fax line, and $0.05 per page for outbound and inbound transmissions. The Dropbox Sign API product page does not carry those numbers, and a developer evaluating the Dropbox Fax API against other providers has to email support to move from evaluation to a working key.

You can create a mintfax sandbox through the API. Two calls, POST /account/register followed by POST /account/register/verify with a 6-digit code, provision a working sandbox. No card, no BAA, no support ticket. Per-page pricing is published on /pricing: $0.07 per page for every destination. There is no monthly minimum, no per-line fee, and no setup cost.

The published Dropbox Fax API pricing includes a $100 monthly minimum that applies before per-page charges do. At 500 pages per month, a mintfax customer pays $35 while the Dropbox Fax API charge lands on the minimum floor. Cost parity crosses around 1,429 pages per month.

Delivery updates and duplicate requests

The Dropbox Fax API v3 signs every webhook delivery with a custom HMAC-SHA256 scheme. The signing input is event_time + event_type concatenated, keyed by your API key. The hex digest arrives on the event as event_hash. The signed input does not include the request body.

mintfax signs every webhook with HMAC-SHA256 under the Standard Webhooks specification. The signed payload is {webhook-id}.{webhook-timestamp}.{body}, so the body is part of what the signature covers. Each delivery carries three headers: webhook-id, webhook-timestamp, and webhook-signature. The per-endpoint signing secret is prefixed whsec_. Standard Webhooks client libraries exist for Node, Python, PHP, Go, .NET, Ruby, Rust, Java, and C#. See verify requests for the receiver-side check.

The Dropbox Fax API does not document an Idempotency-Key header or an equivalent replay-safety token on POST /v3/fax/send or in the dropbox-sign-* SDKs. A retry after a timeout can double-send.

mintfax accepts Idempotency-Key on POST /v1/faxes. The same key with a different body returns 409 idempotency_key_reuse. The same key while the original is still in flight returns 409 idempotency_key_in_progress. Replayed responses carry Idempotent-Replayed: true. Keys expire after 24 hours. A request without the header receives a nudge header on the response: X-Idempotency-Key: not provided; recommended.

Rate limits and retries

The Dropbox Fax API enforces a hard cap of 200 pending faxes per user per day. Exceeding the cap returns HTTP 429 with the response body “Please wait. You already have at least 200 transmissions that are currently pending or transmitting.” The published Dropbox help article does not describe a Retry-After header or a programmatic wait-time hint on that response, so a client hitting the cap chooses its own backoff.

mintfax follows the HTTP Retry-After convention. A 429 response includes Retry-After in seconds and the error envelope carries rate_limit_exceeded.

The Dropbox Fax API does not document a per-fax retry policy on POST /v3/fax/send. The reference page for the endpoint enumerates every request-body field and none configures retries; the third-party fax.plus review of the Dropbox Fax API corroborates the absence.

mintfax retries carrier failures automatically. Default backoff is 1m / 3m / 5m / 5m for a default of 3 attempts, and max_attempts in the send request sets the ceiling per fax between 1 and 5. Retryable codes consume an attempt; terminal codes such as invalid_number, bad_destination, and no_route short-circuit to fax.failed regardless of attempts remaining.

Testing

The Dropbox Fax API exposes a per-request test_mode boolean. Setting test_mode: true on POST /v3/fax/send marks the request as a test, per the test_mode parameter documented on the Send Fax reference.

mintfax’s sandbox runs on mfx_test_ keys and shares the same endpoints as live. Nine test numbers simulate nine scenarios, including successful delivery, busy lines, invalid numbers, and insufficient credit. No card, no BAA, no support contact. See sandbox scenarios for the full number matrix.

Agreements and stored content

The Dropbox Sign help page states that supporting HIPAA compliance on any Dropbox Sign product requires an annual Standard or Premium plan, a signed Business Associate Agreement, and meeting a minimum contract value that Dropbox does not publish. There is no self-serve BAA path for the Dropbox Fax API product. The HIPAA Journal analysis of HelloFax notes the BAA is signed with Dropbox Sign rather than the wider Dropbox service, and the fax.plus 2026 review of the Dropbox Fax API records that no self-serve plan carries HIPAA compliance or a BAA.

mintfax offers a BAA and a separate DPA as click-through documents in the dashboard. Acceptance writes a durable evidence record (account, template version, signer name and title, IP address, user agent, accepted_at); the executed PDF is available immediately.

mintfax content retention defaults to 90 days and is configurable per environment between 7 and 365 days. Zero-footprint mode, off by default and per environment, deletes fax content on terminal classification (fax.delivered or fax.failed) and preserves operational metadata. Per-fax deletion is available for delivered or failed faxes via DELETE /v1/faxes/{fax}. See compliance for the controls and their limits.

When the Dropbox Fax API is the right call

The Dropbox Fax API is a better fit in two specific cases.

If your team is on the Dropbox Sign eSignature product, or plans to be, and wants signature and fax under one contract and one integration, the Dropbox Fax API sits under the same brand and shares the Dropbox Sign authentication scheme. mintfax does not offer eSignature.

If your primary need is inbound fax, receiving faxes to a provisioned number and managing the inbox through a portal, the Dropbox Fax API supports it and mintfax v1 does not. One operational note on the Dropbox side: received faxes cannot be deleted through the API. To delete a received fax, a user has to log in to the web application.

Try mintfax

Start in the free sandbox, see the Dropbox Fax API migration guide, or check mintfax pricing.