An API built for critical messaging
An SMS API lets your applications —core banking, CRM, ERP, e-commerce platform or your own backend— send text messages automatically, with no manual work. At Grupo Tecnophone we designed it for operations where every message matters: OTP codes, security alerts, transaction confirmations and large-scale notifications for banking, fintech, retail and government.
The difference between “sending an SMS” and running business messaging lies in everything around the send: strong authentication, control over where requests come from, number normalization, efficient encoding, traceability for every message and specialized support when something fails in production. Our platform has processed more than 140 million SMS with delivery rates above 99%.
Two ways to integrate: REST API and SMPP
| Aspect | REST API | SMPP |
|---|---|---|
| Protocol | HTTPS with JSON | Persistent TCP sessions (SMPP 3.4) |
| Best for | Applications and backends sending OTPs, alerts and notifications | Platforms with high, sustained traffic and teams with telecom experience |
| Authentication | Per-connection Bearer token + allowlisted IPs | Session credentials (system_id) + allowlisted IPs |
| Delivery reports | Webhooks to your endpoint | deliver_sm PDU within the session |
| Integration complexity | Low: one HTTP request per message | Medium-high: sessions, windowing and reconnection |
Most companies start with the REST API and consider an SMPP connection when sustained volume or their architecture justify it. Both share the same routing, reporting and support platform.
How the REST API works
- Create an API connection in the web panel (app.grupotecnophone.com) under API Connections → SMS.
- Copy the assigned Bearer Token, one for sandbox and one for production.
- Register the IP addresses your system will call from.
- Choose whether the connection uses plain text or content encryption.
- Validate your integration in the sandbox, which checks token, IP, payload and encryption without sending real SMS.
- Switch to the production endpoint.
A send request is a POST call with a JSON body containing the recipient and the text:
curl -X POST https://api.grupotecnophone.com/prod/v1/sms/send \
-H "Authorization: Bearer YOUR_TOKEN" \
-H "Content-Type: application/json" \
-H "User-Agent: MyCompany/1.0" \
-d '{"to":"+525512345678","body":"Your verification code is 482913. It expires in 5 minutes."}'The response includes a unique message identifier (sid), the applied encoding and the number of segments, so you can reconcile each send with its delivery report and with billing. The API documentation includes official examples in cURL, PHP, Python, Node.js and Java.
Security by design
- Mandatory HTTPS for all communication.
- Per-connection Bearer token, separate for sandbox and production.
- Allowlisted IPs: a request with a valid token from an unregistered IP is rejected.
- Optional content encryption: the destination number and the text can be sent encrypted with RSA-OAEP (SHA-256) and Base64.
- Identifiable User-Agent to audit which application originates each send.
- Blacklists to prevent sending to opted-out or blocked numbers.
Delivery reports (DLR) and webhooks
Knowing a message was sent is not enough: in critical operations you need to know it arrived. Each SMS generates a delivery report (DLR) with its final status, which the platform can push to your system via webhooks, with no polling. Webhooks, DLRs and encryption carry no extra cost: you pay per message sent. Learn more in how delivery reports and webhooks work.
Encoding and cost per segment
An SMS holds up to 160 characters in GSM-7 or 70 in UCS-2. A single unsupported accent can switch the encoding and double the segments. You choose the encoding per connection: with GSM-7, the platform automatically normalizes unsupported characters to avoid extra cost; with UCS-2 enabled, it uses GSM-7 whenever possible. See SMS character limits.
Number validation before sending
The API accepts numbers in E.164 or national format and normalizes the prefix according to the connection settings. Each number is also checked against Mexico’s National Numbering Plan to tell mobile from landline numbers, avoiding charges for messages that cannot be delivered.
Use cases
- OTP and authentication: sign-up, 2FA login, account recovery and transaction confirmation.
- Transactional SMS: confirmations, payment notices, data changes and order status.
- Banking and financial services: transaction, card and security alerts.
- Fintech: onboarding, identity verification and real-time notifications.
- Retail and e-commerce: orders, shipping and deliveries.
Engineering support, not just a help desk
We support your integration with specialized, priority support and build custom adaptations when your case requires it. To try the API with your own flow, we offer a 30-day pilot. See also our developer guide.
