Build custom
player engagement
with our iGaming
SMS API.
Powerful RESTful endpoints, native CRM plugins, and unparalleled developer support for custom workflows.
RESTful API endpoints
One JSON endpoint to send, one to look up state, one to schedule. Idempotency keys, cursor pagination and predictable error codes on every route.
Read the docsNative CRM plugins
Drop-in connectors for the platforms operator teams already run, so segments and consent flags sync both ways without a middleware layer.
Read the docsScalability and webhooks
Signed callbacks with exponential retry, per-key throughput ceilings you set yourself, and burst headroom for a jackpot minute.
Read the docsOne request
From a key to a delivered message
No SDK required and no onboarding call before you can try it. Provision a sandbox key, post one body, and read the same response shape production returns.
- Idempotency key honoured for twenty four hours
- Route and estimated accept time on the response
- Identical schema in sandbox and production
curl https://api.textreach.online/v2/messages \
-H "Authorization: Bearer $TEXTREACH_KEY" \
-H "Idempotency-Key: dep-4471-a" \
-d sender_id="LUXPLAY" \
-d to="+35679xxxxxx" \
-d template="deposit_bonus_v3" \
-d locale="en-MT"202 accepted
{
"id": "msg_01J9Q4TX",
"state": "queued",
"route": "MT-direct-01",
"segments": 1,
"eta_ms": 190
}Sandbox keys accept the same payloads and return simulated carrier codes, including the failures you want to test against.
median latency
210ms
gateway accept to carrier ack
peak throughput
18kmsg/s
sustained on a single key
gateway uptime
99.98%
rolling twelve months
direct networks
214
binds across 61 markets
Live throughput - eu-west gateway
Capacity is provisioned per key, so one operator's peak never becomes another's queue.
Surface area
Nine resources, not ninety
The whole platform is a handful of predictable routes. Here are the five you will touch in the first week.
/v2/messagesSend a message
Accepts a template reference or raw body, resolves the route from the destination and returns a queued id in under a quarter second.
/v2/messages/{id}Look up state
Full lifecycle for one message: queued, submitted, delivered or failed, with the carrier reason code attached.
/v2/sendersRegister a sender
Submit an alphanumeric sender for a market and track the registration through to approval without leaving the API.
/v2/webhooksSubscribe to events
Point an HTTPS endpoint at delivery, inbound and consent events. Payloads are signed and retried for twenty four hours.
/v2/consent/{msisdn}Check consent
Current opt-in state, source and timestamp for a number, so a send can be blocked before it is ever routed.
Plugs in
Native connectors, no middleware
Segments, consent flags and delivery state move both ways with the systems your operations team already lives in. Anything in-house talks to the same generic outbound connector.
Regulated by default
The rules live in the gateway
Compliance that depends on a campaign checklist eventually fails. These are enforced on the route, so a non-compliant send cannot physically leave the platform.
Licence-aware routing
Each key carries the markets you hold a licence in. A send to anything outside that set is rejected at the gateway with a 409 rather than filtered later.
Quiet hours per market
Local windows are applied from the destination number, not the account timezone. Messages that arrive inside a closed window are held, not dropped.
Consent as a first-class object
Opt-in state lives on the platform with its source and timestamp. Every send checks it, and every STOP writes back to it within one second.
Scoped keys and signed payloads
Keys are scoped per environment and per route class. Webhook bodies are HMAC signed so you can verify origin before you trust a state change.
In production
Notes from teams already shipping
We had a send working against the sandbox before the contract was signed. The thing that sold it internally was the error codes actually telling us what was wrong, rather than a generic 400.
Node, Postgres, Kubernetes
The consent object is the part I would keep. It moved a rule that used to live in three services into one place, and the gateway refusing the send is a much better failure mode than us discovering it in an audit.
Go, Kafka, GCP
Jackpot minutes used to mean a queue backing up somewhere. We set the ceiling to eighteen thousand a second for that window and watched the dashboard stay flat.
Python, Redis, AWS
Before you start
Questions engineering teams ask first
01
How long does a first integration take?
A sandbox send takes about ten minutes from key to receipt. A production launch is usually gated by sender registration on the destination networks rather than by code, which runs from three days to four weeks depending on the market.
02
Do you provide the routes or do we bring our own?
We provide them. Traffic runs over our direct binds, so there is no aggregator between you and the network and the reason codes you get back are the ones the carrier actually returned.
03
Can we send from our own sender identity?
Yes, and you should. We submit and maintain the registration per market on your behalf, and the API exposes the status so a stalled submission is visible rather than mysterious.
04
What happens when a market changes its rules?
Routing rules are versioned on the platform and updated as networks publish changes. Anything that would newly block your traffic surfaces as a warning event before it becomes a rejection.
05
Is there an SDK, or is it raw HTTP?
Both. There are maintained SDKs for Node, Python, PHP, Go and Java, and the OpenAPI description is published so you can generate your own. The HTTP surface is small enough to use directly.
06
How do you handle inbound replies and STOP?
Inbound arrives as an event on the same webhook subscription. STOP and its per-market equivalents are matched at the gateway and written to the consent object within a second, whether or not your consumer is up.
Something here not answered? Elias Fenech and the integration team answer tickets themselves.
Open a ticketStart against the sandbox today
Create a key, send one message and read the receipt. When you are ready for production, TextReach handles the sender registrations and the binds.