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

Klachten die Engelstalige ontwikkelaars tussen 24 en 26 okt. 2026 openbaar plaatsten, hieronder geparafraseerd, met links naar de originele berichten. Elk antwoord gebruikt alleen wat de openbare site en documentatie van PoYo nu zeggen en linkt naar de pagina waar het vandaan komt. Waar de documentatie iets niet behandelt, zeggen we dat.

---

Q1. Alweer een SaaS gehackt, en mijn AI-API-sleutels gingen mee.

Waar ontwikkelaars over klagen: Bij een bekende SaaS-inbraak lekten AI-API-sleutels massaal uit en werden ze gebruikt voor frauduleus verkeer. Daarnaast meldden mensen een lek van OpenAI-API-sleutels dat met Railway samenhing, en een ontwikkelaar kreeg een mail van OpenAI over een gelekte sleutel die niet eens van hem was. Fouten in de frontend maken het steeds erger: API-sleutels die in de browser zichtbaar zijn, blijven een veelvoorkomende fout.

Zo antwoordt PoYo: Vervang eerst de sleutel: een gelekt geheim blijft een gelekt geheim. Daarna staan in onze documentatie instellingen die beperken wat 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 pagina met API-sleutels en Aan de slag.
• Gebruikslimieten per sleutel (per uur, per dag en in totaal), zodat één sleutel een harde bovengrens heeft voordat jij het merkt.
• Blokkeren per eindgebruiker. Stuur een X-End-User-ID-header mee en je kunt één misbruikende aanroeper op een sleutel blokkeren zonder de sleutel te vervangen. Een geblokkeerd ID geeft HTTP 403 met end_user_blocked terug. 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]).

---

Q2. Als mijn modelleverancier de app uitbrengt waar ik mee concurreer, is mijn rate limit het eerste dat het begeeft.

Waar ontwikkelaars over klagen: Een bouwer zei het botweg: als je API-leverancier ook het product uitbrengt waar je mee concurreert, is de rate limit het eerste dat het begeeft. Reddit-threads stellen steeds dezelfde praktische vraag: hoe mensen in productie omgaan met de rate limits van de Claude API en welke aanpak werkt bij rate limits van AI-aanbieders.

Zo antwoordt PoYo: Onze pagina met foutcodes geeft elke status één betekenis en één aanbevolen actie:

Aan de slag publiceert de standaardlimiet voor generatie: 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 een wijziging van de model-string en geen onboarding bij een nieuwe leverancier. Loop je steeds tegen 429's aan, dan kun 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 een fallback in je client. In Aan de slag staat ook dat de "algehele stabiliteit van PoYo iets lager kan liggen dan die van de officiële aanbieders".

---

Q3. Mijn "429" was eigenlijk een bestedingslimiet: factureringsfouten in de kleren van een rate limit.

Waar ontwikkelaars over klagen: Harde bestedingsplafonds van OpenAI kunnen als 429 verschijnen met project_spend_limit_exceeded / organization_spend_limit_exceeded, waardoor teams een factureringsstop behandelen als throttling. Bij video-API's merkte een ontwikkelaar op dat 402 betekent dat er te weinig quota is om het bedrag te reserveren, terwijl 409 het idempotentiegeval is. Een andere herinnering was praktisch: stel een bestedingslimiet in, zodat een lus of een vreemde met curl je hoe dan ook dezelfde rekening bezorgt.

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

De facturering zelf werkt met vooruitbetaalde credits: de homepage zegt eenmalige aankopen zonder terugkerende abonnementen, en credits die nooit verlopen. Poll GET /api/user/balance voor credits_amount als je een live getal nodig hebt (gebruikerssaldo).

---

Q4. Ik kan niet zien welk model het budget heeft opgemaakt bij OpenAI, Anthropic en OpenRouter.

Waar ontwikkelaars over klagen: Een ontwikkelaar vroeg of een piek in de uitgaven bij OpenRouter per model is uit te splitsen. Anderen wezen op tooling zoals View Spend voor OpenAI / Anthropic / xAI, terwijl bedrijfsroddels mensen eraan bleven herinneren dat Replit meer dan $100 mln aan AI-uitgaven van Anthropic naar OpenAI verplaatste voor een korting: andere leveranciers, andere facturen, dezelfde blinde vlek.

