Pangasiwaan ang mga error sa API at retries
I-diagnose ang mga error sa authentication, saklaw, access sa modelo, at availability ng ShareAI nang walang duplicate na pagsusulat o hindi ligtas na pag-refresh ng retries.
Sa pahinang ito
Laging suriin ang HTTP status bago basahin ang tugon bilang tagumpay. Ang mga serbisyo ng ShareAI ay maaaring magbalik ng iba't ibang error envelopes: ang inference ay maaaring magbigay error.code, ang OAuth ay nagbibigay error at error_description, at ang mga ruta ng Console ay maaaring magbalik code, message at data.status.
| Katayuan | Karaniwang kahulugan | Pagbawi |
|---|---|---|
| 200 na may error object | Walang availability ng device na resulta sa kasalukuyang chat endpoint. | Suriin ang error.code at huwag itong i-render bilang sagot ng assistant. |
| 400 | Hindi wastong kahilingan o OAuth grant. | Itama ang body, mga parameter, callback, o expired/consumed code. |
| 401 | Nawawala, nag-expire, o hindi wastong pagpapatunay. | Suriin ang kredensyal; i-refresh lamang ang wastong OAuth grant. |
| 402 | Kulang ang kredito o balanse na maaaring gamitin. | Suriin ang balanse ng napiling account bago muling subukan. |
| 403 | Saklaw, pagmamay-ari, papel o pagtanggi sa estado ng pagkakabukas. | Suriin ang dokumentadong hangganan ng pahintulot. |
| 404 | Hindi kilalang resource o hindi suportadong ruta ng gateway. | Suriin ang host, path at mga identifier ng resource. |
| 409 | Salungatan sa estado o rebisyon. | Basahin ang kasalukuyang estado at muling pag-isipan ang pagbabago. |
| 429 | Limitasyon sa kahilingan o sabay-sabay na proseso. | Igalang ang Retry-After at gumamit ng may hangganang backoff. |
| 500 / 502 / 503 | Pagkabigo sa availability ng server o upstream. | Panatilihing may hangganan ang retries; panatilihin ang mga diagnostic identifier. |
Ulitin ang mga pagbabasa na may limitasyon#
Para sa pansamantalang pagkabigo sa pagbabasa, maghintay nang may tumataas na delay at jitter, igalang ang Retry-After kung naroroon at huminto pagkatapos ng tinukoy na bilang ng pagtatangka o oras na badyet. Ipakita sa user kapag hindi available ang data sa halip na tahimik na umulit.
Tratuhin ang mga pagsusulat nang maingat#
Huwag awtomatikong ulitin ang pag-update ng presyo, paggawa ng modelo o utos ng pagbabahagi kapag hindi alam ang resulta. Basahin muna ang estado ng resource o utos. Gumamit ng Idempotency-Key lamang sa mga endpoint na nagdodokumento ng suporta, tulad ng mga pagbabago sa kasunduan.
Ang mga refresh token ay single-use#
Ang pag-refresh ng rotation ay nangangailangan ng lock sa bawat awtorisasyon sa iyong backend. Ang bulag na retry ng nagamit na refresh token ay maaaring magpawalang-bisa sa grant. Tingnan ang ligtas na pag-refresh ng token.
Ano ang isasama sa kahilingan sa suporta#
Isama ang endpoint, HTTP status, error code, oras at response/task identifier kung available. Alisin ang Authorization headers, cookies, client secrets, access tokens, refresh tokens at mga pribadong nilalaman ng prompt.
Mga limitasyon sa buwanang paggastos at pagbawi ng pagsingil#
Ang bawat nagbabayad na account ay maaaring magtakda ng sarili nitong buwanang limitasyon sa paggastos ng AI bawat aplikasyon o serbisyo ng client sa Billing → Subscriptions & Commitments. Kasama sa limitasyon ang gastos sa network at surcharge ng builder, habang ang mga nakapirming subscription at kumpirmadong pagbili ay nananatiling hiwalay. Ang error sa limitasyon ay gumagamit ng HTTP 402 application_spending_limit_exceeded; ang kakulangan ng karapat-dapat na kredito ay gumagamit ng HTTP 402 insufficient_credits. Parehong nagbibigay ng link sa pagsingil ng customer. Error contract, streaming handling at integration example.
Huling na-update Setyembre 18, 2026