2026-10-27: 7 API-klachten die we vandaag hoorden

Klachten die Engelstalige ontwikkelaars tussen 25 en 27 okt. 2026 openbaar plaatsten, hieronder in eigen woorden samengevat, met links naar de oorspronkelijke berichten. Elk antwoord gebruikt alleen wat de openbare website en documentatie van PoYo nu zeggen en verwijst naar de pagina waar het vandaan komt. Waar de documentatie iets niet behandelt, zeggen we dat.

---

Q1. Het nieuwe snelle model is zo snel dat het zichzelf een 429 bezorgt, vooral bij maximale redenering en parallelle Codex-sessies.

Waar ontwikkelaars over klagen: GPT-6.1 Terra werd gelanceerd als een snelle, goedkopere laag voor computergebruik, en meteen kregen bouwers HTTP 429 bij Terra / de snelle modus en bij maximale redenering, terwijl dezelfde prompt op Sol gewoon werkte. Meerdere berichten merkten op dat er bij een 429 nul tokens waren verbruikt, wat betekent dat een gelijktijdigheids- of rate-limitpoort aansloeg vóór de meting. Parallelle Codex-sessies die dezelfde sleutel pollen maakten het erger.

Zo antwoordt PoYo: Onze pagina met foutcodes geeft 429 één betekenis, rate_limit_error, en één aanbevolen actie: wacht voordat je het opnieuw probeert, of zet verzoeken in de wachtrij. Getting Started publiceert de standaardlimiet voor generaties: maximaal 20 nieuwe generatieverzoeken per 10 seconden, per account. Verzoeken boven die limiet krijgen HTTP 429 en komen niet in de wachtrij. Chat- en mediamodellen delen één PoYo-sleutel en staan in llms.txt, dus van model wisselen is alleen een andere model-string, geen nieuwe onboarding bij een andere leverancier. Als je steeds 429's krijgt, mag je volgens de documentatie contact opnemen met support voor een hogere limiet; aanvragen worden voorzichtig beoordeeld.

De documentatie beschrijft geen automatische failover tussen aanbieders. Bouw dus zelf een terugvaloptie in je client. Getting Started zegt ook dat de "algehele stabiliteit van PoYo iets lager kan liggen dan bij de officiële aanbieders".

---

Q2. Mijn "429" bleek een bestedingslimiet: factureringsfouten vermomd als rate limits.

Waar ontwikkelaars over klagen: Eén bericht vatte het zo samen: HTTP 429 is niet één soort fout. Bij Anthropic kan het een rate limit, een versnellingslimiet of een bestedingsplafond betekenen, en een 429 door een bestedingsplafond heeft vaak geen Retry-After, dus eindeloos wachten helpt niet. Teams behandelen een harde factureringsstop steeds weer als een vertraging.

Zo antwoordt PoYo: PoYo houdt de twee gevallen in de tabel met foutcodes duidelijk gescheiden:

De facturering zelf werkt met vooruitbetaalde credits: de homepage noemt eenmalige aankopen zonder terugkerende abonnementen, en credits verlopen nooit. Poll GET /api/user/balance voor credits_amount als je een actueel getal nodig hebt (gebruikerssaldo). De tip bij de foutcodes is duidelijk: houd je credits in de gaten om 402's tijdens kritieke taken te voorkomen.

---

Q3. Mijn agent-SDK verbruikt het rate-limitvenster ~1,7× sneller dan chat, en N agents delen nog steeds één limiet.

Waar ontwikkelaars over klagen: Anthropic erkende een bug in de Agents SDK waardoor de 5-uurslimieten van Claude ongeveer 1,7× sneller opgingen dan verwacht bij het overschakelen van chat naar agentmodus. Daarnaast merkten bouwers op dat worktrees bestandsconflicten oplossen, maar tien agents nog steeds één database en één API-rate limit delen, zodat parallelle harnesses elkaar op dezelfde sleutel in de weg zitten.

Zo antwoordt PoYo: Generatie bij PoYo is asynchroon opgezet, dus lange taken zijn niet gebonden aan één gateway-timeout. Getting Started en het API-overzicht zeggen: dien een taak in, bewaar de task_id, en poll daarna de status of ontvang een webhook. Voor productieworkloads geeft de documentatie de voorkeur aan ondertekende webhooks boven veelvuldig pollen. Bij een 429 wacht je of zet je in de wachtrij (foutcodes); de standaardlimiet voor generaties blijft 20 nieuwe verzoeken per 10 s per account, waarbij overschrijdingen worden geweigerd en niet in de wachtrij komen.

Om te voorkomen dat één op hol geslagen agent het hele account leegtrekt, gebruik je de instellingen die op de API-sleutelpagina en in Getting Started staan: gebruikslimieten per sleutel, per uur, per dag en in totaal. Afbeeldingen, video, muziek, chat en 3D zitten achter één uniforme API-sleutel (llms.txt, homepage).

De documentatie beschrijft geen automatische failover tussen aanbieders. Je client moet 429 / 5xx zelf afhandelen en het volgende model of de volgende route kiezen.

---

Q4. Weer een SaaS-bedrijf kreeg mijn AI-sleutels, en de leverancier zei dat het onbevoegde verbruik niet wordt terugbetaald.

Waar ontwikkelaars over klagen: Een ontwikkelaar meldde een gehackte Anthropic API-sleutel waarmee $105.94 aan onbevoegd gebruik was opgebouwd; support (via een AI-agent) zei dat verbruikt gebruik niet wordt terugbetaald en sloot de escalatie. In hetzelfde venster van 48 uur doken steeds inbraken op in de stijl van OpenCode Console / Railway, waarbij opgeslagen OpenAI-, Anthropic- en Google-sleutels de buit waren: eerst roteren, dan een hard bestedingsplafond instellen.

