Skip to main content
You sent a fax. Now you need to know what happened. mintfax gives you two ways to track delivery: poll the API for the current status, or receive webhook events as the status changes. This guide covers both approaches and helps you decide which one fits your integration.

Fax status lifecycle

Every fax moves through a predictable set of states:
A fax reaches exactly one terminal state. Once you see delivered or failed, the status will not change again.

Approach 1: Poll the API

Polling works well for one-off scripts, debugging, and simple integrations where you want to check status on your own schedule. Call GET /fax/{id} to retrieve the full fax record, including status, error_code, error_message, and timestamps.
The response includes everything you need to determine what happened:
If the fax failed, the response includes error_code and error_message:

Poll loop example

If you need to wait for a terminal status, poll with a delay between requests. Fax delivery typically takes 30 seconds to a few minutes depending on page count and carrier conditions.
Respect rate limits. Polling more frequently than once per second will trigger HTTP 429 responses. A 5-second interval is a reasonable default.

Approach 2: Webhooks

Webhooks push status updates to your server the moment they happen. Use them for production systems that need real-time delivery confirmation without polling overhead.

Set up a webhook endpoint

Register your endpoint and subscribe to the events you care about:

Events for delivery tracking

These are the events relevant to tracking a fax through its lifecycle: For most integrations, subscribing to fax.delivered and fax.failed is enough. Add fax.sending if you want per-attempt visibility into transient failures before the final outcome.

Webhook payload

Every event payload includes a unique id for deduplication and created for ordering:
Store each event id you process and skip duplicates. Events may arrive out of order, so use the created timestamp and status to determine the latest state.

Per-fax webhook override

Need delivery updates for a specific fax sent to a different URL? Pass webhook_url when you send the fax:
The per-fax URL receives events for that fax only, in addition to any account-level webhook endpoints.

Retry behavior

mintfax retries failed delivery attempts automatically. By default, each fax gets up to 3 attempts (configurable from 1 to 5 via fax settings). Here is how retries work:
  1. The carrier reports a failure (busy line, no answer, etc.).
  2. If the error is classified as retryable and attempts remain, mintfax schedules the next attempt with a backoff delay.
  3. When the next attempt starts, mintfax fires fax.sending again. Each attempt fires its own fax.sending.
  4. If every attempt is exhausted or a terminal error code is returned, mintfax fires fax.failed and releases the credit hold.
The retries_remaining field on the fax record tells you how many attempts are left. When you poll a fax that is mid-retry, you will see a non-terminal status with a decremented retries_remaining value:
This fax started with 3 retries, has used 2, and is queued for its final attempt. If this attempt also fails, the status moves to failed.

Choosing an approach

You can use both. Poll for quick checks during development, and run webhooks in production for real-time updates. They are not mutually exclusive.

Test in the sandbox

Use sandbox magic numbers to exercise every delivery outcome without sending real faxes: Send to +15005550001 with a sandbox key (mfx_test_...) to confirm your polling loop or webhook handler processes a delivered status. Send to +15005550005 to confirm your integration handles failed. See Sandbox for the full magic number matrix.

What to do next

  • Webhooks - endpoint setup, delivery behavior, and signature overview.
  • Webhook signing - verify that payloads came from mintfax with HMAC-SHA256.
  • Events - full list of event types and payload schemas.
  • Sandbox - magic numbers and simulated failure scenarios.
  • Errors - error codes, HTTP statuses, and recommended actions.
Last modified on July 14, 2026