Skip to main content

O que é

Esta página explica como a API do Symphony comunica falhas, o que significa cada código de erro, quando vale a pena tentar de novo e quais limites de uso existem. Use-a para montar o tratamento de erros da sua integração.

1. Como ler um erro

Toda resposta de erro tem status HTTP 4xx ou 5xx e um corpo JSON. O código estável do erro pode vir em dois lugares diferentes, conforme o endpoint.
Casos especiais, sem código:

Lendo o código com segurança

Regras para programar contra os erros

  • Use o code, nunca o texto. O code é estável. message e action podem ser reescritos a qualquer momento.
  • As mensagens são sempre em inglês. A API não traduz. Se você mostra o erro para o seu usuário, traduza a partir do code.
  • retryable diz se tentar de novo tem chance de funcionar.
  • Guarde o request_id nos seus logs. É por ele que o time do Symphony encontra o que aconteceu.

2. Códigos de status HTTP

Por segurança, um recurso que existe mas que você não pode ver responde 404, e não 403. Assim a API não revela a existência de dados de outras pessoas.

3. Catálogo de códigos de erro

Modelo e agente

Disponibilidade e rede

Consumo e cota

Acesso

Arquivos e documentos

Outros

4. Quando tentar de novo

Tente de novo quando retryable for true, ou quando o status for 429 ou 5xx:
  • Espere um tempo que cresce a cada tentativa (1 s, 2 s, 4 s, 8 s…) e acrescente uma pequena variação aleatória.
  • Se a resposta trouxer o header Retry-After, espere pelo menos esse número de segundos.
  • Limite o número de tentativas (por exemplo, 5) e registre a falha final com o request_id.
Nunca tente de novo em 400, 401, 402, 403, 404, 409 e 422. Nenhum deles se resolve sozinho, e repetir só consome o seu limite de requisições.

5. Limites de uso

São limites independentes. Saber qual deles foi atingido evita tentativas inúteis. Os valores podem ser ajustados por ambiente.

Limite de requisições por IP

Toda resposta traz headers para você acompanhar o limite:
O limite é por IP, não por chave. Várias integrações saindo pela mesma rede (mesmo servidor, mesmo NAT, mesmo runner de CI) dividem a mesma cota.
GET /health e GET /api/version não contam neste limite, e GET /api/models também não.

Limite de consumo do usuário

É o teto de gasto mensal da conta dona da chave. Ele é verificado antes de qualquer chamada ao modelo, então uma requisição bloqueada não gera custo. Acompanhe com GET /api/v1/consumption/me (veja a Referência da API).

Tempo de resposta e tamanho

  • Configure timeouts generosos. Respostas de modelos grandes, com muito contexto ou com arquivos, podem levar alguns minutos. Recomendamos ao menos 300 segundos para a resposta completa. Se precisar de respostas rápidas, use streaming.
  • Arquivos: o tamanho máximo de upload é definido pela configuração da sua empresa. Consulte o administrador se precisar enviar arquivos grandes.
  • Áudio: arquivos acima de 25 MB são comprimidos automaticamente antes da transcrição.

6. Erros durante o streaming

Com "stream": true, o status 200 OK é enviado antes de o modelo começar a responder. Se algo der errado no meio, a falha chega dentro do fluxo, como um evento JSON com o objeto error, e não como status HTTP de erro. O evento de erro tem o mesmo conteúdo do formato B:
Na sua leitura do streaming:
  1. Para cada linha data: {...}, verifique se o JSON tem a chave error antes de ler choices.
  2. Um data: [DONE] depois de um erro não significa sucesso. Considere a resposta como falha.
  3. Se a conexão fechar sem data: [DONE], trate como STREAM_INTERRUPTED.
  4. Ignore linhas em branco.

7. Como pedir ajuda com um erro

Ao abrir um chamado, envie:
  • O request_id da resposta de erro.
  • O endpoint e o horário aproximado (com fuso horário).
  • O status HTTP e o code.
  • O corpo da requisição, sem a chave de API.
Os canais de suporte estão em Ambientes e suporte.

Documentos relacionados