Zo antwoordt PoYo: Drie gedocumenteerde onderdelen passen bij deze klacht:

1. Eén sleutel, één saldo. Chat en media delen één PoYo-account. Poll GET /api/user/balance voor credits_amount (gebruikerssaldo).
2. Limieten per uur, per dag en in totaal per sleutel op de pagina met API-sleutels, zodat één agent of één omgeving niet het hele account kan leegtrekken (Aan de slag).
3. Taakgeschiedenis + gepubliceerde prijzen. Bekijk model, invoer en status op het onderdeel taakgeschiedenis dat in Aan de slag wordt beschreven. Vergelijk chat- en mediaprijzen op de prijzenpagina en lees actuele prijzen per model in llms.txt of in de llms.txt van elk model.

---

Q5. Mijn "serverfunctie" kan door iedereen worden aangeroepen, en de sleutel staat waar curl hem kan vinden.

Waar ontwikkelaars over klagen: Hetzelfde bericht over bestedingslimieten waarschuwde ook dat een serverfunctie die iedereen kan aanroepen een rate limit per gebruiker en een bestedingslimiet nodig heeft. Een ander bericht was botweg: zet geen OpenAI-sleutel in chattemplates in de browser. En de klassieker komt nog steeds aan: geen .env op GitHub.

Zo antwoordt PoYo: Aan de slag is expliciet: maak je API-sleutel nooit zichtbaar in frontendcode (browser, mobiele apps, openbare repo's). Behandel de sleutel als geheim, houd hem op je server en gebruik de instellingen die al voor productiesleutels zijn gedocumenteerd:

• IP-whitelist en limieten per uur / per dag / in totaal per sleutel op de pagina met API-sleutels.
• X-End-User-ID verplicht stellen, en daarna een misbruikende aanroeper blokkeren met HTTP 403 end_user_blocked zonder de hele sleutel te vervangen (Identificatie van eindgebruikers).

---

Q6. Video-API's branden credits per seconde door, en de gebruiks-UI lijkt nog steeds op tokens.

Waar ontwikkelaars over klagen: Videofacturering blijft mensen verwarren die zijn opgegroeid met tokenmeters. Oudere maar nog steeds aangehaalde threads gaan over API-gebruiks-UI's die niet overeenkomen met hoe video wordt gefactureerd en updates van de Sora-API-extensie met verwarrende herfacturering. Het thema is actueel: video-402's als er niet genoeg quota is om het bedrag te reserveren.

Zo antwoordt PoYo: Sora 2 Official (en verwante videomodellen) staan in de PoYo-catalogus via llms.txt en de pagina AI-video-API. Dit zijn de factureringsregels die de openbare pagina's echt vermelden:

• Credits per geslaagd resultaat, geprijsd per model (llms.txt).
• Mislukte taken worden niet in rekening gebracht (homepage + llms.txt).
• Actuele prijzen staan op elke modelpagina / https://poyo.ai/models/<model-id>/llms.txt. Controleer die voordat je betaald werk indient en leid dollarbedragen niet af uit je geheugen.
• Generatie is asynchroon: POST /api/generate/submit, daarna de status pollen of een callback_url instellen (Aan de slag). Als je credits niet toereikend zijn, krijg je 402 insufficient_credits_error (foutcodes).

---

Q7. Elke botbouwer leert dat de API de echte productmanager is: rate limits schrijven de roadmap.

Waar ontwikkelaars over klagen: Een bericht vatte het samen: elke botbouwer leert dat de API de echte productmanager is; de rate limit schrijft de roadmap. Agentische startups blijven bidden dat de API midden in de demo geen rate limit oplegt. Anderen zoeken openlijk naar failover bij 429 / 5xx.

Zo antwoordt PoYo: Generatie bij PoYo is ontworpen als asynchroon, zodat lange jobs niet aan één gateway-time-out vastzitten. Aan de slag 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 generatie blijft 20 nieuwe verzoeken / 10 s per account, waarbij overschrijdingen worden afgewezen en niet in de wachtrij komen. Afbeeldingen, video, muziek, chat en 3D zitten achter één uniforme API-sleutel (llms.txt, homepage). Heb je hogere limieten nodig, neem dan contact op met support; aanvragen worden voorzichtig beoordeeld.

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

---

Snel overzicht