Em que assenta a BulkGate, por onde as mensagens chegam às redes dos operadores, como protegemos o tráfego e o que isso significa para uma integração que tem de aguentar os picos. ## Três localizações O serviço funciona em vários servidores em **três localizações geográficas**. Não se trata de uma máquina com uma de reserva, mas de funcionamento em simultâneo — se qualquer uma das localizações falhar, as restantes assumem o tráfego **automaticamente e sem qualquer intervenção da sua parte**. Para a sua integração nada muda: `portal.bulkgate.com` continua a responder e os pedidos seguem pelo mesmo caminho. O que o failover não cobre é **o caminho até nós** — uma falha no seu fornecedor de conectividade, numa operadora ou em qualquer ponto do percurso entre o seu servidor e o nosso. Para isso existe o [servidor de reserva](https://www.bulkgate.com/pt/documentacao/administracao-da-api/servidor-de-reserva/). A infraestrutura foi concebida para resistir a falhas e está protegida contra DDoS pela **[WEDOS Global Protection](https://www.wedos.global/)**. O tráfego não chega diretamente aos nossos servidores — passa pela sua **rede anycast com mais de 120 nós**, onde o nó mais próximo o recebe. Um ataque é dispersado e filtrado do lado deles antes de chegar até nós; os nossos servidores lidam apenas com os pedidos legítimos que passam. O anycast também encurta o caminho do seu pedido, porque é o nó mais próximo de si que o recebe. A WEDOS guarda também os registos, a configuração e as análises **dentro da UE**, pelo que nem a proteção contra DDoS leva dados para fora da União — consulte [Servidores na UE](#servidores-na-ue). O estado atual do serviço está em **[bulkgate.status.online](https://bulkgate.status.online/en/)**. ## Servidores na UE Todos os nossos servidores funcionam **na União Europeia**. Os seus dados não saem, portanto, da UE e não tem de lidar com transferências para países terceiros nem com cláusulas contratuais-tipo. A forma como tratamos os dados pessoais está descrita nas [Condições de tratamento de dados pessoais](https://www.bulkgate.com/en/legal/agreement-on-personal-data-processing/) e na [Política de privacidade](https://www.bulkgate.com/en/legal/privacy-policy/). ## Ligações a operadores Entregamos as mensagens através de **ligações diretas a operadores** na Europa, na Ásia, em África e na América do Norte, Central e do Sul. ### O que significa 0-hop Uma ligação direta é uma **ligação 0-hop** — ninguém se interpõe entre nós e o SMSC do operador. A mensagem segue do nosso gateway diretamente para a rede de destino. É a **mais alta qualidade de entrega possível**; não existe melhor caminho até ao número de destino, porque não existe um mais curto. Cada intermediário no percurso é um ponto onde algo pode correr mal: | o que acontece num percurso através de intermediários | com 0-hop | |:-------------------------------------------------------------|:---------------------------------| | A mensagem fica à espera na fila de outro agregador. | Desaparece, o caminho é direto. | | Os relatórios de entrega chegam tarde ou incorretos. | O estado vem do próprio operador. | | A mensagem perde-se pelo caminho e ninguém sabe dizer onde. | O percurso tem apenas duas pontas. | | Cada elo fica com a sua margem. | Preço sem intermediários. | É por isso que criamos ligações diretas sempre que possível. Em grandes volumes e com mensagens urgentes — códigos OTP, confirmações de encomendas — a diferença nota-se mais. Hoje temos 0-hop para **mais de 50 países**, e o número continua a crescer. Onde não temos 0-hop, a primeira opção é um **fornecedor local** nesse país — um único intermediário que conhece o mercado local, não uma cadeia de agregadores. Só quando nem esse existe é que entregamos através de **hubs SMS**; mantemo-los como recurso para um número mínimo de destinos, não como o caminho habitual. ## RCS através de uma ligação direta à Google As ligações diretas não ficam pelo SMS. O RCS Business Messaging funciona na plataforma da Google. Temos uma **ligação direta** a ela e ainda **acordos próprios com os operadores** — ambos são necessários: a Google aprova o agente e o conteúdo, o operador deixa o tráfego entrar na sua rede. Sem qualquer um deles, uma mensagem RCS nunca chega ao destinatário. O que o RCS acrescenta em relação ao SMS: | o que obtém | em que difere | |:--------------------------|:----------------------------------------------------------------------------| | **Remetente verificado** | Nome da marca, logótipo e cor em vez de um número, com um selo de verificação diretamente na aplicação Mensagens. | | **Conteúdo rico** | Texto com [botões de sugestão](https://www.bulkgate.com/pt/documentacao/advanced-api/advanced-rcs/), um ficheiro, um cartão ou um carrossel de cartões. | | **Interação** | O destinatário responde com um botão em vez de escrever — o toque regressa até si como um evento. | | **Estados ao nível do chat** | Entregue e lida, não apenas enviada. | | **SMS como alternativa** | Se o destinatário não tiver RCS ou se a mensagem não for entregue dentro do tempo definido, a mensagem passa para o canal seguinte da [cascata](https://www.bulkgate.com/pt/documentacao/advanced-api/advanced-cascata-de-canais/). | Os tipos de mensagens e a forma como são faturados são abordados em [Tipos de mensagens RCS](https://www.bulkgate.com/pt/centro-de-ajuda/rcs/tipos-de-mensagens-rcs-business/); a configuração do agente em [Definições do chat RBM](https://www.bulkgate.com/pt/centro-de-ajuda/rcs/definicoes-do-chat-rcs/). ## Viber como parceiro oficial No **Viber** somos **[parceiro oficial](https://www.forbusiness.viber.com/en/messaging-partners/partner/bulkgate/)**, não revendedor — encontra-nos no diretório de parceiros de mensagens. As mensagens seguem, portanto, pelo caminho aprovado diretamente para a rede do Viber e registamos o seu remetente diretamente junto deles. O que isso significa na prática: | o que obtém | em que difere | |:---------------------------|:-------------------------------------------------------------------------| | **Remetente registado** | O nome da sua marca em vez de um número, com um perfil verificado. [Como o registar](https://www.bulkgate.com/pt/centro-de-ajuda/viber/registo-de-remetente-viber/) | | **Mais rico do que o SMS** | Texto, imagem e um botão com ligação numa só mensagem — sem o limite de 160 caracteres. Consulte [Viber – promocional](https://www.bulkgate.com/pt/documentacao/advanced-api/advanced-viber-promocional/). | | **Modelos transacionais** | Os modelos aprovados são faturados à tarifa transacional mais baixa. Consulte [Viber – transacional](https://www.bulkgate.com/pt/documentacao/advanced-api/advanced-viber-transacional/). | | **Paga apenas o que é entregue** | O Viber cobra apenas as mensagens nos estados DELIVERED e SEEN; o restante é reembolsado na sua conta quando expiram. Consulte [Estados do Viber](https://www.bulkgate.com/pt/centro-de-ajuda/viber/estados-das-mensagens-viber/). | | **SMS como alternativa** | Se o Viber não entregar dentro do tempo definido, a mensagem passa para o canal seguinte da [cascata](https://www.bulkgate.com/pt/documentacao/advanced-api/advanced-cascata-de-canais/). | Os tipos de mensagens e as sessões são abordados em [Tipos de mensagens Viber](https://www.bulkgate.com/pt/centro-de-ajuda/viber/tipos-de-mensagens-viber-business/). ## SMPP para grandes volumes Além da API HTTP, oferecemos aos clientes de maior dimensão uma **ligação SMPP** — o protocolo em que as próprias redes SMS funcionam. Compensa quando os volumes são constantemente elevados e precisa de manter uma sessão aberta em vez de enviar pedidos HTTP individuais. O SMPP é configurado individualmente; [contacte-nos](https://www.bulkgate.com/pt/contacto/) e analisaremos consigo os seus volumes e parâmetros. ## Priorização das mensagens Nem todas as mensagens podem esperar o mesmo. Um código para o qual o utilizador está a olhar num formulário tem de sair de imediato; uma campanha para cem mil números não sofre com um segundo a mais. Por isso, dividimos o tráfego em filas separadas e servimo-las por esta ordem: | prioridade | o que lhe pertence | |:--|:--| | **1. OTP** | [Códigos de utilização única](https://www.bulkgate.com/pt/documentacao/otp-api/envio-de-codigo-de-utilizacao-unica/). O utilizador está à espera deles em tempo real. | | **2. Transacionais** | Confirmação de encomenda, aviso de entrega, alerta — uma mensagem para um destinatário. | | **3. Transacionais em massa** | As mesmas mensagens enviadas em lote para vários números de uma vez. | | **4. Campanhas pequenas** | Um envio promocional para um número menor de destinatários. | | **5. Campanhas médias** | Um envio promocional de dimensão média. | | **6. Campanhas grandes** | Um envio promocional em grande escala. | As filas não se ultrapassam umas às outras: uma campanha grande já em curso não atrasa um código OTP que chegue a meio dela. > [!IMPORTANT] > **Exigimos que os clientes separem o tráfego transacional do promocional.** Não é uma recomendação — toda a priorização assenta nisso. Envie cada tipo de mensagem pelo endpoint a que pertence: uma [mensagem transacional](https://www.bulkgate.com/pt/documentacao/advanced-api/advanced-transactional/2.0/) pelo endpoint transacional, um envio promocional pelo endpoint [promocional](https://www.bulkgate.com/pt/documentacao/advanced-api/advanced-promotional/2.0/). Uma campanha com um só item em vez de uma mensagem transacional espera desnecessariamente na fila das campanhas; uma campanha enviada pelo endpoint transacional atrasa mensagens que alguém está à espera em tempo real e, além disso, é [estritamente proibida](https://www.bulkgate.com/pt/centro-de-ajuda/informacoes-gerais/diferenca-sms-promocional-e-transacional/). ## Proteção contra phishing e SMS pumping Avaliamos o tráfego continuamente para detetar duas coisas que prejudicam tanto os remetentes como os destinatários. **Phishing.** Cada mensagem é verificada em relação a padrões de campanhas fraudulentas conhecidas — tanto o ID do remetente como o texto, e separadamente para cada país de destino. A verificação tem também em conta **imitações**: deteta um nome ou uma formulação deliberadamente alterados em alguns caracteres para escapar a uma comparação literal. Isto protege a sua marca contra a usurpação de identidade e o seu ID de remetente contra danos de reputação junto do operador. **SMS pumping.** Tráfego gerado artificialmente (*AGT*) — um atacante faz passar códigos OTP pelo seu formulário para números de gamas premium e recebe uma parte do seu preço. Por isso, observamos o padrão do tráfego, não o seu conteúdo. Assim que detetamos tráfego que não corresponde ao que a conta normalmente envia — um aumento repentino ou destinos invulgares — **paramos o envio** e notificamo-lo por e-mail e SMS. O ataque é travado antes de ficar caro; o prejuízo fica limitado ao que já tiver sido enviado. > [!NOTE] > **A análise é anónima.** Decorre automaticamente sobre o padrão do tráfego, não sobre a identidade dos destinatários — ninguém lê as suas mensagens e não é criado nenhum perfil a partir delas. Isto corresponde ao que está descrito em [Servidores na UE](#servidores-na-ue). Pode prevenir um ataque ao seu próprio formulário definindo `request_quota_identification` e `request_quota_number` na [API OTP](https://www.bulkgate.com/pt/documentacao/otp-api/envio-de-codigo-de-utilizacao-unica/) — a quota está associada a quem faz o pedido, normalmente ao seu endereço IP. O portal acrescenta ainda restrições geográficas e limites diários de envio; a forma de os configurar é abordada em [Hacked OTP SMS: Protect yourself with BulkGate API limits!](https://www.bulkgate.com/en/blog/otp-sms-protection-bulkgate-api/). ## Segurança da comunicação e dos dados **Toda a comunicação passa por HTTPS.** A API não tem variante não encriptada — um pedido `http://` é redirecionado para HTTPS, mas o redirecionamento **não preserva o corpo do POST**, pelo que a mensagem não é enviada. Chame sempre diretamente `https://` e nunca confie no redirecionamento. Aceitamos **TLS 1.2 e 1.3**; as versões mais antigas TLS 1.0 e 1.1 são recusadas pelo servidor. Se a sua integração funcionar num ambiente mais antigo, certifique-se de que o respetivo cliente HTTP suporta TLS 1.2 — caso contrário, a ligação falha antes mesmo de o pedido ser enviado. O mesmo se aplica ao [servidor de reserva](https://www.bulkgate.com/pt/documentacao/administracao-da-api/servidor-de-reserva/). **A comunicação com os fornecedores é sempre encriptada.** A encriptação não termina no seu pedido. O segundo troço do percurso está protegido da mesma forma — quer a mensagem siga [0-hop](#o-que-significa-0-hop) diretamente para o operador, através de um fornecedor local ou através de um hub. **O portal está protegido por cabeçalhos de segurança.** Envia ao navegador os seguintes: - **[Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP)** — os scripts só são executados com um [`nonce`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/nonce) de utilização única. - **[`X-Content-Type-Options: nosniff`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Content-Type-Options)** — o navegador não pode adivinhar o tipo de conteúdo. - **[`X-Frame-Options: SAMEORIGIN`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Frame-Options)** — a página não pode ser incorporada numa moldura alheia, proteção contra clickjacking. - **[`Referrer-Policy: strict-origin-when-cross-origin`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy)** — um domínio alheio não recebe o caminho completo com os respetivos parâmetros. - **[`Feature-Policy`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Permissions-Policy)** — o microfone, a câmara e a API de pagamentos estão desativados no portal. **As palavras-passe NÃO são guardadas em texto simples.** É guardado apenas um hash **Argon2id** — a palavra-passe não pode ser reconstituída a partir da base de dados, mesmo que alguém lhe tenha acesso. Os códigos de utilização única são tratados da mesma forma: um [código OTP](https://www.bulkgate.com/pt/documentacao/otp-api/envio-de-codigo-de-utilizacao-unica/) é mantido na base de dados como hash Argon2id, não como número legível, pelo que ninguém do nosso lado o consegue ler. **Os tokens de API são encriptados na base de dados.** Um [token](https://www.bulkgate.com/pt/documentacao/administracao-da-api/tokens-de-api/) é guardado encriptado (AES-256), não como cadeia de caracteres legível. > [!CAUTION] > O token é a palavra-passe do seu crédito. Nunca o coloque em código executado num navegador ou numa aplicação móvel — qualquer pessoa o pode ler a partir daí. Chame a API a partir do seu próprio servidor e guarde o token numa configuração fora do seu repositório. ## Porque é que isto importa aos grandes clientes A diferença entre fornecedores não está em enviarem ou não a mensagem, mas **por que caminho**. Connosco, uma mensagem segue primeiro **0-hop** diretamente para a rede do operador; onde não temos essa ligação, através de um **fornecedor local** nesse país; e só num **número mínimo de casos** através de um **hub SMS**. Quanto mais acima nesta ordem a mensagem viajar, mais depressa chega, mais preciso é o seu relatório de entrega e menos mãos lhe tocam — e com centenas de milhares de mensagens por mês essa diferença nota-se tanto nas estatísticas de entrega como na fatura. O resto vem por acréscimo: funcionamento em **três localizações com failover automático**, um [servidor de reserva](https://www.bulkgate.com/pt/documentacao/administracao-da-api/servidor-de-reserva/) para uma falha no percurso, **servidores na UE** sem transferência de dados para países terceiros, **comunicação encriptada** em ambos os troços do percurso e **SMPP** para volumes com que a API HTTP começa a ter dificuldades. Sobre o próprio tráfego funciona a **proteção contra phishing e SMS pumping**, que trava um ataque ao seu formulário antes de ficar caro. Operamos o serviço **desde 2012**, pelo que pode construir sobre ele uma integração que não terá de reescrever daqui a um ano.