Prepare the AhaSend Account
Verify the sending domain and create a domain-scoped send-only v2 key or SMTP credential. Keep the old provider active while you test. Record your existing templates, headers, tracking choices, sender addresses, jobs and suppression rules so you can compare behavior.Map the API Fields
Use the AhaSend Create Message endpoint with v2 authentication. This is a field mapping from Resend’s send API, not a drop-in change of base URL.
AhaSend Create Message returns HTTP 202 with a result for each recipient; check each
status, including error, instead of treating the request as all-or-nothing. Follow send examples for an actual sandbox call. Keep a stable business-event idempotency key with an unchanged payload and separate keys for sandbox and live work. Review schedule limits before moving future jobs.
Replace the SMTP Settings
Replacesmtp.resend.com, username resend and its API-key password with AhaSend’s host and separate SMTP credentials. Use STARTTLS instead of carrying over an implicit-TLS configuration. See Resend’s SMTP guide.
See SMTP settings for all hosts, ports, TLS requirements and limits. Keep your existing mail library and change its transport configuration; use the language examples to test.
Map Events by Meaning
These are the closest matching outcomes, not identical payloads or a guaranteed one-to-one event sequence. Keep the provider name with each saved message ID while both systems are active. See Resend’s event documentation and the AhaSend event list.
Create a separate AhaSend webhook configuration and replace the old verification code with AhaSend signature checks. Parse AhaSend’s payload shape, deduplicate by its delivery header, and acknowledge verified unknown event types with 2xx. Do not reuse the old provider’s signing secret, retry assumptions or event IDs.
Export the Old Recipient Blocks
Open Resend’s Suppressions page and choose Download CSV, as described in Resend’s suppression guide. Preserve each address and its reason, including manually added blocks. Resend suppressions apply across the team’s domains: copy each required block to every AhaSend sending domain it must cover, and keep the team-wide rule in your application. Include contact unsubscribes separately: a contact preference and an email suppression are different records. Compare the export with saved bounce/complaint events and your application’s opt-out records before switching.Import Suppressions Before Switching Traffic
Export blocked addresses using the old provider’s options described above. Include hard bounces, complaints, unsubscribes and application-level opt-outs; deduplicate by address and sending domain without losing the reason. Keep the original export and your application’s durable preferences. A provider change is not permission to mail an opted-out address again. Normalize the export into a CSV withemail,domain,reason,expires_at columns. domain is the AhaSend sending domain, not the recipient’s domain. This sample row is a format template; replace both placeholders. Select an expiry that preserves your block policy, and keep permanent opt-outs blocked in your own app beyond that time. See suppression durations.
suppressions.csv
AHASEND_ACCOUNT_ID and AHASEND_IMPORT_KEY, a separate full API key with suppressions:write. This is a real management operation: sandbox mode does not apply to suppressions. First test with a unique address on your test sending domain, then verify it with List Suppressions.
Save the following as import_suppressions.py. It validates the whole CSV before making changes and stops on the first failed request. It requires an explicit domain so an empty cell cannot broaden the import to all domains.
import_suppressions.py
python import_suppressions.py suppressions.csv. An existing suppression can return 409: compare its domain, reason and expiry before deciding what to do. Do not delete it just to make the import pass. A stopped run may have imported earlier rows, so keep the progress output and reconcile uncertain requests. Exact retries reuse a stable idempotency key; after its time limit, verify existing records before retrying. Keep imports within API rate limits.
Switch Traffic in Small Steps
- Verify the AhaSend domain and leave the old provider’s required DNS in place while it still sends. Test the new code in sandbox mode, including failure and suppression paths.
- Keep your message templates in your app or adapt them explicitly. Provider template IDs, recipient lists, request IDs and signing secrets do not transfer to AhaSend automatically.
- Import suppressions, then update your saved recipient preferences. Repeat the export/import for changes made since the initial snapshot before moving each traffic group.
- Route each new job to exactly one provider. Keep that choice, the saved payload and your application event ID with the job so a retry cannot silently switch providers and duplicate it.
- Move a small group of expected mail, compare acceptance, bounces and delivery delays, and increase only when results remain stable. Follow deliverability and warm-up guidance.
- Keep receiving old-provider events for in-flight messages. If you roll back, route only new unsent jobs back and preserve all new suppressions. Retire old credentials, DNS and event handlers after old work has finished.

