React & Next.js email
Handle email API failures without sending duplicate messages
Track each intended email and distinguish a rejected request from an uncertain timeout.
When an email request times out, you do not necessarily know that it failed. The provider may have accepted the message before the connection broke. Reliable retries start with a record of the intended email, not a loop that resends every exception.
Give each business event a stable identity, such as booking-482-confirmation. Store that identity before sending and enforce uniqueness in your database. This application record is useful even when a provider has its own idempotency feature; do not assume such a feature exists without checking the API contract.
| Outcome | Meaning | Next action |
|---|---|---|
| Invalid credential or sender | Configuration rejected | Fix configuration; do not retry in a tight loop |
| Explicit temporary rejection | Request was rejected temporarily | Retry according to documented guidance with a limit |
| Timeout after submission | Acceptance is uncertain | Reconcile before sending again |
| Accepted, then permanently bounced | Sending succeeded but recipient delivery failed | Record the failure and resolve the recipient problem |
Build a small delivery state machine
- 1
Create the event record
Save the business event, recipient reference and template version. Use a unique constraint so two concurrent workers cannot create two intended sends for the same event. Keep credentials and reset tokens out of this record.
- 2
Claim the job atomically
Only one worker should own a send attempt at a time. Record attempt time and status. Use a durable queue or database lease appropriate to your stack, not only a variable in server memory.
- 3
Save the provider result
When Venmail accepts the message, store the returned identifier. Separate accepted from delivered. If the connection outcome is unknown, mark it for reconciliation instead of reporting a certain failure.
- 4
Process updates once
If using delivery webhooks, verify their authenticity with the account's documented mechanism and deduplicate event processing. Delivery events can arrive more than once or out of order.
- 5
Test interruption
Simulate a worker stopping after submission but before saving the response. Check that recovery does not blindly send a duplicate. Define a manual review path when the provider cannot resolve an uncertain attempt.
You can exercise most of this logic for free with a test database and local mail capture. The important design choice is persistence across failures, not the number of retry attempts.
You can build and test this workflow with free software. For live sending, check API or SMTP access and the sending allowance in your Venmail account; the public Free workspace offer is not a promise of a free production API quota. Venmail, Venmail
Retry readiness
- Business events have stable unique IDs
- Jobs are claimed atomically
- Unknown outcomes stay distinct
- Provider IDs are saved
- Crash recovery is tested
Ready for the next practical step?
Explore Venmail for your email workflow. Check the free features, account limits and integrations that fit your next step.
Explore Venmail's free planRelated practical guides
Send email from a React contact form: the safe pattern
Keep the form in React and put validation, abuse controls and Venmail credentials on the server.
Read the guideSend your first Venmail test email from Node.js
Use a small server-side script to verify credentials and a sender before connecting a React app.
Read the guideSources and review method
Venmail publishes this guide and may be one of the products discussed. We compare providers on consistent dimensions, link to primary documentation and state non-fit cases. Product limits and pricing should be rechecked before purchase.