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

Klager, som engelsksprogede udviklere har lagt offentligt op mellem den 24. og 26. okt. 2026, gengivet med egne ord nedenfor med links til de oprindelige opslag. Hvert svar bygger udelukkende på det, PoYos offentlige side og dokumentation siger i dag, og linker til den side, det stammer fra. Hvor dokumentationen ikke dækker noget, siger vi det.

---

Q1. Endnu en SaaS blev hacket – og mine AI-API-nøgler røg med.

Det klager udviklerne over: Et velkendt brud hos en SaaS-udbyder efterlod AI-API-nøgler lækket i massevis og brugt til svigagtig trafik. Desuden meldte folk om en lækage af OpenAI API-nøgler knyttet til Railway, og en udvikler fik en mail fra OpenAI om en lækket nøgle, der end ikke var hans. Fejl i frontend gør det ved med at blive værre: eksponerede API-nøgler i browseren er stadig en almindelig fejl.

Sådan svarer PoYo: Roter først – en lækket hemmelighed er stadig en lækket hemmelighed. Derefter nævner vores dokumentation kontroller, der begrænser, hvad en stjålet PoYo-nøgle kan bruges til:

• IP-hvidliste. Tillad kun dine godkendte server-IP'er på en nøgle, så en nøgle, der er kopieret ud af en miljøvariabel, ikke virker fra angriberens maskine. Se siden med API-nøgler og Kom i gang.
• Forbrugsgrænser pr. nøgle (pr. time, pr. dag og samlet), så én nøgle har et fast loft, før du opdager det.
• Blokering pr. slutbruger. Send en X-End-User-ID-header, så kan du blokere én misbrugende bruger på en nøgle uden at rotere den. Et blokeret ID returnerer HTTP 403 med end_user_blocked. Se Identifikation af slutbrugere.

Vores offentlige dokumentation lover ikke refundering for forbrug med en lækket nøgle. Hvis du mener, at en PoYo-nøgle er blevet misbrugt, så tilbagekald den og kontakt support ([email protected]).

---

Q2. Når min modelleverandør udgiver den app, jeg konkurrerer med, er min hastighedsgrænse det første, der brister.

Det klager udviklerne over: En bygger sagde det ligeud: hvis din API-leverandør også udgiver det produkt, du konkurrerer med, er hastighedsgrænsen det første, der brister. Reddit-tråde stiller hele tiden det samme driftsspørgsmål – hvordan folk håndterer hastighedsgrænser i Claude API i produktion og hvilke fremgangsmåder der virker til hastighedsgrænser hos AI-udbydere.

Sådan svarer PoYo: Vores side med fejlkoder giver hver status én betydning og én anbefalet handling:

Kom i gang offentliggør standardgrænsen for generering: op til 20 nye genereringsanmodninger pr. 10 sekunder pr. konto. Anmodninger over den grænse får HTTP 429 og kommer ikke i kø. Chat- og mediemodeller deler én PoYo-nøgle og er opført i llms.txt, så at skifte model er en ændring af strengen model – ikke en ny onboarding hos en leverandør. Hvis du konsekvent rammer 429, siger dokumentationen, at du kan kontakte supporten for at få en højere grænse; godkendelser behandles forsigtigt.

Dokumentationen beskriver ingen automatisk failover mellem udbydere. Byg fallback ind i din klient. Kom i gang siger også, at PoYos "samlede stabilitet kan være en smule lavere end hos de officielle udbydere".

---

Q3. Min "429" var i virkeligheden en forbrugsgrænse – faktureringsfejl i hastighedsgrænsens tøj.

Det klager udviklerne over: Hårde forbrugsgrænser hos OpenAI kan vise sig som 429 med project_spend_limit_exceeded / organization_spend_limit_exceeded, så teams behandler et faktureringsstop som en begrænsning af trafikken. Om video-API'er bemærkede en udvikler, at 402 betyder, at der ikke er kvote nok til at reservere beløbet, mens 409 er tilfældet med idempotens. En anden påmindelse var praktisk: sæt en forbrugsgrænse, så en løkke – eller en fremmed med curl – sender dig den samme regning på begge måder.

Sådan svarer PoYo: PoYo holder de to tilfælde tydeligt adskilt i tabellen med fejlkoder:

Selve faktureringen er forudbetalte kreditter: Forsiden siger engangskøb uden tilbagevendende abonnementer, og kreditterne udløber aldrig. Poll GET /api/user/balance for credits_amount, når du har brug for et live tal (brugersaldo).

---

Q4. Jeg kan ikke se, hvilken model der åd budgettet hos OpenAI, Anthropic og OpenRouter.

