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.
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