Delivery semantics

Tecron’s public send path is at-least-once, not exactly-once.

What “queued” means

Accept returns 202 and persists a message (or broadcast recipients) before Graph completes. Downstream workers call WhatsApp Cloud API asynchronously.

Residual double-send window

If the worker process crashes after Meta’s Graph API has accepted the send but before we persist the WhatsApp message id (wamid), a later retry of that job can produce a second WhatsApp message to the same recipient.

Intent-key / AUTHENTICATION-category retry paths may retry after ambiguous Graph failures.
MARKETING / UTILITY paths fail closed rather than retrying blindly in some cases — the Redis-loss residual can still exist.

Design your product for at-least-once: prefer idempotent customer-facing effects, and do not assume one Tecron accept equals one WhatsApp bubble forever.

Dashboard Resend

In API Logs, Resend uses a new idempotency key. It is a duplicate send (a new Graph attempt), not a replay of the original Graph HTTP call.

Broadcast `retry-failed`

POST /v1/broadcasts/{id}/retry-failed sends again to eligible failed recipients. It is not a no-op replay of the original Graph POSTs. It also consumes daily quota (INCRBY by the number of rows retried).

Idempotency-Key on accept