2026-10-26: 7 API-klager vi hørte i dag

Klager som engelskspråklige utviklere la ut offentlig mellom 24. og 26. okt. 2026, gjengitt med egne ord nedenfor og med lenker til de opprinnelige innleggene. Hvert svar bruker bare det PoYos offentlige nettsted og dokumentasjon sier i dag, og lenker til siden det kommer fra. Der dokumentasjonen ikke dekker noe, sier vi det.

---

Q1. Nok en SaaS-tjeneste ble hacket – og AI-API-nøklene mine forsvant med den.

Dette klager utviklerne på: Et innbrudd hos en kjent SaaS-tjeneste førte til at AI-API-nøkler lekket i stor skala og ble brukt til svindeltrafikk. I tillegg meldte folk om en lekkasje av OpenAI-API-nøkler knyttet til Railway, og én utvikler fikk en e-post fra OpenAI om en lekket nøkkel som ikke engang var hans. Feil i frontend gjør det stadig verre: API-nøkler som eksponeres i nettleseren, er fortsatt en vanlig svakhet.

Slik svarer PoYo: Roter først – en lekket hemmelighet er fortsatt en lekket hemmelighet. Deretter beskriver dokumentasjonen vår kontroller som begrenser hva en stjålet PoYo-nøkkel kan gjøre:

• IP-hviteliste. Tillat bare godkjente server-IP-er på en nøkkel, slik at en nøkkel som er kopiert ut av en miljøvariabel, ikke virker fra angriperens maskin. Se API-nøkkelsiden og Kom i gang.
• Bruksgrenser per nøkkel (per time, per dag og totalt), slik at én nøkkel har et absolutt tak før du oppdager noe.
• Blokkering per sluttbruker. Send en X-End-User-ID-header, så kan du blokkere én misbrukende bruker på en nøkkel uten å rotere den. En blokkert ID returnerer HTTP 403 med end_user_blocked. Se Identifisering av sluttbrukere.

Den offentlige dokumentasjonen vår lover ikke refusjon for bruk med en lekket nøkkel. Hvis du tror en PoYo-nøkkel er misbrukt, tilbakekaller du den og kontakter kundestøtte ([email protected]).

---

Q2. Når modelleverandøren min lanserer appen jeg konkurrerer med, er hastighetsgrensen det første som ryker.

Dette klager utviklerne på: Én utvikler sa det rett ut: Hvis API-leverandøren din også lanserer produktet du konkurrerer med, er hastighetsgrensen det første som ryker. Reddit-tråder stiller stadig det samme driftsspørsmålet – hvordan folk håndterer hastighetsgrensene i Claude-API-et i produksjon og hvilke tilnærminger som fungerer for hastighetsgrenser hos AI-leverandører.

Slik svarer PoYo: Siden med feilkoder gir hver statuskode én betydning og én anbefalt handling:

Kom i gang oppgir standardgrensen for generering: opptil 20 nye genereringsforespørsler per 10 sekunder, per konto. Forespørsler over grensen får HTTP 429 og kommer ikke inn i køen. Chat- og mediemodeller deler én PoYo-nøkkel og står oppført i llms.txt, så å bytte modell er å endre en model-streng – ikke å ta i bruk en ny leverandør. Hvis du stadig får 429, sier dokumentasjonen at du kan kontakte kundestøtte for en høyere grense; godkjenning gis med forsiktighet.

Dokumentasjonen beskriver ingen automatisk failover mellom leverandører. Bygg reserveløsningen inn i klienten. Kom i gang sier også at PoYos «samlede stabilitet kan være litt lavere enn hos de offisielle leverandørene».

---

Q3. «429»-feilen min var egentlig en forbruksgrense – faktureringsfeil forkledd som hastighetsgrenser.

Dette klager utviklerne på: OpenAIs harde forbrukstak kan dukke opp som 429 med project_spend_limit_exceeded / organization_spend_limit_exceeded, så team behandler en faktureringsstopp som struping. For video-API-er påpekte én utvikler at 402 betyr at det ikke er nok kvote til å reservere belastningen, mens 409 gjelder idempotens. En annen påminnelse var praktisk: Sett en forbruksgrense, for en løkke – eller en fremmed med curl – fakturerer deg likt uansett.

Slik svarer PoYo: PoYo skiller tydelig mellom de to tilfellene i tabellen over feilkoder:

Selve faktureringen er forhåndsbetalte kreditter: Forsiden sier engangskjøp uten gjentakende abonnementer, og kredittene utløper aldri. Poll GET /api/user/balance for credits_amount når du trenger et tall i sanntid (brukersaldo).

---

Q4. Jeg ser ikke hvilken modell som spiste budsjettet på tvers av OpenAI, Anthropic og OpenRouter.