Zo antwoordt PoYo: Roteer eerst: een gelekt geheim blijft een gelekt geheim. Daarna noemt onze documentatie instellingen die beperken wat iemand met een gestolen PoYo-sleutel kan doen:

• IP-whitelist. Sta op een sleutel alleen je goedgekeurde server-IP's toe, zodat een sleutel die uit een omgevingsvariabele is gekopieerd niet werkt vanaf de machine van de aanvaller. Zie de API-sleutelpagina en Getting Started.
• Gebruikslimieten per sleutel (per uur, per dag en in totaal), zodat één sleutel een hard plafond heeft voordat jij iets merkt.
• Blokkeren per eindgebruiker. Stuur een X-End-User-ID-header en je kunt één misbruikende aanroeper op een sleutel blokkeren zonder die te roteren. Een geblokkeerde ID krijgt HTTP 403 met end_user_blocked. Zie Identificatie van eindgebruikers.

Onze openbare documentatie belooft geen terugbetaling voor gebruik met een gelekte sleutel. Denk je dat een PoYo-sleutel is misbruikt, trek hem dan in en neem contact op met support ([email protected]).

---

Q5. Een AI-client moet weten wanneer hij niet opnieuw moet proberen, en bij video kan een nieuwe poging de rekening ongemerkt verdubbelen.

Waar ontwikkelaars over klagen: Nieuwe pogingen helpen bij tijdelijke storingen, maar niet altijd. Als een verzoek foutief is opgebouwd, een inloggegeven ongeldig is of een model voor het account niet beschikbaar is, vergroot dezelfde aanroep herhalen alleen de druk. Bij video-API's keert hetzelfde thema terug als "druk op opnieuw en je maakt misschien een tweede betaalde taak aan".

Zo antwoordt PoYo: Koppel de fout aan de actie in de foutcodes:

• 402 insufficient_credits_error → opwaarderen. Niet opnieuw proberen.
• 429 rate_limit_error → wachten of in de wachtrij zetten.
• 500 / 502 / 503 → exponentiële backoff.
• 401 → herstel de sleutel; hetzelfde foute inloggegeven opnieuw proberen helpt niet (Getting Started).

Getting Started waarschuwt ook: behandel elke nieuwe poging als mogelijk nieuw betaald werk; controleer of het oorspronkelijke verzoek een taak heeft aangemaakt voordat je opnieuw indient. Voor media staat in llms.txt en op de homepage dat mislukte taken niet worden berekend en dat er per geslaagde uitvoer wordt gefactureerd, tegen een prijs per model. Gebruik liever callback_url / webhooks dan agressief de status te pollen, zodat je de belasting tijdens het wachten niet vermenigvuldigt (API-overzicht).

---

Q6. API-prijzen voelen nog steeds belachelijk duur naast het abonnement, en ik zie het actuele saldo niet voordat de agent het opmaakt.

Waar ontwikkelaars over klagen: Eén reactie zei het ronduit: abonnementen voelen gesubsidieerd, maar de API-prijzen van OpenAI en Anthropic zijn "belachelijk duur". Andere berichten in hetzelfde venster vroegen of mensen wel weten wat één multi-agentprompt kost tegen API-tarieven, en herinnerden bouwers eraan dat de tellers van ChatGPT- / Codex-abonnementen en de API-tellers niets van elkaar weten.

Zo antwoordt PoYo: Drie gedocumenteerde onderdelen sluiten hierop aan:

1. Vooruitbetaalde credits, geen abonnementsteller. De homepage beschrijft prijzen op basis van credits met eenmalige aankopen, zonder terugkerende abonnementen, en credits die nooit verlopen. Je betaalt voor geslaagde generaties; mislukte taken worden niet berekend (llms.txt).
2. Eén sleutel, één saldo. Chat en media delen één PoYo-account. Poll GET /api/user/balance voor credits_amount (gebruikerssaldo).
3. Gepubliceerde prijzen per model. De actuele prijzen staan op elke modelpagina / https://poyo.ai/models/<id>/llms.txt en in de catalogusindex (llms.txt). Raadpleeg die voordat je betaald werk indient en leid dollarbedragen niet af uit je geheugen. Met de takengeschiedenis (beschreven in Getting Started) kun je achteraf model, invoer en status bekijken.

---

Q7. Mijn "serverfunctie" / Telegram-bot kan door iedereen worden aangeroepen, en de sleutel staat waar curl hem kan vinden.

Waar ontwikkelaars over klagen: Er bleven praktische beveiligingsberichten verschijnen: beperk API-sleutels en stel een dagquotum in; plak aanbiedersleutels niet in chatinterfaces of Telegram-agents; een sleutel in een aanroepbare serverfunctie zonder rate limit per gebruiker en bestedingsplafond is een creditcard voor wie de URL vindt.

Zo antwoordt PoYo: Getting Started is duidelijk: zet je API-sleutel nooit in frontendcode (browser, mobiele apps, openbare repositories). Behandel de sleutel als een geheim, bewaar hem op je server en gebruik de instellingen die al voor productiesleutels zijn gedocumenteerd:

• IP-whitelist en limieten per sleutel per uur / dag / in totaal op de API-sleutelpagina.
• Vereis X-End-User-ID en blokkeer daarna een misbruikende aanroeper met HTTP 403 end_user_blocked, zonder de hele sleutel te roteren (Identificatie van eindgebruikers).
• Handel 401, 402 en 429 expliciet af voordat je live gaat (Getting Started, foutcodes).

---

Snel overzicht