Avoiding duplicate sends
Operations
What to do when your agent retries a send and you're not sure whether the first one went through.
The scenario
Agent calls POST /send. The response times out. Did the message go or not? Naive retry risks sending twice.
What the API gives you today
Every sent message has a unique messageId returned in the response. You can cross-check by listing recent outbound messages:
curl "https://myagentmail.com/v1/inboxes/$ID/messages?direction=outbound&limit=10" \
-H "X-API-Key: ak_..."
Scan the results for a matching subject and to within the last few seconds. If it's there, your first send succeeded — don't retry.
What's coming
A first-class Idempotency-Key header is on the roadmap. Send the same key twice and the second call returns the first call's response without sending again. If that's blocking you, let us know.
Design advice until then
- If a
POST /sendcall times out or returns a 5xx, don't retry immediately. List recent messages first to check whether the send went through. - For agent flows where duplicates are catastrophic (e.g. sending contracts), use drafts as a staging step. An agent can't accidentally send a draft twice — the second
POST /drafts/{id}/sendcall returns a 404 because the first one deleted the draft.