OTP SMS in Bangladesh: verification codes, any time of day

For logins, sign-ups, password resets and payment confirmations, SMS remains the most widely available second factor in Bangladesh. It works on every handset, including feature phones, and does not require the user to install anything.

GotiSMS treats OTP as its own category. Unlike promotional messages, which are restricted to 09:00–21:00 Bangladesh time, OTP and transactional messages can be sent at any time. A customer resetting a password at 2 a.m. gets the code just as they would at noon.

OTP traffic is sent through the same API as other transactional messages, using category: "otp", so there is no separate product to integrate.

Here is a minimal cURL example. Replace YOUR_API_KEY with a key from your dashboard and use your approved sender ID or default non-masking sender.

curl -X POST https://api.gotisms.com/api/messages/send \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: otp-7f3a9c21-login" \
  -d '{
    "recipients": ["01712345678"],
    "senderId": "YourBrand",
    "message": "Your YourBrand code is 482913. It expires in 5 minutes. Do not share it.",
    "category": "otp"
  }'

A successful response means the message was accepted, not yet delivered. Delivery status is available through the reports endpoints or on the Campaigns page. Full request and response details are in the API documentation.

Networks fail. A request might time out on your side even though GotiSMS received it. If your code simply retries, a naive gateway would send the customer two codes and charge you twice.

The Idempotency-Key header prevents that. Generate a unique key for each OTP you intend to send, for example from your verification attempt ID, and reuse the same key if you need to retry that request. GotiSMS recognises the key and will never send or charge for the same message twice.

Good practice:

• Create the key once, when the OTP is generated, and store it with the attempt.
• Use a new key when the user explicitly asks for a new code.
• Never reuse a key across different users or messages.

Billing is per SMS part, and shorter messages also tend to be read faster. For OTP, aim for a single part:

• English (GSM-7) fits 160 characters in one SMS, which is plenty for a code, your brand name and an expiry note.
• Bangla (Unicode) fits only 70 characters. A Bangla OTP message can work well for local audiences, but keep it short.
• Avoid emoji and special symbols. One emoji switches the entire message to Unicode, cutting the limit from 160 to 70.

Many services send the OTP in English even when the app is in Bangla, because digits and a short English sentence fit comfortably in one part. If your users prefer Bangla, test the length using the live counter on the compose screen first. See our guide to SMS character limits.

The SMS is only one part of a secure verification flow. On your side:

• Set a short expiry. Five to ten minutes is common. Reject codes after that.
• Never reuse codes. Generate a fresh random code for each attempt and invalidate it after one successful use.
• Rate-limit requests. Cap how many codes one number or IP can request per hour to block SMS pumping and abuse.
• Limit verification attempts. Lock the attempt after a few wrong guesses.
• Say "do not share" in the message. It reduces social-engineering attacks.
• Protect your API key. Keep it on your server only, and enable the IP allow-list on the key so it only works from your own servers.

More advice is in our article on OTP SMS best practices.

You can send OTP from your account's default non-masking sender right away. For higher trust, request a masking sender ID so codes arrive under your brand name; customers learn to recognise the genuine sender, which makes phishing harder.

To start:

1. Create an account at gotisms.com/register and top up your Taka wallet with bKash or another method.
2. Create an API key in the dashboard, optionally restricted to your server IPs.
3. Send a test OTP to your own number with the example above.
4. Check the delivery result, then wire it into your login or sign-up flow.

Need higher throughput than the default 300 requests per minute? Contact support to have it adjusted.