Status 

Idempotency-nøgleunderstøttelse er delvis i dag. Udvalgte interne retry-mutationer — for eksempel order-billing retry- og refund-billing retry-flows — accepterer allerede en idempotency-nøgle og bruger den til at deduplicere downstream betalingsprocessor-kald. Der er endnu ikke et standardiseret idempotencyKey-argument på tværs af alle kundevendte create-mutationer på Zonos Graph; det er på roadmap. Indtil det er tilgængeligt, brug mønstrene nedenfor for at holde mutationer sikre at gentage.

Sikre som standard-mutationer 

Nogle mutationer er naturligt idempotente, fordi de upserter efter en stabil identifikator, du angiver. Når du kalder disse med samme input, er resultatet det samme — der er ingen risiko for at oprette dubletter.

• Mutationer, der tager en unik merchant-leveret identifikator (for eksempel en order externalId), returnerer den eksisterende post ved et gentaget kald i stedet for at oprette en ny.
• Read-only operationer (queries) er altid sikre at gentage.

Når du kan tilknytte din egen stabile identifikator til den ressource, du opretter, foretræk den vej.

Mønstre for mutationer, der ikke er naturligt idempotente 

For mutationer, der opretter ressourcer uden en merchant-leveret nøgle, behandl dem som højst én gang fra din side:

1. Gem anmodningen før afsendelse. Skriv en række i din egen database (status pending) før netværkskaldet.
2. Send mutationen. Ved succes registrer det returnerede ressource-id mod din pending-række (status committed).
3. Ved netværksfejl, gentag ikke blindt. Forespørg Zonos Graph for at afgøre, om ressourcen blev oprettet (for eksempel ved at liste ressourcer oprettet inden for de seneste minutter for din konto, eller ved at forespørge efter en relateret ressource, du kan korrelere). Gentag kun, hvis du kan bekræfte, at ressourcen ikke er til stede.
4. Brug en unik constraint i din egen database på den forretningsnøgle, der repræsenterer anmodningen, så en duplikeret gentagelse fra din egen applikation ikke kan dobbeltindsende.

Webhook-levering er mindst én gang 

Når du modtager Zonos webhooks, design handlers til at være idempotente — den samme hændelse kan leveres mere end én gang. Deduplicer efter hændelses-id. Se Webhooks for hændelses-id-feltet.

Hvor platformen er på vej hen 

Den underliggende platform kører allerede idempotency-nøgle-flows i produktion til billing retries: nøglen afgrænser et retry-forsøg og forhindrer duplikerede betalingsprocessor-kald. Vi arbejder på at eksponere det samme mønster som et valgfrit idempotencyKey-argument på kundevendte create-mutationer. Når det angives, returnerer Graph det oprindelige svar for ethvert efterfølgende kald med samme nøgle inden for et opbevaringsvindue. Denne side opdateres, når overfladen er generelt tilgængelig.

Hvis standardiserede idempotency-nøgler på kundevendte mutationer blokerer din integration, kontakt support.