Principal Como solicitar um Eddie ao time Cloud Humans Requisitos de API para utilização no Eddie

Requisitos de API para utilização no Eddie

Última atualização em Dec 03, 2025

📄Documento Modelo para Utilização**:** Documento de Especificação de API

  1. Quais informações da API precisamos receber?
  • Para configurar o Eddie com qualquer API, precisamos que a documentação forneça os seguintes dados.

1.1 Endpoint da API:

  • Base URL principal.

  • Endpoint específico que será utilizado pelo Eddie.

2. Onde obter ou gerar a chave de acesso da API?

2.1 API Key:

  • Informações sobre onde gerar ou acessar a chave da API.

  • Caso já possua a chave, basta enviá-la.

2.2 A API utiliza token gerado?

  • Se a API exigir token gerado via outro endpoint, precisamos:

  • Endpoint responsável pela geração do token.

  • Credenciais necessárias.

  • Formato do retorno esperado.

3. Documentação da API

  • A documentação deve estar atualizada e conter:

  • Descrição dos endpoints.

  • Métodos suportados.

  • Exemplo de payload recente.

  • Estrutura dos campos que o Eddie precisará extrair.

4. Quais parâmetros precisamos para testar a API?

  • Exemplos de parâmetros para teste:

  • E-mail

  • CPF

  • Número de pedido

  • Outros identificadores usados pela API.

5. Exemplos de Documentação Ideal

  • Uma documentação ideal deve conter:

  • Base URL + endpoints detalhados.

  • Método (GET, POST, PUT, DELETE).

  • Headers necessários.

  • Exemplo de request (JSON).

  • Exemplo de response (JSON).

  • Explicação campo a campo.

  • Fluxo de autenticação (se existir).

6. Erros comuns e como tratá-los.

A documentação deve listar os principais erros retornados pela API, com explicações claras para que a gente consiga identificar, interpretar e corrigir corretamente em caso de falhas. É importante incluir:

  1. Códigos HTTP mais comuns, como:

    • *400 (Bad Request),
    • 401 (Unauthorized),
    • 403 (Forbidden),
    • 404 (Not Found),
    • 409 (Conflict),
    • 422 (Unprocessable Entity),
    • 429 (Too Many Requests),
    • 500 (Internal Server Error).*

  2. Descrição da causa provável de cada erro, por exemplo:

    • Parâmetros inválidos ou ausentes.

    • Falha de autenticação ou token expirado.

    • Excesso de requisições (rate limit).

    • Endpoint temporariamente indisponível.

    • Erro interno do servidor da API.

  3. Exemplo de resposta de erro, incluindo o formato do JSON retornado e os campos relevantes, como:

    • error

    • message

    • code

  4. Orientações de correção ou tratamento, como:

    • Gerar ou renovar o token.

    • Ajustar parâmetros obrigatórios.

    • Aguardar alguns segundos antes de reenviar (em caso de 429).