2026-10-26: 7 lamentele sulle API che abbiamo sentito oggi

Lamentele pubblicate apertamente da sviluppatori di lingua inglese tra il 24 e il 26 ottobre 2026, riassunte qui con i link ai post originali. Ogni risposta usa solo ciò che il sito pubblico e la documentazione di PoYo dicono oggi, e rimanda alla pagina da cui proviene. Dove la documentazione non copre un punto, lo diciamo.

---

Q1. Un altro SaaS è stato violato, e le mie chiavi API di IA sono andate con esso.

Di che cosa si lamentano gli sviluppatori: Un incidente SaaS noto ha lasciato chiavi API di IA esposte in massa e usate per traffico fraudolento. A parte, qualcuno ha segnalato una fuga di chiave API OpenAI legata a Railway, e uno sviluppatore ha ricevuto un’e-mail di OpenAI su una chiave esposta che non era nemmeno sua. Gli errori di frontend peggiorano le cose: le chiavi API esposte nel browser restano un difetto comune.

Come risponde PoYo: Ruotate prima. Un segreto esposto resta un segreto esposto. Poi la documentazione elenca controlli che limitano ciò che una chiave PoYo rubata può fare:

• Elenco di IP consentiti. Si può permettere solo agli IP dei server approvati di usare una chiave. Una chiave copiata da una variabile d’ambiente non funziona dalla macchina di chi attacca. Vedere la pagina delle chiavi API e Per iniziare.
• Tetti d’uso per chiave (orari, giornalieri e totali), così una chiave ha un tetto fermo prima che ve ne accorgiate.
• Blocco per utente finale. Inviate l’header X-End-User-ID e potete bloccare un chiamante abusivo su una chiave senza ruotarla. Un ID bloccato restituisce HTTP 403 con end_user_blocked. Vedere Identificazione dell’utente finale.

La documentazione pubblica non promette rimborsi per l’uso fatto con una chiave esposta. Se pensate che una chiave PoYo sia stata usata in modo improprio, revocatela e scrivete al supporto ([email protected]).

---

Q2. Quando il fornitore del modello pubblica l’app con cui sono in concorrenza, la prima cosa che cede è il limite di frequenza.

Di che cosa si lamentano gli sviluppatori: Uno sviluppatore l’ha detto in modo netto: se il fornitore dell’API pubblica anche il prodotto con cui siete in concorrenza, la prima cosa che cede è il limite di frequenza. I thread su Reddit continuano a fare la stessa domanda operativa: come si gestiscono in produzione i limiti di frequenza dell’API Claude e quali approcci funzionano per i limiti di frequenza dei fornitori di IA.

Come risponde PoYo: La nostra pagina dei codici di errore dà a ogni stato un significato e un’azione consigliata:

Per iniziare pubblica il limite predefinito di generazione: fino a 20 nuove richieste di generazione ogni 10 secondi, per account. Le richieste oltre quel limite ricevono HTTP 429 e non entrano in coda. I modelli di chat e media condividono una chiave PoYo e sono elencati in llms.txt. Cambiare modello è cambiare la stringa model, non integrare un nuovo fornitore. Se i 429 sono continui, la documentazione dice che potete scrivere al supporto per un limite più alto. Le approvazioni sono trattate con cautela.

La documentazione non descrive un failover automatico tra fornitori. Costruite il fallback nel client. Per iniziare dice anche che la «stabilità complessiva di PoYo può essere un po’ inferiore a quella dei fornitori ufficiali».

---

Q3. Il mio «429» era in realtà un tetto di spesa. Errori di fatturazione vestiti da limite di frequenza.

Di che cosa si lamentano gli sviluppatori: I tetti di spesa rigidi di OpenAI possono comparire come 429 con project_spend_limit_exceeded / organization_spend_limit_exceeded, così i team trattano uno stop di fatturazione come una limitazione. Sulle API video, uno sviluppatore ha notato che 402 significa che non c’è quota sufficiente per riservare l’addebito, mentre 409 è il caso di idempotenza. Un altro promemoria era pratico: impostate un tetto di spesa, così un ciclo o un estraneo con curl vi addebitano allo stesso modo.

Come risponde PoYo: PoYo separa i due casi in modo chiaro nella tabella dei codici di errore:

La fatturazione stessa è a crediti prepagati. La home dice: acquisti una tantum, senza abbonamenti ricorrenti, e i crediti non scadono. Interrogate GET /api/user/balance per leggere credits_amount quando vi serve un numero aggiornato (saldo utente).

---

Q4. Non vedo quale modello abbia consumato il budget tra OpenAI, Anthropic e OpenRouter.