Dette klager utviklerne på: Én utvikler spurte om en topp i forbruket hos OpenRouter kan brytes ned per modell. Andre pekte på verktøy som View Spend for OpenAI / Anthropic / xAI, mens rykter fra bedriftsmarkedet stadig minnet folk på at Replit flyttet over 100 millioner dollar i AI-forbruk fra Anthropic til OpenAI for å få rabatt – ulike leverandører, ulike fakturaer, samme blindsone.

Slik svarer PoYo: Tre dokumenterte elementer passer til denne klagen:

1. Én nøkkel, én saldo. Chat og medier deler én PoYo-konto. Poll GET /api/user/balance for credits_amount (brukersaldo).
2. Tak per time, per dag og totalt for hver nøkkel på API-nøkkelsiden, slik at én agent eller ett miljø ikke kan tømme hele kontoen (Kom i gang).
3. Oppgavehistorikk + publiserte priser. Se modell, input og status i oppgavehistorikken som beskrives i Kom i gang. Sammenlign priser for chat og medier på prissiden, og les gjeldende priser per modell i llms.txt eller i hver modells llms.txt.

---

Q5. «Serverfunksjonen» min kan kalles av hvem som helst – og nøkkelen ligger der curl finner den.

Dette klager utviklerne på: Det samme innlegget om forbruksgrenser advarte også om at en serverfunksjon som hvem som helst kan kalle, trenger hastighetsgrense per bruker og en forbruksgrense. Et annet innlegg var kontant: Ikke legg en OpenAI-nøkkel i chatmaler i nettleseren. Og klassikeren treffer fortsatt: ingen .env på GitHub.

Slik svarer PoYo: Kom i gang er tydelig: Eksponer aldri API-nøkkelen i frontend-kode (nettleser, mobilapper, offentlige repoer). Behandle nøkkelen som en hemmelighet, hold den på serveren, og bruk kontrollene som allerede er dokumentert for nøkler i produksjon:

• IP-hviteliste og tak per time / dag / totalt for hver nøkkel på API-nøkkelsiden.
• Gjør X-End-User-ID obligatorisk, og blokker deretter en misbrukende bruker med HTTP 403 end_user_blocked uten å rotere hele nøkkelen (Identifisering av sluttbrukere).

---

Q6. Video-API-er brenner kreditter per sekund – og bruksoversikten ser fortsatt ut som tokens.

Dette klager utviklerne på: Videofakturering forvirrer stadig folk som er vant til tokenmålere. Eldre, men fortsatt siterte tråder handler om bruksoversikter i API-er som ikke stemmer med hvordan video faktureres og oppdateringer av utvidelsen i Sora-API-et med forvirrende ny fakturering. Temaet er aktuelt: 402 for video når det ikke er nok kvote til å reservere belastningen.

Slik svarer PoYo: Sora 2 Official (og beslektede videomodeller) står i PoYo-katalogen via llms.txt og siden AI-video-API. Faktureringsreglene som de offentlige sidene faktisk oppgir:

• Kreditter per vellykket resultat, priset per modell (llms.txt).
• Mislykkede oppgaver belastes ikke (forsiden + llms.txt).
• Gjeldende priser står på hver modellside / https://poyo.ai/nb/models/<model-id>/llms.txt – sjekk dem før du sender inn betalt arbeid, og ikke gjett dollarbeløp ut fra hukommelsen.
• Generering er asynkron: POST /api/generate/submit, deretter polling av status eller angitt callback_url (Kom i gang). Når kredittene ikke strekker til, får du 402 insufficient_credits_error (feilkoder).

---

Q7. Alle som bygger boter, lærer at API-et er den egentlige produktsjefen – hastighetsgrensene skriver veikartet.

Dette klager utviklerne på: Ett innlegg oppsummerte det slik: Alle som bygger boter, lærer at API-et er den egentlige produktsjefen; det er hastighetsgrensen som skriver veikartet. Oppstartsselskaper innen agenter ber stadig til høyere makter om at API-et ikke strupes midt i demoen. Andre leter åpent etter failover ved 429 / 5xx.

Slik svarer PoYo: Generering på PoYo er laget for å være asynkron, slik at lange jobber ikke er bundet til ett enkelt tidsavbrudd i gatewayen. Kom i gang og API-oversikten sier: Send inn en oppgave, lagre task_id, og poll deretter status eller ta imot en webhook. For produksjonslaster foretrekker dokumentasjonen signerte webhooks fremfor hyppig polling. Ved 429 venter du eller setter i kø (feilkoder); standardgrensen for generering er fortsatt 20 nye forespørsler / 10 s per konto, og overskytende forespørsler avvises og settes ikke i kø. Bilde, video, musikk, chat og 3D ligger bak én samlet API-nøkkel (llms.txt, forside). Trenger du høyere grenser, kontakter du kundestøtte – godkjenning gis med forsiktighet.

Dokumentasjonen beskriver ingen automatisk failover mellom leverandører. Klienten din må håndtere 429 / 5xx og velge neste modell eller ny forsøksvei.

---

Rask oversikt