ForwardForwardEmail routing console
Step-by-step guide

How to Automate Domain Email With the Forward API

A practical walkthrough with clear setup, verification, and common mistakes to avoid. Learn how to use the Forward API to automate domains, aliases, routing workflows, and forwarding log checks with Bearer API keys.

2026-07-17·Forward Team·8 min readIntegration

email forwarding APIdomain email APIautomate email aliasesForward API

When the API is worth using

Use the API when domain and alias setup is part of a repeatable workflow: onboarding a client, provisioning a new brand, syncing an internal system, or checking delivery without opening the dashboard.

Forward API access is available on Creator, Pro, and Business. The base URL is https://forward.redsols.com/api and requests use JSON.

  • Provision domains during onboarding
  • Create standard aliases such as hello@ and support@
  • Update destinations when ownership changes
  • Read forwarding logs during support investigations

Create and protect an API key

Create a key from Dashboard, then copy it immediately because the secret is shown once. Send it with every request as a Bearer token in the Authorization header.

Treat the key like a production credential: keep it in a secret manager, never commit it to source control, rotate it when ownership changes, and delete unused keys.

  • Header: Authorization: Bearer fwd_...your_key...
  • Create: POST /api-keys
  • List: GET /api-keys
  • Delete: DELETE /api-keys/{key_id}

Provision a domain and alias

Create the domain first, save the returned domain ID, and publish the DNS records shown by the product. Verify the domain before treating it as active.

Once the domain is ready, create an alias with a local part, destination list, enabled state, and optional catch-all behavior. Keep the payload deterministic so rerunning your workflow does not create confusing duplicates.

  • Create domain: POST /domains
  • List domains: GET /domains
  • Verify domain: POST /domains/{domain_id}/verify
  • Create alias: POST /domains/{domain_id}/aliases
  • List aliases: GET /domains/{domain_id}/aliases

Manage changes and debug delivery

Use PATCH when a destination or enabled state changes, and DELETE only after your system has recorded the replacement configuration. Keep the Forward object IDs in your own database so updates are explicit.

When a user reports missing mail, fetch the forwarding logs before changing DNS or recreating an alias. Logs provide a faster first check for whether the message reached the routing layer.

  • Update alias: PATCH /domains/{domain_id}/aliases/{alias_id}
  • Delete alias: DELETE /domains/{domain_id}/aliases/{alias_id}
  • Read logs: GET /logs?limit=50
  • Handle 409 when a domain is already verified
  • Handle 401 or Invalid token without retrying blindly

Build a safe automation loop

A reliable integration is idempotent at the workflow level: look up the domain, match the alias by local part, create only when missing, and update destinations when the desired state changes.

Add retries only for transient network failures. Do not retry authentication errors, domain-limit errors, or invalid payloads without correcting the request first.

  • Store domain and alias IDs
  • Compare desired and current destinations
  • Back off on temporary 5xx responses
  • Log request IDs and response details without logging API keys
  • Delete or rotate keys during offboarding

Bottom line

The API is most valuable when email setup becomes part of another system's workflow. Keep the desired state in your application, use Forward for routing, and make every change traceable.

Start with one domain and one alias, verify the complete inbound flow, then expand the automation to client or brand provisioning.

Try Forward free