Ativo · 01
Verificação telefónica em duas chamadas API.
O Kamba Verify gera, protege com hash, envia com o teu Sender ID aprovado, gere reenvios atómicos (/verify/resend) e confirma o código sob lock transacional.
{
"phone": "+244923000000",
"sender_id": "MINHAMARCA"
}
→ verification_id · expires_in: 300Do pedido ao número verificado.
A tua aplicação pede um código, o cliente recebe-o por SMS e introduz os dígitos. O Kamba Verify confirma o código antes de a aplicação continuar.
- 01Pedir código
- 02Receber SMS
- 03Introduzir código
- 04Número verificado
Testa o fluxo sem enviar SMS.
Esta simulação no navegador usa o código 123456. Não chama a API, não envia mensagem e não consome créditos.
Verificação hospedada
Um ecrã pronto para os teus códigos por SMS
O cliente introduz o código numa página da KambaSMS com o nome da tua empresa. Volta à tua aplicação, onde o teu servidor confirma o resultado.
O que está incluído no Kamba Verify.
Ativo · 02
Códigos protegidos por hash e [OTP ocultado] no histórico
Ativo · 03
Validação estrita de Sender ID aprovado da conta
Ativo · 04
Quotas isoladas por conta + número (3/h) e 0 créditos no check
Testa na Sandbox e passa para produção.
Usa o mesmo workspace, chaves API e documentação da KambaSMS para integrar sem fricção.
Kamba Verify: o que precisas de saber.
Consulta os requisitos, as regras de consumo e o âmbito do serviço antes de ativar a integração. A documentação contém os contratos completos da API.
Como tratar um limite de pedidos?
Se receberes HTTP 429, respeita o cabeçalho Retry-After quando estiver presente. Evita repetir em ciclo. Os limites de pedidos, o saldo e as quotas de OTP são controles distintos. Um timeout de envio pode ter resultado desconhecido: consulta a operação original antes de tentar um novo envio.
A página de status garante a entrega?
A página apresenta incidentes reportados manualmente. A ausência de incidentes não comprova disponibilidade ou entrega. Para SMS, aceite pelo fornecedor, entregue segundo DLR e código verificado são estados distintos; no sandbox não existe entrega real.
O que preciso para começar?
Usa uma chave com permissão Verify no teu servidor. Inicia com /verify/start e guarda o verification_id; confirma com /verify/check. A sessão pertence à tua conta e ambiente. O Sender ID deve estar aprovado e ativo na conta; uma chave API não pode substituir o seu remetente. Para login com segundo fator e provas consumíveis, consulta o Authenticator.
Como funciona o consumo?
Cada envio SMS real do código padrão consome um crédito, incluindo reenvios. Consultar o histórico ou confirmar o código não cobra outro SMS. Em Sandbox, o código de teste é 123456 e não há débito nem envio à operadora.
Quais são os limites e o âmbito?
A verificação expira em cinco minutos e permite até cinco tentativas. O início tem limite de três verificações por hora por conta e telefone. Durante um reenvio em curso ou por reconciliar, novas confirmações e reenvios são recusados. Em live, o código anterior é invalidado quando o novo reenvio é reservado. O reenvio exige 60 segundos de intervalo e permite até dois reenvios numa sessão pendente e renova a validade.
O que devo verificar se algo falhar?
Distingue o estado do SMS do resultado da verificação. SMS entregue não significa código confirmado. Uma sessão já verificada pode continuar a devolver sucesso em consultas de confirmação; esse resultado não é uma prova de autenticação de uso único para abrir várias sessões.
Precisas de ajuda? Indica o produto, horário, ID do pedido e uma descrição do problema. Não partilhes chaves API, códigos OTP ou conteúdo pessoal das mensagens. Para capacidade ou compromissos específicos da conta, confirma as condições com o suporte.