Receba SMS por API ou painel: qual o fluxo de trabalho mais adequado?

Primeiro distinga três APIs diferentes

Uma API de recebimento de números temporários pede ou aluga um número e então recupera um SMS recebido para esse pedido. Um painel manual apresenta o mesmo tipo de pedido e mensagem a uma pessoa em um navegador. Uma API de envio ou verificação, como o Twilio Verify, inicia uma verificação enviando um código para o próprio dispositivo do usuário. Esses produtos ficam em lados opostos da mensagem. Pesquisar por “API de verificação SMS” pode retornar qualquer um dos dois, então verifique a direção antes de escolher a documentação.

A OTPAtlas oferece atualmente um painel com sessão iniciada para selecionar e acompanhar pedidos de números temporários. Não oferece uma API pública documentada para programadores externos. Os exemplos de fornecedores abaixo mostram como as APIs externas documentadas diferem de um painel manual; não são endpoints da OTPAtlas.

Fontes: 5documentação da API de receção da SIM · guia da API de encomenda/verificação do SMSPool · API de envio do Twilio Verify

Quando um painel é a ferramenta mais adequada

Para um código ocasional, um painel mantém a decisão humana visível: confirme as regras do serviço de recebimento, compare os países permitidos, leia o preço e o estoque ao vivo, financie uma conta se necessário e revise o pedido exato antes da confirmação. Na OTPAtlas, a aba SMS então exibe o número atribuído, a expiração exata após a atribuição, o status e qualquer mensagem registrada; o Histórico e a atividade de saldo mostram o resultado final. Nenhuma integração de software é necessária para fazer essas perguntas.

Uma API não torna elegível um país excluído, não cria stock, não prolonga um número curto nem garante que uma plataforma de terceiros o aceite. Se a parte difícil for escolher o número certo ou compreender um crédito sem mensagem, a automatização pode apenas repetir uma má escolha mais depressa. Use um painel até a própria decisão ser compreendida e repetida o suficiente para justificar código.

O que uma API de receção suportada documenta realmente

A documentação oficial do 5SIM separa produtos e preços, a compra de um número de ativação, a verificação de um pedido durante SMS, a conclusão e o cancelamento, e os estados. Os seus termos públicos continuam a reger os compradores que usam a API, incluindo a sua restrição de elegibilidade para os EUA/Rússia. O guia do SMSPool documenta um ID de pedido, verificações de estado para um código pendente ou completo, cancelamento e respostas de erro como sem stock ou saldo insuficiente. O OnlineSIM documenta endpoints de ativação e aluguer. O HeroSMS remete os utilizadores para a sua documentação da API e publica limites de pedidos nas suas regras, embora a sua alegada compatibilidade com SMS-Activate não tenha sido testada aqui.

Estes são contratos específicos do fornecedor. Não cole os nomes de parâmetros, números de estado ou lógica de reembolso de um fornecedor noutra integração. Use a documentação atual para o fornecedor e produto que realmente selecionou, incluindo se a API suporta as mesmas escolhas de país, operadora e aluguer que viu no seu painel.

Fontes: 5documentação da API da SIM · 5termos da SIM · guia de encomenda/verificação da API do SMSPool · produtos da API do OnlineSIM · API e regras do HeroSMS

Conceber o ciclo de vida do pedido antes de o automatizar

Um fluxo conceitual seguro é: ler produtos e preço atual; garantir que a conta seja elegível e esteja financiada; enviar um pedido; armazenar o ID de pedido retornado; verificar esse mesmo pedido para estados de aguardando, SMS recebido, cancelado ou expirado; e reconciliar qualquer movimentação de saldo. Se o provedor oferecer cancelamento, aplique seu tempo real e regra de ausência de mensagem. O guia da SMSPool instrui explicitamente os integradores a reter o ID do pedido e consultar o endpoint de verificação porque ele não envia notificações push para esse fluxo.

Um tempo limite de solicitação após o envio de um pedido é ambíguo: o provedor pode ter criado o pedido mesmo que seu cliente nunca tenha visto a resposta. Não envie cegamente uma segunda solicitação de compra paga. Primeiro inspecione o histórico de pedidos ou os recursos de status do provedor e reconcilie com um registro de solicitação local. Não encontramos uma chave de idempotência documentada comum a esses provedores; pergunte se o endpoint escolhido oferece suporte a uma. Esta é uma precaução de engenharia, não uma promessa do comportamento dos provedores.

Fontes: 5API de encomendas e histórico da SIM · ID de encomenda, estado e consulta periódica do SMSPool

Tratar erros, limites de taxa e segredos como decisões de produto

Sem stock significa que o produto selecionado não está disponível; saldo insuficiente significa que é necessário carregar fundos. Nenhum dos casos é motivo para comprar automaticamente um país diferente se a plataforma recetora o proibir. A SMSPool documenta esses tipos de resposta. A 5SIM publica limites de pedidos e respostas 429 ou 503 para diferentes limites; a HeroSMS publica limites de pedidos de API nas suas regras atuais. Leia os limites atuais do fornecedor e use repetição controlada ou recuo progressivo para verificações de estado, evitando a repetição descontrolada de uma chamada de compra.

Mantenha as chaves de API num servidor de confiança em vez de numa página de navegador pública, limite o acesso a registos que contenham números de telefone ou texto de mensagens e retenha apenas o que o fluxo de trabalho necessita. Acompanhe o ID da encomenda e o resultado final para que uma questão de suporte possa identificar um evento específico. Um utilizador do painel não precisa de criar estes controlos; um programador que utiliza uma API precisa. Nenhuma das interfaces concede permissão para contornar as regras de uma plataforma recetora.

Fontes: Erros da API da SMSPool · 5limites da API do SIM · Regras da API da HeroSMS

Duas escolhas completas

Caso A: uma pessoa precisa de um código permitido esta semana. Pode usar o painel do OTPAtlas para verificar uma oferta ativa de serviço-país, financiar apenas depois de compreender o carregamento mínimo, confirmar a encomenda e ler o estado do SMS. Criar uma integração API acrescentaria trabalho de credenciais e tratamento de erros sem alterar a elegibilidade ou a duração do número.

Caso B: uma equipa testa repetidamente o seu próprio fluxo de registo aprovado em países permitidos. Um fornecedor com uma API de receção oficial pode reduzir a cópia manual se a equipa conseguir implementar o ciclo de vida da encomenda, proteger credenciais, reconciliar compras ambíguas e respeitar os limites de pedidos. Se a equipa precisar, em vez disso, de enviar códigos de verificação aos seus próprios utilizadores, deve analisar um produto de envio como o Twilio Verify, não uma API de receção de números temporários.

Fontes: 5API de receção da SIM · API de envio do Twilio Verify

Perguntas comuns