Idempotency key on inbox message sends

The problem

POST /v1/inbox/conversations/{conversationId}/messages has no idempotency support. When a send times out client-side, the outcome is genuinely unknown: the request may have reached Meta and delivered, or not. There is no way to tell from the client.

That makes retrying unsafe. If the original did go through, the retry delivers the same message to the customer a second time. Support confirmed the endpoint has no idempotency or dedup today, and mentioned another user who hit this as a quadruple video send.

This is not hypothetical for us. We run a WhatsApp assistant on Vercel with a 30s client timeout, and we had three sends abort at 30s in a single day. We got lucky and none of them had actually been delivered, but that was luck, not design.

Why it matters more here than elsewhere

A duplicate on most endpoints is an annoyance. On WhatsApp it is a message that a real customer receives twice from a business, and it cannot be taken back. For anyone building automated replies, an unsafe retry is worse than no retry, which pushes you toward dropping messages instead.

Our current workaround, and why it does not generalise

Before retrying, we list the recent messages of the conversation and look for our own text among the outgoing ones, scoped to after the inbound message we are replying to. It works, but it costs an extra API round trip on every retry; it matches on message text, which is fragile, since identical replies are normal (the same question produces the same answer) and the time window ends up doing a lot of load-bearing work; and it only works for text, with no equivalent for media sends, which is exactly the case that reportedly produced the 4x delivery.

What we are asking for

Accept an Idempotency-Key on inbox message sends, with the same semantics you already have on /v1/posts, SMS and calls: a replay within the retention window returns the original response instead of sending again. This is a parity request more than a new concept.

Related, lower priority

A way to opt out of waiting, so a slow upstream returns a fast error instead of holding the connection open, would also help. But idempotency is the one that actually makes a client-side retry safe, and it is worth more than the fast fail on its own.