En stor mængde parallelle requests gør ikke et økonomisk flow mere pålideligt; den kan skabe flere ukendte udfald og gøre et adgangsstop sværere at håndtere.
Konkrete grænser
Hver app og organisation har 120 API-kald pr. minut. Ved overskridelse svares 429 rate_limited. Miljøerne er adskilt. Lister returnerer højst 100 poster pr. side, og domænepayloads må højst være 256 KiB. Disse tal er tekniske grænser for partner-API'et, ikke et abonnement eller et løfte om gennemløb.
App Console har desuden kvoter for arbejdsrum, apps, invitationer og aktive credentials. De begrænser registreringsobjekter og skal ikke forveksles med bogføringskvoter. Sandbox-tokens gælder 1 time, og der kan højst være 10 aktive. Client secrets gælder 90 dage, og der kan højst være 2 aktive pr. app. Se forbrug for de konkrete enheder og afgrænsninger.
Ved HTTP 429
Grænsen tælles i hele kalenderminutter. Svaret har ingen Retry-After-header; vent til det næste minut, før du prøver igen. Fordel klienternes genforsøg med tilfældig forsinkelse, så alle ikke rammer samme sekund efter pausen.
Hold retry-antallet og den samlede ventetid begrænset. En baggrundskø skal kunne parkere en operation og gøre problemet synligt for drift, når grænsen vedvarer. Et endeløst retry-loop er ikke en recoverymekanisme.
Hvilke fejl der kan genforsøges
Netværksfejl og visse midlertidige serverfejl kan kræve et genforsøg. Ved en skriveoperation med muligt ukendt udfald bruges samme idempotensnøgle og samme input. Ved 400, 403 eller en kendt domænefejl er et uændret genforsøg normalt ikke løsningen; input eller rettighed skal først afklares.
Et 401 betyder heller ikke "prøv igen hvert sekund". Kontrollér tokenudløb og refresh-flow. Flere samtidige workers må ikke rotere det samme refresh-token parallelt. Replaybeskyttelsen kan i så fald tilbagekalde tokenfamilien, fordi genbrug af en gammel rotationsværdi er et sikkerhedssignal.
Begræns parallelismen efter opgaven
Hold handlinger mod samme forretningsobjekt i en kontrolleret rækkefølge. En fakturakladde skal eksempelvis være oprettet, før dit system gemmer dens Hours-reference som en eksisterende ressource. Start ikke relaterede handlinger samtidig blot for at spare en netværksrunde.
Uafhængige operationer kan køres i et lille, begrænset antal workers. Hver worker skal have egen timeout, korrelationsreference og mulighed for at blive stoppet ved tilbagekaldt adgang. Mål kølængde, ventetid og fejlrate, før du øger parallelismen.
Minutkvoten er ikke hele misbrugsbeskyttelsen
Minutkvoten ligger i det transaktionelle domæneforløb. Fejl, der ruller en transaktion tilbage, kan også rulle dens tællerændring tilbage. Den er derfor ikke alene et komplet værn mod ugyldige tokens, syntaktisk forkerte requests, loginmisbrug eller store forbindelsesrater.
En offentlig installation skal have særskilt ingress- og identitetsbeskyttelse: forbindelsesgrænser, requeststørrelse, loginbeskyttelse og en passende politik for fejlslagne kald. Disse kontroller konfigureres på installationens reverse proxy og erstattes ikke af kvoten.
Drift uden payloadlækage
Registrér antal requests, statusgrupper, latenstid, app-ID og miljø. Undgå at gemme tokens eller komplette regnskabspayloads i målingssystemet. En række med beløb og kundebeskrivelse kan være følsom, selv om den ikke indeholder et bankkontonummer.
Se fejl for eskalering og idempotens for usikre netværksudfald. En korrekt retrystrategi bør være dokumenteret og testet, før integrationen får endeligt bogføringsmandat.