[New] Integration / API: No Idempotency-Key support on any POST endpoint — unsafe retries on writes

Area: Integration / API (audit p13) · Surface: mobieusAPI · Dimension: competitor-gap · Severity: major

Stripe, Zendesk, and Intercom all accept an Idempotency-Key header so a client that times out and retries a POST doesn't create duplicate tickets, enrollments, or charges. Without it, any network blip on a create call risks double-enrolling a learner or filing duplicate tickets, and integrators have no safe retry primitive. This is table stakes for a production API and is cheap to add given the existing rate_limits-style keyed table pattern.

Evidence

`grep -rn "Idempotency|HTTP_IDEMPOTENCY" platform/src/` finds zero references in middleware or controllers (only unrelated business-logic comments). POST write endpoints that create money/records — HelpdeskController@createTicket (line 188), HelpdeskController@replyToTicket (257), LearnController@enrollmentsCreate (238), WebhooksController@create (37) — read the body and insert unconditionally with no dedup key.

Suggested fix. Add an ApiIdempotencyMiddleware that, when an Idempotency-Key header is present on a POST, hashes (key + api_key_id + path + body) and short-circuits to the stored prior response within a 24h window; persist in a new api_idempotency_keys table mirroring the rate_limits design.

Filed by the automated tenant-app audit and adversarially evidence-verified. Status: verified. Open — not yet actioned.