Fax API Migration Checklist

1. Start with the fax workflows you already have

Start with a short list that a developer and the person responsible for day-to-day faxing can review together. Include outgoing faxes, incoming numbers, document storage, delivery updates, and any business software that uses those documents or updates. In the steps below, a “job” simply means one fax task your application needs to track.

For each workflow, record what starts it, where the document comes from, who receives it, and what happens if delivery fails. Identify scheduled jobs, manual resends, and documents that someone has already submitted but your application has not yet marked complete.

Separate three kinds of work:

• Software changes: how your application connects to the account, submits documents, and receives updates.
• Number changes: which numbers will move, which will stay with the existing provider, and which teams receive faxes on each number.
• Records to keep: which documents, reports, and activity records you’ll still need after the old account closes.

Plan how you’ll export and store historical records separately from transferring your number. For example, your team may need to look up a confirmation report from a fax sent months before the move. Decide where that report will live, who can access it, and how long your organization needs to keep it.

Next, agree on what “ready to switch” means. These are your acceptance criteria: the checks that must pass before you start using the new integration for real work. For example, the document must be readable, an incoming fax must reach the right team, and a delivery result must appear beside the correct application record. Choose checks that reflect your own documents and destinations.

2. Set up account access and authentication

Our API is available on the Enterprise plan, as explained in the Fax.Plus API quickstart. Confirm the account, assigned numbers, and features needed for your workflow before planning the production switch. Eligibility to port a number is not the same as eligibility to use the API.

Authentication is how the API checks which account your application can access. Our authentication guide covers personal access tokens and OAuth 2.0. A personal access token is a secret your application uses to authenticate requests. OAuth 2.0 lets a user authorize access through a sign-in and consent flow. Your developer should choose the method that fits the workflow and follow its setup requirements.

Keep the credentials used for real work separate from your test setup, and store secrets on the server rather than in browser code. Limit permissions to the actions the application needs. During testing, disable a test credential deliberately and check that your application reports the problem clearly. A connection problem should give your team something to investigate, rather than trigger repeated sends.

For regulated workflows, confirm your organization's security and contractual requirements before using real documents. A technical connection alone does not establish that the entire workflow meets those requirements, especially when other applications handle the documents.

3. Keep each fax connected to the right business record

Write down how the information in your current integration corresponds to the new one. This is sometimes called a field map. It should cover details such as the destination number, document reference, fax ID, and result. Keep your application’s own job ID unchanged and save the old and new providers’ IDs alongside it.

For example, an order called PO-1042 in your system should remain PO-1042 after the move. Its fax may have a different tracking ID with the new provider, but your team should still be able to find the order, the document, and its result together.

With Fax.Plus, you upload a file first. The API returns a path, which is the reference your application includes in its send request. The send endpoint, the API address that accepts that request, can return scheduled fax IDs when you set return_ids to true. Save those IDs so you can follow what happens next.

Show the difference between “submitted,” “being processed,” and a final delivery result in your application. The outbox guide describes stages such as document conversion and sending. A successful API request tells you that the request was accepted; your application still needs to track the fax to its final outcome.

Decide what your team should see when only part of a fax is transmitted, when a send fails, or when a result needs a person’s attention. A useful message explains what is known and what to check next. That helps an operator decide whether to inspect the document, verify the destination, or authorize another attempt.

Test document appearance with sample files containing made-up information. Include multi-page PDFs, scanned pages, small text, and any cover-page layout your workflow uses. A request that succeeds technically can still produce a document that is difficult for the recipient to read.

4. Make delivery updates useful and safe to repeat

A webhook is an automatic message sent to your application when an event occurs, such as a fax finishing transmission. It helps your application update a record without repeatedly asking whether anything has changed. For a new integration, follow our current webhook documentation and use /v3/webhooks.

The event name fax_sent means the outbound session finished, including unsuccessful attempts. Read its status before marking a record “delivered.” Check the webhook’s signature, a cryptographic check used to verify the message, and acknowledge valid messages promptly. Schedule slower work, such as updating another system, to run in the background so your receiver can respond quickly.

The same webhook can arrive more than once. Its webhook-id header, a value sent alongside the message, identifies the delivery and stays the same when that message is sent again. Keep track of IDs you’ve processed so receiving one again doesn’t repeat the business action. This is called deduplication.

For example, receiving the same delivery update twice should not add the same attachment to an order twice. Test this separately from preventing duplicate fax sends: checking a repeated update does not tell you whether an uncertain send request should be submitted again.

5. What to test before switching fax providers

Start with documents containing no customer or sensitive information and send them only to agreed test numbers your team controls. Confirm the setup and any charges before testing. If you previously used a sandbox, an isolated environment for testing without normal production activity, check what testing arrangement is available here rather than assuming it works the same way.

Keep a result for each test, including the document type, controlled destination, expected behavior, observed behavior, and unresolved issue. Fix failed acceptance checks before widening the rollout.

Where your workflow needs a confirmation document, Fax.Plus provides a PDF confirmation report endpoint. Verify the report your application retrieves and how it is stored. A transmission result is not proof that a person reviewed or accepted the document.

6. Plan when your existing fax numbers will move

Number porting transfers your existing number from one provider to another so people can keep using it to reach you. If you want to keep your numbers, begin by checking whether they can be ported. Follow the current Fax.Plus porting process, including the required account details and authorization documents.

Keep your current line active until Fax.Plus confirms that the port is complete. Canceling first can prevent the transfer and put the number at risk.

The porting process describes how a temporary number lets you start faxing while the transfer is pending. Use it to test your receiving workflow before the transfer. Confirm which number will be replaced, particularly if the account has multiple numbers. Then check that incoming faxes reach the right place again after the port completes.

Plan the application change and number transfer together, but track them separately. A working API integration does not mean the number has moved. Likewise, a completed port does not prove that your application's receiver and routing rules are correct.

Before setting a switch date, confirm the porting arrangements and agree on what you’ll do if a check fails. Developers sometimes call returning to the previous setup a rollback. Changing an application setting back, however, won’t automatically move a ported number back to its old provider. Plan the recovery options for your software and your numbers separately.

7. Check unfinished work before closing the old integration

When you start routing production work through Fax.Plus, keep a clear boundary between jobs submitted to the old provider and jobs submitted to the new one. Do not send the same production document through both providers merely to compare results.

When you switch, make a list of unfinished sends, scheduled jobs, unresolved failures, and incoming documents that still need processing. Compare that list with both providers’ records. This reconciliation helps you spot work that might otherwise be missed or sent twice. If a send’s outcome is uncertain, check its record before trying again through the other provider.

Review the first production transactions against your acceptance checks. Track symptoms that matter operationally: unprocessed inbound documents, missing final statuses, unreadable pages, repeated actions, and discrepancies between your application and provider records.

Once the checks pass, account for unfinished work, save the records you need, and confirm that any number transfers are complete. Then follow your agreed plan to close the old service. Disable credentials you no longer use and remove old webhook destinations so they don’t remain active unnecessarily.

Plan your move to Fax.Plus

Start with one workflow your team understands well. List what it needs to do, agree on the checks that will show it works, and use the Fax.Plus API quickstart for the implementation steps.

If you’re still evaluating your options, our Fax.Plus API page explains the service and how to get in touch. Bring your workflow, expected usage, and number requirements to that conversation so you can plan the move around what your team actually needs.