Use case · Verification

Send one-time passwords without the queue

Your login depends on a code landing before the session expires. Connect the accounts you already pay for and the platform paces each code to the number it leaves from — so a burst of logins drains at the speed your numbers allow instead of queueing behind one shared quota.

Make the code impossible to misread

Keep it short. A longer message is more segments, and in verification the cost is not the interesting problem — the length is, because people read codes under time pressure.

  • The code itself, in a form that cannot be misread
  • What the code is for, so a surprise code is recognizable as a mistake
  • How long it lasts
  • An instruction not to share it

Pace the burst to the number it leaves from

Because provider limits apply per sender number, a burst of logins can queue behind itself. Pacing is applied at the number, and a second number raises the ceiling rather than splitting the same allowance — which is why capacity planning for OTP starts with how many numbers you own, not with which plan you are on.

  • Per-number pacing rather than one shared application quota
  • Routing across connected accounts when one stops accepting traffic
  • Delivery receipt status recorded against the send

What to leave out

  • Do not put anything else in the same message — a code plus a promotion reads as spam
  • Do not depend on delivery as proof of the person; the code is the proof
  • Do not retry blindly — a retried request sends a second code, because the send API has no idempotency key

Questions this usually raises

Can a code be delivered twice by accident?
Yes, if the caller retries. There is no idempotency key on the send API, so duplicate prevention has to live in the service that calls it.
Will an opt-out stop verification codes?
No. Suppression is applied to promotional traffic; transactional sends such as a code are not suppressed by the same rule.
How fast can OTP traffic go?
As fast as the numbers you own allow. The provider’s limit is per number, and adding numbers is what raises throughput.

Keep reading

4 min

A timeout is not a failure

Sending is accepted asynchronously and there is no de-duplication key. Retrying a request you are unsure about sends a second message and bills for it.

Read the guide →
5 min

SMS segments and what you actually pay for

SMS is billed per segment, not per message. Whether your text fits in one segment depends on the character set it needs — and on the encoding you set on the connection.

Read the guide →
Use cases

Order confirmations

The confirmation is the message your customer keeps — forwarded, screenshotted, quoted back to support. Send it the moment the order lands, on a channel they actually read, and let the log answer for it later.

Open →
Use cases

Shipping and delivery updates

Dispatch notices, tracking updates and delivery windows go out when the state actually changes, not on a timer. On the SMS channel the platform spreads a dispatch batch to the limit your provider applies per number, so a whole route does not stall halfway through.

Open →
Use cases

Appointment reminders

A reminder earns its place by arriving early enough to change a plan and saying only what the person needs to act on: when, where, and how to change it. Send a confirmation at booking and a timed reminder before, on the number they booked with.

Open →
Use cases

Payment reminders

The reminder that arrives before a due date is a service; the one that arrives after is a complaint notification. Send both, keep them transactional, and pace the due-date batch so it drains in a time you can plan around.

Open →
Use cases

Two-factor authentication

A 2FA message is triggered by a login attempt, is time-critical, and — when it arrives unexpectedly — is the earliest signal your customer gets that someone else has their password. Send it fast, word it as a warning, and keep the record.

Open →
Use cases

Account security alerts

A security alert is not a notification — it is the account owner’s chance to interrupt something in progress. Speed and clarity are the whole job, and detail is a liability.

Open →
Use cases

Service and incident alerts

An incident alert arrives when something is already wrong — the worst possible moment to discover your send path is down too. Keep more than one connected account on that channel, and the notice about the outage is not its first casualty.

Open →
Use cases

Customer feedback requests

A feedback request is marketing in everything but name, so treat it like one: one question, sent once, to people who have not opted out. That is what keeps the answers worth reading.

Open →
Scope. Whaleal Platform sends over the CPaaS or BSP accounts you already hold. Your contracts, your rates and your sender identities stay yours, and nothing in the middle reprices them. Routing and pacing run on the SMS channel while logging covers every channel; consent and content stay with you.