Det klager udviklerne over: En udvikler spurgte, om et spring i forbruget hos OpenRouter kan opdeles pr. model. Andre pegede på værktøj som View Spend til OpenAI / Anthropic / xAI, mens sladder fra erhvervslivet blev ved med at minde folk om, at Replit flyttede $100M+ af AI-forbruget fra Anthropic til OpenAI mod en rabat – forskellige leverandører, forskellige fakturaer, samme blinde vinkel.

Sådan svarer PoYo: Tre dokumenterede dele passer til den klage:

1. Én nøgle, én saldo. Chat og medier deler én PoYo-konto. Poll GET /api/user/balance for credits_amount (brugersaldo).
2. Grænser pr. time, pr. dag og samlet pr. nøgle på siden med API-nøgler, så én agent eller ét miljø ikke kan tømme hele kontoen (Kom i gang).
3. Opgavehistorik + offentliggjorte priser. Se model, input og status i opgavehistorikken, som beskrives i Kom i gang. Sammenlign priser for chat og medier på prissiden, og læs aktuelle priser pr. model i llms.txt eller i hver models egen llms.txt.

---

Q5. Min "serverfunktion" kan kaldes af alle – og nøglen ligger, hvor curl kan finde den.

Det klager udviklerne over: Det samme opslag om forbrugsgrænser advarede også om, at en serverfunktion, der kan kaldes af alle, har brug for en hastighedsgrænse pr. bruger og en forbrugsgrænse. Et andet opslag var kontant: læg ikke en OpenAI-nøgle i chatskabeloner i browseren. Og klassikeren rammer stadig: ingen .env på GitHub.

Sådan svarer PoYo: Kom i gang er tydelig: eksponér aldrig din API-nøgle i frontendkode (browser, mobilapps, offentlige repositories). Behandl nøglen som en hemmelighed, behold den på din server, og brug de kontroller, der allerede er dokumenteret for produktionsnøgler:

• IP-hvidliste og grænser pr. time / pr. dag / samlet pr. nøgle på siden med API-nøgler.
• Kræv X-End-User-ID, og bloker derefter en misbrugende bruger med HTTP 403 end_user_blocked uden at rotere hele nøglen (Identifikation af slutbrugere).

---

Q6. Video-API'er brænder kreditter af pr. sekund – og forbrugsvisningen ligner stadig tokens.

Det klager udviklerne over: Videofakturering forvirrer stadig folk, der er vokset op med tokenmålere. Ældre, men stadig citerede tråde handler om brugerflader til API-forbrug, der ikke passer til, hvordan video faktureres og opdateringer til Sora API-udvidelser med forvirrende gen-fakturering. Temaet er aktuelt: video-402-fejl, når der ikke er kvote nok til at reservere beløbet.

Sådan svarer PoYo: Sora 2 Official (og beslægtede videomodeller) findes i PoYos katalog via llms.txt og siden AI-video-API. Faktureringsregler, som de offentlige sider rent faktisk angiver:

• Kreditter pr. vellykket resultat, prissat pr. model (llms.txt).
• Mislykkede opgaver bliver ikke trukket (forsiden + llms.txt).
• Aktuelle priser står på hver modelside / https://poyo.ai/da/models/<model-id>/llms.txt – tjek dem, før du indsender betalt arbejde; gæt ikke dollarbeløb ud fra hukommelsen.
• Generering er asynkron: POST /api/generate/submit, derefter poll status eller angiv callback_url (Kom i gang). Når kreditterne ikke slår til, får du 402 insufficient_credits_error (fejlkoder).

---

Q7. Alle botbyggere lærer, at API'en er den egentlige produktchef – hastighedsgrænser skriver køreplanen.

Det klager udviklerne over: Ét opslag opsummerede det: alle botbyggere lærer, at API'en er den egentlige produktchef; hastighedsgrænsen skriver køreplanen. Agentiske startups bliver ved med at bede til, at API'en ikke begrænser hastigheden midt i en demo. Andre leder åbent efter failover ved 429 / 5xx.

Sådan svarer PoYo: Generering hos PoYo er designet til at være asynkron, så lange jobs ikke er bundet til én enkelt gateway-timeout. Kom i gang og API-overblikket siger: Indsend en opgave, gem task_id, og poll derefter status eller modtag en webhook. Til produktionsworkloads foretrækker dokumentationen signerede webhooks frem for hyppig polling. Ved 429 skal du vente eller sætte i kø (fejlkoder); standardgrænsen for generering er fortsat 20 nye anmodninger pr. 10 sek. pr. konto, hvor overskydende anmodninger afvises og ikke sættes i kø. Billede, video, musik, chat og 3D ligger bag én samlet API-nøgle (llms.txt, forside). Hvis du har brug for højere grænser, så kontakt supporten – godkendelser behandles forsigtigt.

Dokumentationen beskriver ingen automatisk failover mellem udbydere. Din klient skal selv håndtere 429 / 5xx og vælge næste model eller sti til nyt forsøg.

---

Hurtigt overblik