Documentação da API

POST /api/v1/submit-lead

Recebe os dados de uma demonstração solicitada e encaminha para a equipe de vendas. Limitado a 5 requisições por minuto por IP — acima disso, retorna 429. A forma sem versão (/api/submit-lead) segue funcionando como alias, mas novas integrações devem usar a rota versionada.

curl -X POST https://payby.com.br/api/v1/submit-lead \
  -H "Content-Type: application/json" \
  -d '{
    "restaurante": "Nome do restaurante",
    "nome": "Seu nome",
    "telefone": "11999999999",
    "email": "voce@exemplo.com"
  }'

Versionamento

O caminho é versionado (/api/v1/...). Uma mudança que quebra compatibilidade sobe para uma nova versão (/api/v2/...); a versão anterior continua no ar por pelo menos 90 dias depois disso, e respostas da versão sendo descontinuada trazem um cabeçalho Sunset com a data em que ela para de funcionar.

Rate limit

Toda resposta traz RateLimit-Limit, RateLimit-Remaining e RateLimit-Reset (segundos até a janela liberar). Um 429 também traz Retry-After.

Erros

Toda resposta de erro é um JSON estruturado com code, message e, quando aplicável, hint. Método errado no endpoint retorna 405 (não 404), e qualquer caminho sob /api/ que não exista retorna 404 em JSON também — não a página de erro do site.

Limitação conhecida: um corpo com JSON sintaticamente inválido (não apenas incompleto) ainda retorna um erro em texto puro do parser interno do Cloud Functions, antes do nosso código rodar — não há um hook suportado para interceptar isso na 1ª geração do Cloud Functions sem trocar de plataforma.

{
  "error": {
    "code": "missing_required_fields",
    "message": "restaurante, nome, telefone and email are all required.",
    "hint": "Resend the request with all four fields set to non-empty strings."
  }
}