Checklist Rápido de Integração de API (Para Fornecedores)
Este é um checklist de verificação rápida (“sim/não/NA”) para garantir que os pontos técnicos, de segurança, governança e operação da integração foram endereçados.
Instruções: Marque (S) para Sim, (N) para Não, ou (NA) para Não Aplicável.
Dica de uso: preencha este checklist antes de começar o desenvolvimento e revalide antes do Go‑Live. Anexe as evidências (links, prints, coleções Postman, etc.) ao enviá-lo.
✅ Checklist
| Tópico | Ponto de Verificação | Resposta (S/N/NA) |
|---|---|---|
| Documentação | A documentação da API (Swagger/OpenAPI) está acessível e atualizada? | |
| Existe um guia de “Primeiros Passos” (Getting Started) com exemplos práticos? | ||
| Há changelog/versionamento documentado (v1, v2) e ciclo de vida (depreciação)? | ||
| O contato técnico do fornecedor (nome, email, horário de atendimento) foi designado? | ||
| Ambiente | Um ambiente de Sandbox/Testes está disponível para uso? | |
| As credenciais (chaves/tokens) de Sandbox foram fornecidas? | ||
| Autenticação | O método de autenticação está claro (ex.: OAuth 2.0, mTLS, API Key)? | |
| O processo de obtenção/renovação de token (refresh) está documentado? | ||
| O tempo de vida do token, escopos e política de revogação estão definidos? | ||
| A API exige whitelisting de IPs do cliente? Faixas/Procedimento informados? | ||
| Limites & Performance | Existe rate limiting? | |
| Os limites exatos (ex.: 100 req/min) estão documentados? | ||
| Existe alguma forma de consultar o limite disponível? | ||
| Há limite de tamanho de payload por requisição/resposta e política de compressão (gzip/br)? | ||
| Timeouts recomendados e política de retry com backoff estão documentados? | ||
| Design da API | Suporta operações em lote (batch) para criação/atualização? | |
| O processamento é assíncrono para operações longas? | ||
| Se assíncrono, existem webhooks e/ou polling com job status? | ||
| Paginação documentada (offset/cursor), com exemplos e limites de página? | ||
| Padrões de filtro, ordenação, fields (sparse fieldsets) estão definidos? | ||
| Webhooks (se aplicável) | Entregas possuem assinatura, tentativas com retry e DLQ/diferimento? | |
| Há endpoint de validação (ex.: challenge), event types e versões dos eventos? | ||
| Tratamento de Erros & Observabilidade | Códigos HTTP padronizados (2xx/4xx/5xx) e corpo de erro consistente? | |
Respostas incluem trace-id/request-id para debug ponta a ponta? | ||
| Esquema de erro possui código, mensagem, detalhes e documentação? | ||
| Monitoramento & Operação | Existe health-check (ex.: /health//status) e página de status pública? | |
| Canal de comunicação de incidentes (email/statuspage) e janela de manutenção definidos? | ||
| Governança, Versionamento & SLA | Política de versionamento (semver, URI versioning) e quebra de compatibilidade? | |
| Aviso prévio para breaking changes e cronograma de depreciação definido? | ||
| Testabilidade & Qualidade | Coleções Postman/Insomnia e mocks (ou sandbox determinístico) disponíveis? | |
| Exemplos de payloads válidos e de erro (JSON Schema) fornecidos? | ||
| Rede & Conectividade | Há necessidade de VPN/peering? Processo e prazos estabelecidos? | |
| Go-Live & Suporte | Processo para credenciais de Produção e cutover claro? | |
| Suporte técnico (horários, SLA de atendimento, escalonamento) definido para Go‑Live? | ||
| Continuidade & Incidentes | Relatório pós‑incidente (postmortem) é compartilhado quando aplicável? |