Infrastructure

What BulkGate runs on, how messages reach operator networks, how we protect the traffic and what it means for an integration that has to hold up at peak.

Three locations

The service runs on several servers in three geographical locations. This is not one machine with a spare, but concurrent operation — if any location goes down, the remaining ones take the traffic over automatically and with no action on your side. Nothing changes for your integration: portal.bulkgate.com keeps answering and requests go out the same way.

What the failover does not cover is the route to us — an outage at your connectivity provider, at a carrier or anywhere on the path between your server and ours. The backup server is there for that.

The infrastructure is built for outage resilience and is protected against DDoS by WEDOS Global Protection. Traffic does not reach our servers directly — it passes through their anycast network of 120+ nodes, where the nearest one picks it up. An attack is spread out and filtered on their side before it ever reaches us; our servers deal only with the legitimate requests that get through. Anycast also shortens the path of your request, because the node closest to you takes it.

WEDOS keeps logs, configuration and analytics inside the EU as well, so not even the DDoS protection takes data outside the union — see Servers in the EU.

The current service status is at bulkgate.status.online.

Servers in the EU

All our servers run in the European Union. Your data therefore does not leave the EU and you do not have to deal with transfers to third countries or standard contractual clauses.

How we handle personal data is described in the Personal data processing terms and the Privacy policy.

Operator connections

We deliver messages over direct operator connections in Europe, Asia, Africa and in North, Central and South America.

What 0-hop means

A direct connection is a 0-hop connection — nobody else stands between us and the operator's SMSC. The message goes from our gateway straight into the destination network. It is the highest possible delivery quality; there is no better route to the destination number, because there is no shorter one.

Every intermediary on the route is a place where something can go wrong:

That is why we build direct connections wherever we can. At high volumes and with time-critical messages — OTP codes, order confirmations — the difference shows the most.

Today we have 0-hop into more than 50 countries, and the number keeps growing.

Where we have no 0-hop, the first choice is a local provider inside that country — one intermediary that knows the local market, not a chain of aggregators. Only when there is not even one of those do we deliver through SMS hubs; we keep those as a fallback for a minimum of destinations, not as the usual route.

RCS over a direct Google connection

Direct connections do not stop at SMS. RCS Business Messaging runs on Google's platform. We have a direct connection to it plus our own agreements with operators — both are needed: Google approves the agent and the content, the operator lets the traffic into its network. Without either one an RCS message never reaches the recipient.

What RCS adds over SMS:

Message types and how they are billed are covered in RCS message types; agent setup in RBM chat settings.

Viber as an official partner

For Viber we are an official partner, not a reseller — you will find us in their messaging partner directory. Messages therefore go out over the approved route straight into Viber's network and we register your sender directly with them.

What that means in practice:

Message types and sessions are covered in Viber message types.

SMPP for high volumes

Alongside the HTTP API we offer larger customers an SMPP connection — the protocol the SMS networks themselves run on. It pays off where volumes are consistently high and you need to keep a session open instead of sending individual HTTP requests.

SMPP is set up individually; get in touch and we will go through your volumes and parameters.

Message prioritisation

Not every message can wait the same. A code the user is staring at in a form has to go out immediately; a campaign to a hundred thousand numbers will not suffer from one extra second. We therefore split the traffic into separate queues and serve them in this order:

The queues do not overtake each other: a large campaign already in flight will not hold up an OTP code that arrives in the middle of it.

Protection against phishing and SMS pumping

We evaluate traffic continuously to catch two things that hurt senders and recipients alike.

Phishing. Every message is checked against patterns of known fraudulent campaigns — both the sender ID and the text, and separately for each destination country. The check also accounts for lookalikes: it catches a name or wording deliberately altered by a few characters to slip past a literal comparison. This protects your brand from being impersonated and your sender ID from a reputation hit at the operator.

SMS pumping. Artificially generated traffic (AGT) — an attacker pushes OTP codes through your form to numbers in premium ranges and collects a share of their price. We therefore watch the shape of the traffic, not its content. As soon as we see traffic that does not match what the account normally sends — a sudden surge or unusual destinations — we stop the sending and notify you by e-mail and SMS. The attack is cut off before it gets expensive; the damage stays at whatever has already gone out.

You can head off an attack on your own form by setting request_quota_identification and request_quota_number in the OTP API — the quota is bound to the requester, typically their IP address. The portal adds geographical restrictions and daily send limits on top of that; how to set them up is covered in Hacked OTP SMS: Protect yourself with BulkGate API limits!.

Communication and data security

All communication runs over HTTPS. The API has no unencrypted variant — an http:// request is redirected to HTTPS, but the redirect does not preserve the POST body, so the message is not sent. Always call https:// directly and never rely on the redirect.

We accept TLS 1.2 and 1.3; the older TLS 1.0 and 1.1 are refused by the server. If your integration runs on an older environment, make sure its HTTP client can do TLS 1.2 — otherwise the connection fails before the request is even sent. The same applies to the backup server.

Communication with providers is always encrypted. The encryption does not stop at your request. The second leg of the route is protected the same way — whether the message goes 0-hop straight to the operator, through a local provider, or through a hub.

The portal is protected by security headers. It sends the browser these:

• Content Security Policy — scripts only run with a one-time nonce.
• X-Content-Type-Options: nosniff — the browser must not guess the content type.
• X-Frame-Options: SAMEORIGIN — the page cannot be embedded in a foreign frame, clickjacking protection.
• Referrer-Policy: strict-origin-when-cross-origin — a foreign domain is not given the full path with its parameters.
• Feature-Policy — microphone, camera and the payment API are switched off in the portal.

Passwords are NOT stored in plaintext. Only an Argon2id hash is kept — the password cannot be derived back from the database, even if someone got hold of it. One-time codes are handled the same way: an OTP code is held in the database as an Argon2id hash, not as a readable number, so nobody on our side can read it.

API tokens are encrypted in the database. A token is stored encrypted (AES-256), not as a readable string.

Why large customers care

The difference between providers is not whether they send the message, but which way. With us a message goes 0-hop straight into the operator's network first; where we have no such connection, through a local provider in that country; and only in a minimum of cases through an SMS hub. The higher up this order a message travels, the sooner it arrives, the more accurate its delivery report and the fewer hands touch it — and at hundreds of thousands of messages a month that difference shows in the delivery statistics and on the invoice alike.

The rest comes on top: operation across three locations with automatic failover, a backup server for an outage on the route, servers in the EU with no data transfer to third countries, encrypted communication on both legs of the route, and SMPP for volumes the HTTP API starts to struggle with. On top of the traffic itself runs protection against phishing and SMS pumping, which stops an attack on your form before it gets expensive. We have been running the service since 2012, so you can build an integration on it that you will not be rewriting a year from now.