--- title: "Como escolher uma API de mensagens: checklist para CTOs" description: "Como escolher uma API de mensagens: checklist para CTOs sobre canais, qualidade de rota, webhooks, segurança, limites, retentativas, SMPP, MCP, compliance e preços." canonical: "https://omnichannels.ai/pt/blog/messaging-api-buyers-checklist/" language: "pt" updated: "2026-10-10" publisher: "BroadNet Technologies" brand: "OmniChannels.ai" category: "integration" primaryQuery: "how to choose a messaging api" keywords: ["como escolher api de mensagens", "checklist de api de mensagens", "critérios de avaliação de cpaas", "comparar fornecedores de api de sms", "rotas diretas vs rotas cinza", "webhooks de api de mensagens", "segurança de api de mensagens", "limites de requisição de api de sms", "servidor mcp para api de mensagens"] published: "2026-10-10" author: "OmniChannels.ai Editorial Team" reviewer: "BroadNet Messaging Solutions Team" readingMinutes: 13 answer: "Escolha uma API de mensagens com base em evidências, não em listas de recursos. Verifique se ela cobre os canais de que você precisa em uma única integração, usa rotas diretas com as operadoras, envia status de entrega normalizados para webhooks, autentica com segurança, documenta limites e erros e explica como fazer retentativas sem duplicatas. Depois confirme acesso de teste, opção de SMPP para volume, acesso seguro para agentes de IA, suporte a compliance, termos de suporte claros e uma tabela de preços publicada. Dê nota a cada fornecedor com um teste real." takeaways: ["A qualidade da rota decide se as mensagens chegam com o ID de remetente (Sender ID) correto, então pergunte como o tráfego chega a cada operadora e confirme em aparelhos reais.", "Uma chamada de API aceita significa que a mensagem entrou na fila, não que foi entregue; o resultado final chega depois, por webhooks ou relatórios de entrega SMPP.", "Nem toda API de mensagens aceita uma chave de idempotência, então verifique como o fornecedor espera que você evite envios duplicados após um timeout.", "Limites documentados, uma resposta 429 com Retry-After e códigos de erro legíveis por máquina são sinais de uma API feita para tráfego de produção.", "Uma tabela de pontuação ponderada, preenchida depois de um teste prático, gera uma decisão mais defensável do que comparar páginas de marketing."] faq: - q: "Qual é o fator mais importante na escolha de uma API de mensagens?" a: "Para a maioria das empresas, é a qualidade de entrega nas rotas que importam para você: se as mensagens chegam aos aparelhos nos seus países-alvo, com o seu ID de remetente cadastrado e com relatórios de entrega reais. Recursos e preço só importam quando a entrega é confiável. Teste isso diretamente, enviando para aparelhos reais em cada grande operadora dos seus mercados durante a avaliação." - q: "Qual é a diferença entre rotas diretas com operadoras e rotas cinza?" a: "Rota direta significa que o fornecedor se conecta à operadora móvel, ou a um parceiro autorizado, sob um acordo que cobre aquele tipo de tráfego. Uma rota cinza entrega tráfego application-to-person por canais que não foram feitos para isso, como conexões de chips de consumidor. Rotas cinza podem parecer baratas, mas trazem o risco de IDs de remetente substituídos, tráfego bloqueado e relatórios de entrega pouco confiáveis." - q: "Preciso de um fornecedor com suporte a SMPP?" a: "Só se você envia grandes volumes de SMS, já opera clientes SMPP ou revende SMS para seus próprios clientes. A maioria das aplicações é mais bem atendida por uma API REST, que é mais simples de proteger e também cobre WhatsApp, RCS e outros canais. Escolher um fornecedor que oferece as duas opções mantém o SMPP disponível sem impô-lo desde o primeiro dia." - q: "Como uma API de mensagens deve lidar com retentativas?" a: "A API deve documentar quais erros podem ser repetidos com segurança, retornar 429 com o cabeçalho Retry-After quando você ultrapassa um limite e explicar como evitar mensagens duplicadas. Alguns fornecedores aceitam uma chave de idempotência; outros esperam que você registre cada envio antes de fazê-lo e verifique o status após um timeout. As duas abordagens funcionam se estiverem documentadas e você as implementar." - q: "Agentes de IA devem ter acesso à nossa API de mensagens?" a: "Podem ter, desde que o acesso seja controlado. Um servidor Model Context Protocol (MCP) permite que agentes chamem ferramentas de mensagens com um token, então aplique as mesmas regras de qualquer integração: privilégio mínimo, chaves temporárias para experimentos, confirmação humana antes de envios, números de teste primeiro e revisão de logs. Os agentes devem seguir as mesmas regras de consentimento e de ID de remetente que as pessoas." - q: "O que perguntar sobre suporte e SLAs?" a: "Pergunte como os incidentes são reportados e comunicados, quais horários e idiomas o suporte cobre, quem cuida de problemas no nível da operadora, como IDs de remetente bloqueados, com que rapidez os tokens podem ser revogados e o que o contrato efetivamente garante. Obtenha as respostas no contrato, não em uma apresentação comercial, e pergunte como funcionam os créditos de serviço se os compromissos não forem cumpridos." sources: - title: "OWASP Top 10 API Security Risks – 2023" url: "https://owasp.org/API-Security/editions/2023/en/0x11-t10/" - title: "RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage" url: "https://www.rfc-editor.org/rfc/rfc6750" - title: "RFC 6585: Additional HTTP Status Codes (429 Too Many Requests)" url: "https://www.rfc-editor.org/rfc/rfc6585" - title: "OpenAPI Specification v3.1.0" url: "https://spec.openapis.org/oas/v3.1.0" - title: "Model Context Protocol specification" url: "https://modelcontextprotocol.io/specification/2025-06-18" - title: "Short Message Peer to Peer Protocol Specification v3.4 (SMPP.org)" url: "https://smpp.org/SMPP_v3_4_Issue1_2.pdf" --- # Como escolher uma API de mensagens: checklist para CTOs Canonical: https://omnichannels.ai/pt/blog/messaging-api-buyers-checklist/ Language: pt Publisher: OmniChannels.ai by BroadNet Technologies Este checklist é para CTOs, líderes de engenharia e arquitetos que estão escolhendo uma API de mensagens para SMS, WhatsApp, RCS e outros canais. Ele transforma uma comparação vaga de fornecedores em perguntas específicas, testes que você consegue rodar em uma tarde e uma tabela de pontuação que você consegue defender diante das equipes de finanças e de segurança. Se você já escolheu um fornecedor e precisa construir a integração, leia nosso [guia de integração de API de mensagens](/pt/blog/messaging-api-integration-guide/). Este artigo trata da decisão anterior a isso. ## O que um CTO deve avaliar em uma API de mensagens? Avalie o que afeta os resultados em produção: se as mensagens chegam, se você consegue ver o que aconteceu, se a integração sobrevive a falhas e se ela continua em compliance. As listas de recursos são parecidas entre fornecedores; essas propriedades, não. | Área | A pergunta que importa | Evidência a pedir | |---|---|---| | Canais | Uma única integração cobre todos os canais de que precisamos? | Referência da API por canal, um único esquema de autenticação | | Qualidade de rota | Como o tráfego chega a cada operadora? | Descrição das rotas, testes em aparelhos | | Visibilidade da entrega | Como ficamos sabendo do status final? | Documentação de webhooks, lista de status, opções de reenvio | | Segurança | Como as credenciais são emitidas, guardadas e revogadas? | Documentação de autenticação, certificações, processo de rotação | | Limites e erros | O que acontece se enviarmos rápido demais ou algo errado? | Limites publicados, corpo de erro, orientação de retentativa | | Experiência do desenvolvedor | Um engenheiro consegue enviar uma mensagem real só com a documentação? | Especificação OpenAPI, SDKs, exemplos de código | | Duplicatas | Como fazer retentativas sem enviar em dobro? | Orientação sobre idempotência | | Acesso de teste | Conseguimos testar com segurança antes da produção? | Credenciais de teste, números verificados | | Alto volume | Existe opção de SMPP? | Documentação de SMPP, provisionamento de binds | | Agentes de IA | Agentes conseguem usar a API com limites de segurança? | Documentação do servidor MCP | | Compliance | IDs de remetente, consentimento, proteção de dados | Processo de cadastro, certificações | | Suporte | Quem ajuda quando algo quebra? | Termos de suporte por escrito | | Preços | Conseguimos prever a fatura? | Tabela de preços, modelo de cobrança | ## A API cobre os canais de que você precisa? Procure uma única URL base, um único esquema de autenticação e um único modelo de status de entrega para todos os canais. Integrações separadas por canal multiplicam o código a manter e os pontos em que um status pode se perder. - **Liste os canais dos próximos dois anos**, não só os de hoje. Equipes que começam com OTP por SMS costumam acrescentar modelos de WhatsApp, depois RCS, depois e-mail ou push. - **Verifique a profundidade de cada canal**, não apenas o logotipo. No WhatsApp, dá para gerenciar modelos, enviar mensagens interativas e acompanhar a aprovação pela API? No SMS, há mensagens bidirecionais, Unicode e consulta de número? - **Verifique o fallback.** Se uma mensagem de WhatsApp não for entregue, a plataforma consegue cair para RCS ou SMS, e a ordem é configurável por caso de uso? Nossa [comparação entre WhatsApp, SMS e RCS](/pt/blog/whatsapp-vs-sms-vs-rcs/) explica quando cada canal se encaixa. ## Como avaliar a qualidade da rota? Pergunte como o fornecedor chega a cada operadora nos seus principais mercados e depois confirme você mesmo. A qualidade da rota determina se a mensagem chega, se o seu ID de remetente é preservado e se o relatório de entrega reflete o que realmente aconteceu. Uma **rota direta** significa que o fornecedor se conecta à operadora, ou a um parceiro autorizado, sob um acordo que cobre o tráfego application-to-person (A2P). Uma **rota cinza** empurra tráfego A2P por caminhos que não foram feitos para isso, como conexões de chips de consumidor. Rotas cinza podem parecer mais baratas na tabela de preços, mas trazem riscos reais: - o ID de remetente é substituído por um número aleatório, o que quebra a confiança e o hábito de preenchimento automático do OTP; - as operadoras detectam e bloqueiam o tráfego, às vezes no meio de uma campanha; - os relatórios de entrega podem ser gerados pela rota e não pela rede, então "entregue" pode não significar entregue. Perguntas a fazer: 1. Quais dos nossos países e operadoras de destino vocês alcançam diretamente? 2. Como vocês tratam o cadastro de ID de remetente em cada país? 3. De onde vêm os seus relatórios de entrega, e vocês repassam o código de erro da operadora? 4. O que acontece com o nosso tráfego quando uma rota se degrada? O redirecionamento é automático, e vocês nos avisam? Depois teste: envie para aparelhos reais em cada grande operadora, verifique o ID de remetente exibido e compare os relatórios de entrega com o que os celulares mostram. Veja [o que é SMS A2P](/pt/blog/what-is-a2p-sms/) para entender como o SMS corporativo chega às operadoras. ## Como são tratados os relatórios de entrega e os webhooks? O fornecedor deve enviar os status de entrega para o seu endpoint HTTPS, em um formato normalizado para todos os canais, e oferecer uma forma de recuperar eventos perdidos. Consultar mensagem por mensagem (polling) não é um desenho sustentável. Como é o ideal: - **Uma lista de status documentada.** Por exemplo, SUBMITTED, SENT, DELIVERED, READ, FAILED e REJECTED, indicando quais são finais. Nosso guia de [status de entrega](/pt/blog/message-delivery-status-explained/) explica o que cada um significa na prática. - **Motivos de falha.** Um status FAILED ou REJECTED deve trazer o motivo da operadora ou do canal, quando existir. - **Recuperação.** Se o seu endpoint cair, dá para pedir o reenvio dos relatórios de entrega de um intervalo de datas ou consultar o status por destinatário? - **Orientação honesta sobre ordem e duplicatas.** Eventos podem chegar fora de ordem e mais de uma vez. Uma documentação que diz isso é mais confiável do que uma que ignora o assunto. - **Segurança do endpoint.** Pergunte se os webhooks são assinados. Se não forem, o fornecedor deve explicar como proteger o endpoint, por exemplo apenas HTTPS, um caminho difícil de adivinhar, validação rigorosa do corpo e confirmação do estado antes de ações irreversíveis. ## Que autenticação e segurança esperar? No mínimo: tokens enviados no cabeçalho `Authorization` sobre TLS, nunca em URLs; um processo claro para rotacionar e revogar credenciais; e controles de segurança auditados de forma independente. Os tokens Bearer são definidos na RFC 6750, e o OWASP API Security Top 10 é uma boa lista para percorrer com o fornecedor. Pergunte: - **Como os tokens são emitidos, delimitados e revogados?** É possível ter tokens separados por serviço ou ambiente? Com que rapidez um token vazado é revogado? - **As credenciais são passadas como parâmetros de URL?** Algumas APIs HTTP legadas ainda recebem usuário e senha na query string, onde acabam parando em logs. Evite isso em integrações novas. - **Há allow-list de IPs, e onde?** É comum em binds SMPP; verifique se vale também para a REST. - **Quais certificações cobrem o serviço?** Peça o certificado ou o relatório, não apenas um logotipo, e verifique o escopo. - **Onde o conteúdo das mensagens é armazenado, e por quanto tempo?** Isso importa nas análises de proteção de dados, como as exigidas pela LGPD. ## Que limites e throughput planejar? Espere limites padrão documentados, uma resposta `429 Too Many Requests` (RFC 6585) com o cabeçalho `Retry-After` quando você os ultrapassar e um processo para acordar tetos maiores nos picos de produção. Limites não documentados são descobertos durante a sua maior campanha. - **Peça os limites por interface**: requisições REST, binds SMPP e consultas de número costumam ter limites separados. - **Verifique os endpoints de envio em massa.** Enviar uma requisição com um arquivo de destinatários respeita muito mais os limites do que milhares de requisições individuais. - **Pergunte como os picos são tratados.** Promoções relâmpago e alertas de incidente exigem planejamento com o fornecedor, não esperança. - **Planeje o seu lado.** Uma fila e um limitador token bucket na frente da API mantêm vários workers dentro da sua cota. Nossa [referência de erros e limites](/developers/errors-and-limits/) mostra como essa documentação fica na prática. ## Qual é a qualidade dos SDKs e da documentação? Uma boa documentação permite que um engenheiro envie uma mensagem real, receba um status e trate um erro sem abrir um chamado de suporte. Peça o documento OpenAPI; um fornecedor que mantém um consegue oferecer clientes gerados, coleções do Postman e nomes de campos precisos. Sinais de qualidade: - uma especificação OpenAPI 3.x que corresponde à API em produção; - pelo menos um SDK mantido e exemplos em HTTP puro para as outras linguagens; - nomes exatos dos campos das requisições, um corpo de erro documentado com código legível por máquina e exemplos de respostas; - um quickstart que termina com um status de entrega, não apenas com "200 OK"; - observações honestas sobre o que não é suportado. ## Como a API lida com retentativas e duplicatas? Uma requisição de envio pode dar certo no servidor enquanto a resposta se perde, então uma retentativa às cegas envia a mesma mensagem duas vezes ao cliente. Pergunte como o fornecedor espera que você evite isso. Algumas APIs aceitam uma chave de idempotência: você envia um valor único com a requisição, e uma repetição com o mesmo valor devolve o resultado original. Outras, como a nossa, não aceitam; o padrão documentado então é registrar cada envio no seu banco de dados antes de fazê-lo, guardar o ID da mensagem retornado e, após um timeout, procurar evidências de aceite antes de reenviar. As duas abordagens funcionam se estiverem documentadas. O que não funciona é um fornecedor que nunca pensou no assunto. A [página de erros e limites](/developers/errors-and-limits/) mostra o padrão de registrar antes de enviar. ## Existe acesso de teste seguro? Você deve conseguir testar com mensagens reais para números que controla antes que qualquer tráfego chegue aos clientes. Pergunte como é o acesso de teste: um sandbox que simula respostas ou envios reais restritos a números verificados. Sandboxes simulados são úteis para testes unitários, mas raramente reproduzem o comportamento das operadoras. Envios reais para números verificados mostram como o ID de remetente realmente aparece, a codificação e os relatórios de entrega. Pergunte quanto tempo leva para passar do acesso de teste ao de produção, já que as aprovações de ID de remetente em alguns países seguem o calendário do regulador. ## Você precisa de uma opção de SMPP? Provavelmente não no primeiro dia, mas talvez mais adiante. O SMPP v3.4 é o protocolo de telecom para troca de SMS por uma conexão persistente e serve para volume alto e constante de SMS, agregadores e revendedores. Pergunte se o fornecedor oferece SMPP sobre TLS, como os binds são provisionados e se as rotas são as mesmas da REST. Nosso [guia de API de SMS vs SMPP](/pt/blog/sms-api-vs-smpp/) compara as duas em detalhe. ## Agentes de IA conseguem usar a API com segurança? Se as suas equipes usam assistentes de IA ou constroem agentes, um servidor Model Context Protocol (MCP) permite que eles descubram e chamem ferramentas de mensagens sem código de integração sob medida. Pergunte o que o agente pode fazer e com quais permissões. Perguntas a fazer: - O servidor MCP age com o mesmo token e as mesmas permissões do nosso próprio código? - Podemos habilitar só as ferramentas de que o agente precisa, como relatórios de entrega sem as ferramentas de envio? - Há chaves temporárias para experimentos? - Os envios aparecem nos mesmos relatórios de entrega, para que possamos auditar o comportamento do agente? Veja nossa [documentação do servidor MCP](/developers/mcp/) como exemplo desses controles. ## Que suporte a compliance o fornecedor deve oferecer? O fornecedor deve ajudar você a cadastrar IDs de remetente onde for exigido, apoiar o tratamento de descadastros (opt-outs) e processar dados sob controles reconhecidos de segurança e privacidade. A responsabilidade pelo consentimento continua sendo sua; o fornecedor deve torná-la viável na prática. - **IDs de remetente:** alguns países exigem o cadastro de IDs de remetente alfanuméricos, e alguns exigem identificadores regulatórios em cada mensagem. Veja nosso [guia de cadastro de ID de remetente nos Emirados Árabes Unidos e na Arábia Saudita](/pt/blog/sms-sender-id-registration-uae-saudi/). - **Consentimento:** pergunte como os descadastros são capturados no SMS bidirecional e como chegam aos seus sistemas. Nosso [guia de consentimento](/pt/blog/opt-in-consent-multichannel-campaigns/) trata das obrigações. - **Proteção de dados:** pergunte sobre acordos de tratamento de dados, local de hospedagem, retenção e suboperadores. ## O que perguntar sobre suporte e SLAs? Trate os termos de suporte como parte do produto e obtenha-os por escrito. Não compare os números de destaque do material comercial; compare o que o contrato efetivamente garante. - Como os incidentes são detectados, comunicados e encerrados? - Quais horários, fusos e idiomas o suporte cobre? - Quem cuida de problemas do lado da operadora, como um ID de remetente bloqueado em um país? - Há um contato designado ou um engenheiro de onboarding durante a integração? - O que o contrato garante, como isso é medido e o que acontece se não for cumprido? ## Quão transparentes são os preços? Você deve conseguir estimar a fatura mensal a partir de uma tabela de preços publicada e dos seus volumes. Pergunte: - Os preços são por mensagem, por segmento ou por mensagem entregue, e isso varia por canal? - Quais taxas de terceiros são repassadas separadamente, como as cobranças da Meta no WhatsApp? - A cobrança é pré-paga ou pós-paga, e o que acontece se o crédito acabar no meio de uma campanha? - Consulta de número, cadastro de ID de remetente e binds SMPP dedicados são cobrados à parte? Lembre-se de que mensagens Unicode e longas usam mais segmentos de SMS. Nosso [guia de limites de caracteres](/pt/blog/sms-character-limits-unicode-arabic/) explica por que uma campanha em árabe, ou com acentos fora do GSM-7, pode custar mais do que a versão em inglês. ## Como pontuar os fornecedores? Rode o mesmo teste prático com cada fornecedor da lista curta e depois pontue todos em uma única tabela. Pondere os critérios conforme as suas prioridades; os pesos abaixo são um ponto de partida, não um padrão. ### Procedimento de pontuação 1. Faça uma lista curta de dois a quatro fornecedores que cubram seus canais e países. 2. Peça acesso de teste a cada um e anote quanto tempo leva. 3. Rode o smoke test abaixo com cada fornecedor. 4. Envie para aparelhos reais em cada grande operadora dos seus principais mercados. 5. Faça por escrito as perguntas de cada seção acima. 6. Dê nota de 1 a 5 a cada critério, multiplique pelo peso e some. 7. Revise as duas melhores pontuações com segurança, finanças e o time que vai operar a integração. | Critério | Peso sugerido | Fornecedor A | Fornecedor B | Fornecedor C | |---|---|---|---|---| | Qualidade de rota e entrega nos seus mercados | 5 | | | | | Relatórios de entrega e webhooks | 4 | | | | | Segurança e gestão de credenciais | 4 | | | | | Documentação, OpenAPI e SDKs | 3 | | | | | Limites, erros e orientação de retentativa | 3 | | | | | Cobertura de canais e fallback | 3 | | | | | Compliance e suporte a ID de remetente | 3 | | | | | Termos de suporte | 3 | | | | | Transparência de preços | 3 | | | | | Acesso de teste | 2 | | | | | Opção de SMPP | 2 | | | | | Acesso para agentes de IA (MCP) | 1 | | | | ### Um smoke test rápido A documentação de cada fornecedor deve permitir algo assim. Esta é a chamada equivalente na nossa API, como mostrado no [quickstart](/developers/quickstart/): ```bash curl -X POST https://api.broadnet.me/sms/sendSms \ -H "Authorization: Bearer $BROADNET_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "senderId": "OmniDemo", "destinationNumber": "447700900123", "message": "Your OmniDemo code is 482913", "messageType": "TEXT" }' ``` Uma chamada bem-sucedida retorna `200 OK` com o ID da mensagem em texto simples. Durante o teste, verifique mais quatro coisas: o que acontece com um token deliberadamente inválido (espere `401`), com um número malformado (espere um `400` com código de erro), com uma mensagem em árabe ou em português acentuado (ela precisa ser enviada como Unicode; veja a [referência da API de SMS](/developers/sms/)) e se um status DELIVERED chega ao seu [webhook](/developers/webhooks/). ## Exemplo prático: uma fintech escolhe um fornecedor de OTP e alertas A "Nakheel Pay" (fictícia), um app de pagamentos na Arábia Saudita e nos Emirados Árabes Unidos, precisa de OTP por SMS agora e de alertas de transação pelo WhatsApp dentro de um ano. - **Lista curta:** três fornecedores que cobrem os dois países e os dois canais. - **Smoke test:** o acesso de teste de um fornecedor chega em poucos dias; outro exige um longo processo comercial antes de qualquer teste. Isso é registrado no critério de acesso de teste. - **Testes em aparelhos:** em um fornecedor, o ID de remetente cadastrado aparece em todas as operadoras testadas; em outro, uma operadora mostra um remetente numérico. Esse fornecedor é questionado sobre a rota e recebe nota baixa em qualidade de rota. - **Duplicatas:** a equipe confirma como cada fornecedor lida com retentativas. Um aceita chave de idempotência; outro documenta o padrão de registrar antes de enviar. Os dois são aceitáveis; a equipe implementa o padrão uma única vez no seu serviço de envio. - **Análise de segurança:** o time de segurança verifica o escopo dos certificados e o processo de revogação de tokens. - **Decisão:** a tabela ponderada favorece o fornecedor com rotas diretas, webhooks normalizados e opção de SMPP para o crescimento futuro, mesmo que outro tivesse um preço de SMS de vitrine um pouco menor. ## Erros comuns na escolha de uma API de mensagens - **Escolher só pelo preço por mensagem.** Mensagens não entregues e IDs de remetente substituídos custam mais do que economizam. - **Testar apenas em um sandbox simulado.** O comportamento das operadoras só aparece em aparelhos reais. - **Ignorar duplicatas.** Um loop de retentativa sem proteção envia OTPs em dobro. - **Tratar "enviado" como "entregue".** Pergunte como os status finais são reportados. - **Deixar a análise de segurança** para depois da integração, quando trocar de fornecedor sai caro. - **Aceitar compromissos verbais.** Os termos de suporte e de serviço devem estar no contrato. - **Limites deste checklist:** ele descreve boas práticas, não constitui aconselhamento jurídico. Confirme as regras de cada país com os reguladores e com seu fornecedor. ## Como a OmniChannels.ai ajuda A OmniChannels.ai oferece uma única API REST em `https://api.broadnet.me` para SMS, WhatsApp, RCS, Messenger, Instagram, Telegram, Email e Push, com autenticação por token Bearer, cerca de 330 caminhos documentados, uma especificação OpenAPI 3.1 e o SDK TypeScript `@broadnet/cpaas-sdk`. Os status de entrega chegam ao seu webhook em um único formato. SMPP 3.4 sobre TLS está disponível para SMS de alto volume, e um [servidor MCP](/developers/mcp/) permite que agentes de IA usem a mesma API. O tráfego passa pelas conexões diretas da BroadNet com mais de 1.000 operadoras e agregadores. O acesso de teste vai para os seus próprios números verificados; comece pela [visão geral para desenvolvedores](/pt/developers/).