Mga limitasyon sa rate ng API at pinakamahusay na kasanayan

Bawat Ody API key ay nakakakuha ng 600 request kada minuto sa /v1/api/* at sa MCP endpoint — basahin ang mga RateLimit-* header sa bawat tugon, at mag-back off gamit ang Retry-After na halaga kapag nakakuha ka ng 429.

Paano gumagana ang limitasyon

• Ang limitasyon ay bawat key, binibilang sa isang nakapirming 60-segundong window. Ang mga request na walang valid na key ay limitado bawat IP sa halip.
• Bawat tugon — tagumpay o error — ay nagdadala ng tatlong standard na header:
  • RateLimit-Limit — ang iyong per-minutong budget (600).
  • RateLimit-Remaining — mga request na natitira sa kasalukuyang window.
  • RateLimit-Reset — segundo hanggang sa mag-reset ang window.
• Ang paglampas ay nagbabalik ng 429 na may error code na resource_exhausted at isang Retry-After na header (segundo). Maghintay ng hindi bababa sa ganoong katagal bago subukang muli.

HTTP/1.1 429 Too Many Requests
RateLimit-Limit: 600
RateLimit-Remaining: 0
RateLimit-Reset: 23
Retry-After: 23

Pananatili sa loob ng limitasyon

• Subaybayan ang RateLimit-Remaining at dahan-dahan nang maaga habang papalapit ito sa zero, sa halip na mag-react sa mga 429.
• Gumamit ng mga webhook sa halip na polling. Mag-subscribe ng isang endpoint sa mga event tulad ng message.received at itutulak ng Ody ang aktibidad sa iyo — tingnan ang Tumanggap ng mga webhook at i-verify ang mga signature. Kung kailangan mong mag-poll, ang bawat 10–30 segundo ay sapat na para sa isang shared inbox.
• Subukang muli gamit ang exponential backoff at jitter sa 429 at 5xx, nililimitahan ang mga pagsubok muli. Igalang ang Retry-After kapag naroroon. Para sa mga pagpapadala, ipares ang mga pagsubok muli sa isang Idempotency-Key upang walang doble-dobleng pagpapadala — tingnan ang Pagination, idempotency, at paghawak ng error.
• Humiling ng mas malalaking pahina (?limit= hanggang sa maximum ng bawat endpoint) sa halip na maraming maliliit kapag nagsi-sync ng data.

Pinakamahusay na kasanayan sa seguridad ng key

• I-scope ang bawat key sa pinakamababang kailangan nito. I-deselect ang mga scope sa paggawa — ang isang dashboard na nagbabasa lamang ng mga pag-uusap ay dapat magkaroon lamang ng conversations:read. Tingnan ang Kunin ang iyong Ody API key.
• Gumamit ng mga test key sa lahat ng lugar kung saan ang mga tunay na text ay magiging bug. Ang mga development environment at CI ay dapat tumakbo sa ody_test_… na mga key upang ang mga pagpapadala ng mensahe ay ma-simulate — tingnan ang Bumuo nang ligtas gamit ang test mode.
• Isang key bawat integrasyon. Ang magkahiwalay na key para sa Zapier, iyong server, at isang AI assistant ay nangangahulugang maaari mong bawiin ang isa nang hindi nasisira ang iba, at ang column na "huling ginamit" sa Mga Setting → Developer API ay nananatiling makabuluhan.
• Panatilihin ang mga key sa server-side. Huwag kailanman i-embed ang isang key sa mga mobile app, browser JavaScript, o shared na dokumento — sinuman na may key ay maaaring kumilos bilang tagalikha nito sa loob ng mga scope nito.
• I-rotate at i-prune. Bawiin ang mga key na hindi mo na ginagamit. Dahil ang plaintext ay ipinapakita lamang nang isang beses, ang pag-rotate ay nangangahulugang paggawa ng bagong key, pag-deploy nito, at pagkatapos ay pagbawi sa luma.

Mga kaugnay na artikulo

• Pangkalahatang-ideya ng API at pagpapatunay
• Pagination, idempotency, at paghawak ng error
• Tumanggap ng mga webhook at i-verify ang mga signature
• Bumuo nang ligtas gamit ang test mode