> ## Documentation Index > Fetch the complete documentation index at: https://docs.ycloud.com/llms.txt > Use this file to discover all available pages before exploring further. # Limites de taxa > Consulte as cotas da API da YCloud, leia os cabeçalhos de limite de taxa e repita requisições limitadas com segurança. A YCloud limita as requisições de API dentro de uma janela de tempo. Os limites se aplicam a uma conta, a um remetente ou a um grupo de endpoints. As requisições que excederem um limite retornam HTTP `429 Too Many Requests` com a [resposta de erro](/pt/api-reference/guides/api-fundamentals/handle-errors) padrão. ## Limites da Messaging API `rps` significa requisições por segundo. Um remetente é um número de telefone comercial do WhatsApp. | Endpoint | Limite de taxa | Escopo | | - | - | - | | `POST /v2/emails` | 200 rps | Por conta | | `POST /v2/sms` | 200 rps | Por conta | | `POST /v2/voices` | 200 rps | Por conta | | `POST /v2/whatsapp/messages` | 200 rps | Por remetente | | `POST /v2/whatsapp/messages/sendDirectly` | 80 rps por padrão; 1.000 rps após um upgrade automático de taxa de transferência qualificado | Por remetente | A maioria dos endpoints tem um limite de 200 rps por conta. Os endpoints de envio do WhatsApp usam os limites por remetente mostrados acima. Consulte a [documentação de taxa de transferência](https://developers.facebook.com/docs/whatsapp/cloud-api/overview#throughput) da Meta para obter mais informações sobre upgrades automáticos. ### Envios do WhatsApp enfileirados e diretos A YCloud contabiliza os dois endpoints de envio do WhatsApp separadamente. O endpoint enfileirado `/v2/whatsapp/messages` aceita até 200 rps por remetente, enquanto a YCloud envia mensagens enfileiradas para a Meta a 60 rps. A aceitação na fila não significa que a Meta tenha aceitado ou entregue a mensagem. Evite enviar a uma taxa alta por ambos os endpoints com o mesmo remetente ao mesmo tempo. Os envios enfileirados e diretos ainda usam o mesmo número de telefone comercial do WhatsApp, portanto, o tráfego combinado de ambos pode atingir o limite da Meta e causar falhas. ## Limites da Management API A maioria das APIs sem uma política documentada separada são APIs de gerenciamento. Esses endpoints compartilham uma cota por conta: **200 requisições por segundo e 10.000 requisições por hora**. Ambos os limites se aplicam; você não pode sustentar 200 rps durante uma hora inteira. As requisições para um endpoint de gerenciamento consomem a cota disponível para os demais. A política compartilhada inclui: * `/v2/balance` * `/v2/webhookEndpoints/*` * `/v2/whatsapp/businessAccounts/*` * `/v2/whatsapp/phoneNumbers/*` * `/v2/whatsapp/templates/*` * `/v2/whatsapp/messages/{id}` * Outras APIs sem uma política documentada separadamente ## Ler cabeçalhos de limite de taxa A YCloud inclui informações sobre limite de taxa na maioria das respostas da API. Leia os cabeçalhos quando estiverem presentes em vez de presumir que todos os endpoints têm a mesma cota. | Cabeçalho | Significado | | - | - | | `Retry-After` | Segundos a aguardar antes de repetir ou enviar outra requisição. | | `RateLimit-Limit` | Máximo de unidades de cota para a conta ou remetente na janela de tempo informada. | | `RateLimit-Policy` | Políticas informativas de cota e suas respectivas janelas de tempo. Por exemplo, `100;w=60` descreve 100 unidades de cota por 60 segundos. | | `RateLimit-Remaining` | Unidades de cota ainda disponíveis para o limite informado. | | `RateLimit-Reset` | Segundos até que a cota informada seja redefinida. | Os cabeçalhos `RateLimit-*` estão em versão beta e podem sofrer alterações. O formato de cabeçalho documentado da YCloud segue a especificação de limite de taxa IETF draft-06. Trate os parâmetros de política como informativos e mantenha seu cliente tolerante a parâmetros adicionais. ### Exemplo: cota horária compartilhada esgotada ```http theme={"theme":{"light":"github-light","dark":"github-dark"}} HTTP/2 429 Content-Type: application/json Retry-After: 1800 RateLimit-Limit: 10000 RateLimit-Policy: 200;w=1;burst=200;algorithm=token_bucket;level=account;scope=management_api, 10000;w=3600;algorithm=fixed_window;level=account;scope=management_api RateLimit-Remaining: 0 RateLimit-Reset: 1800 ``` A conta esgotou sua cota compartilhada de **10.000 requisições por hora** . Aguarde pelo menos 1.800 segundos antes de enviar outra requisição sujeita a essa cota. Alternar para um endpoint de gerenciamento diferente não fornece uma nova cota. ## Tratar uma resposta `429` 1. Pause requisições que compartilhem a cota esgotada da conta ou do remetente. 2. Respeite `Retry-After` quando presente. Não tente novamente antes que esse intervalo expire. 3. Reduza a simultaneidade e adicione recuo exponencial com jitter. 4. Limite as repetições por um número de tentativas ou pelo tempo limite da sua aplicação. 5. Registre em log o endpoint, o método HTTP, o erro `code`, `requestId` e o horário da requisição. Exclua chaves de API e dados pessoais. Se uma resposta bem-sucedida incluir `Retry-After`, atrase as requisições subsequentes; não reenvie a requisição que já obteve sucesso. Monitore `RateLimit-Remaining` e `RateLimit-Reset` para diminuir o ritmo antes que a cota se esgote. ### Repetir com recuo e jitter Este exemplo em JavaScript trata `Retry-After` como uma espera mínima. O limite de recuo restringe o atraso de jitter da aplicação; ele não reduz uma espera solicitada pelo servidor. As configurações de tentativas e atrasos são escolhas da aplicação, não limites da API. ```javascript theme={"theme":{"light":"github-light","dark":"github-dark"}} async function requestWithBackoff(url, options) { const maxAttempts = 5; const baseDelayMs = 500; const maxBackoffMs = 30_000; for (let attempt = 0; attempt < maxAttempts; attempt += 1) { const response = await fetch(url, options); if (response.status !== 429) return response; if (attempt === maxAttempts - 1) { throw new Error("YCloud API rate limit persisted after retries"); } const header = response.headers.get("Retry-After"); const seconds = header === null ? NaN : Number(header); const serverDelayMs = Number.isFinite(seconds) && seconds >= 0 ? seconds * 1000 : 0; const backoffCap = Math.min(maxBackoffMs, baseDelayMs * 2 ** attempt); const delayMs = Math.max(serverDelayMs, Math.random() * backoffCap); await response.body?.cancel(); await new Promise((resolve) => setTimeout(resolve, delayMs)); } } ``` Aplique este exemplo apenas quando a operação for segura para repetição. Para esperas longas, use uma fila agendada para que um worker não precise permanecer ativo. ## Controlar a simultaneidade e as repetições Use uma fila delimitada e um limite compartilhado de workers. Evite loops de repetição independentes onde cada um presume que a cota total da conta ou do remetente está disponível. Restaure o tráfego gradualmente após o término da limitação. Um `POST` repetido pode criar outro recurso ou enviar outra mensagem. Verifique primeiro as orientações de nova tentativa do endpoint e o resultado que você salvou. Onde houver suporte, mantenha um `externalId` estável, mas não o trate como uma chave de idempotência universal. Armazene o ID de resposta da YCloud e reconcilie resultados ambíguos antes de reenviar. Monitore o volume de requisições, respostas `429`, latência, contagem de novas tentativas e tempo na fila por endpoint e remetente. Consulte [Práticas recomendadas da API de mensagens do WhatsApp](/pt/api-reference/guides/whatsapp-platform/whatsapp-messages-api-best-practices) para enfileiramento, reconciliação e prevenção de duplicatas. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.