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 HTTP4xx ou 5xx e um corpo JSON. O código estável do erro pode vir em dois lugares diferentes, conforme o endpoint.
- Formato A: código em error
- Formato B: código em detail
Lendo o código com segurança
Regras para programar contra os erros
- Use o
code, nunca o texto. Ocodeé estável.messageeactionpodem 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. retryablediz se tentar de novo tem chance de funcionar.- Guarde o
request_idnos 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 quandoretryable 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.
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: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 comGET /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:
- Para cada linha
data: {...}, verifique se o JSON tem a chaveerrorantes de lerchoices. - Um
data: [DONE]depois de um erro não significa sucesso. Considere a resposta como falha. - Se a conexão fechar sem
data: [DONE], trate comoSTREAM_INTERRUPTED. - Ignore linhas em branco.
7. Como pedir ajuda com um erro
Ao abrir um chamado, envie:- O
request_idda 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.