Di che cosa si lamentano gli sviluppatori: Uno sviluppatore ha chiesto se un picco di spesa OpenRouter si scompone per modello. Altri hanno indicato strumenti come View Spend per OpenAI / Anthropic / xAI. Le voci aziendali hanno ricordato che Replit ha spostato oltre 100 milioni di dollari di spesa IA da Anthropic a OpenAI per uno sconto. Fornitori diversi, fatture diverse, lo stesso punto cieco.

Come risponde PoYo: Tre elementi documentati corrispondono a questa lamentela:

1. Una chiave, un saldo. Chat e media condividono un account PoYo. Interrogate GET /api/user/balance per leggere credits_amount (saldo utente).
2. Tetti orari, giornalieri e totali per chiave sulla pagina delle chiavi API, così un agente o un ambiente non può svuotare l’intero account (Per iniziare).
3. Cronologia dei task e prezzi pubblicati. Controllate modello, input e stato sulla superficie cronologia dei task descritta in Per iniziare. Confrontate i prezzi di chat e media sulla pagina dei prezzi e leggete i prezzi correnti per modello da llms.txt o dal llms.txt di ciascun modello.

---

Q5. La mia «funzione server» è richiamabile da chiunque, e la chiave sta dove curl la trova.

Di che cosa si lamentano gli sviluppatori: Lo stesso post sui tetti di spesa avvertiva anche che una funzione server richiamabile da chiunque ha bisogno di un limite di frequenza per utente e di un tetto di spesa. Un altro post era diretto: non mettete una chiave OpenAI nei template di chat del browser. E il classico regge ancora: niente .env su GitHub.

Come risponde PoYo: Per iniziare è esplicito: non esponete mai la chiave API nel codice frontend (browser, app mobili, repository pubblici). Trattate la chiave come un segreto, tenetela sul vostro server e usate i controlli già documentati per le chiavi di produzione:

• Elenco di IP consentiti e tetti orari / giornalieri / totali per chiave sulla pagina delle chiavi API.
• Richiedete X-End-User-ID, poi bloccate un chiamante abusivo con HTTP 403 end_user_blocked, senza ruotare l’intera chiave (Identificazione dell’utente finale).

---

Q6. Le API video bruciano crediti al secondo, e l’interfaccia d’uso sembra ancora fatta di token.

Di che cosa si lamentano gli sviluppatori: La fatturazione video continua a confondere chi è cresciuto con i contatori di token. Thread più vecchi, ma ancora citati, coprono interfacce d’uso API che non coincidono con la fatturazione video e aggiornamenti dell’estensione API Sora con una rifatturazione poco chiara. Il tema è attuale: il video restituisce 402 quando non c’è quota sufficiente per riservare l’addebito.

Come risponde PoYo: Sora 2 Official e i modelli video collegati stanno nel catalogo PoYo tramite llms.txt e la pagina API video IA. Regole di fatturazione che le pagine pubbliche enunciano davvero:

• Crediti per output riuscito, con prezzo per modello (llms.txt).
• Le attività non riuscite non vengono addebitate (home e llms.txt).
• I prezzi correnti stanno su ogni pagina di modello e in https://poyo.ai/it/models/<model-id>/llms.txt. Controllateli prima di inviare lavoro a pagamento. Non ricavate gli importi a memoria.
• La generazione è asincrona: POST /api/generate/submit, poi si interroga lo stato o si imposta callback_url (Per iniziare). Se i crediti non bastano, ricevete 402 insufficient_credits_error (codici di errore).

---

Q7. Chi costruisce bot impara che l’API è il vero product manager. I limiti di frequenza scrivono la roadmap.

Di che cosa si lamentano gli sviluppatori: Un post l’ha riassunto così: chi costruisce bot impara che l’API è il vero product manager; il limite di frequenza scrive la roadmap. Le startup di agenti continuano a sperare che l’API non limiti la frequenza a metà demo. Altri cercano apertamente il failover su 429 / 5xx.

Come risponde PoYo: La generazione su PoYo è progettata per essere asincrona, così i lavori lunghi non restano legati a un singolo timeout del gateway. Per iniziare e la panoramica dell’API dicono: inviate un task, salvate il task_id, poi interrogate lo stato o ricevete un webhook. Per i carichi di produzione, la documentazione preferisce webhook firmati alle interrogazioni frequenti. Su 429, attendete o mettete in coda (codici di errore). Il limite predefinito resta 20 nuove richieste / 10 s per account; l’eccedenza viene rifiutata e non entra in coda. Immagine, video, musica, chat e 3D stanno dietro una chiave API unificata (llms.txt, home). Se vi servono limiti più alti, contattate il supporto. Le approvazioni sono trattate con cautela.

La documentazione non descrive un failover automatico tra fornitori. Il client deve gestire 429 / 5xx e scegliere il modello successivo o il percorso di nuovo tentativo.

---

Mappa rapida