Skip to content
Nishchit
USE CASE / OTP

The message that
cannot be late.

A one-time passcode is the highest-stakes message most products send. Late and the user retries; wrong and the user is locked out. Nishchit sends it over one REST call, in one segment, in either language.

SEND A PASSCODEPOST /v1/messages
curl https://api.nishchit.tech/v1/messages \
  -X POST \
  -H "Authorization: Bearer $NISHCHIT_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: signup-otp-user-9281" \
  -d '{
    "to": "+8801712345678",
    "body": "Your Nishchit OTP is 482913",
    "reference": "user_9281"
  }'
WHAT A PASSCODE FLOW NEEDS

Four requirements,
and none of them is speed.

Speed is the one everybody optimises and the one nobody controls — it belongs to the network. These are the four you can actually decide.

It has to be one segment

A passcode that costs three credits is a passcode written badly. Both an English and a Bangla passcode fit in one segment if you keep the body to the code and the brand — the comparison below is measured, not asserted.

How segments are counted →

It has to be exercised before launch

Passcode flows fail in the branches nobody tests: the gateway outage, the terminal failure, the rate limit. Test mode has magic recipient numbers that produce each of those deterministically, without reaching a carrier or spending a credit.

Magic numbers →

It has to survive a retry

A user double-tapping Resend, a queue redelivering, a load balancer retrying — each can send a second passcode at a second charge. An idempotency key keyed to the attempt makes the duplicate a no-op that returns the original response.

Idempotency semantics →

It has to be rate limited by someone

Passcode endpoints are the most abused surface in any product. New projects start on a low-volume trust tier with a daily ceiling independent of the credit balance, so a leaked key cannot drain an account overnight.

Trust tiers and ceilings →
BOTH LANGUAGES, ONE CREDIT

A passcode is short
enough to stay cheap.

Bangla costs roughly three times what English costs per unit of message — but a passcode is short enough that the difference never appears. Both of these are one segment.

ENGLISH OTPGSM-7

Your Nishchit OTP is 482913

CHARACTERS
27
PER SEGMENT
160
SEGMENTS
1
CREDITS
1
COST৳ 0.35
BANGLA OTPUCS-2

আপনার নিশ্চিত ওটিপি ৪৮২৯১৩

CHARACTERS
26
PER SEGMENT
70
SEGMENTS
1
CREDITS
1
COST৳ 0.35

What pushes a passcode over one segment is everything you add around the code: a long expiry sentence, a support number, a link, or a typographic apostrophe pasted from a word processor — that last one alone switches an English body to UCS-2 and cuts its capacity from 160 characters to 70. Measure your own body

THE HARD PART

Designing a passcode flow
you cannot observe.

The primary Bangladesh route returns no delivery receipts. Most providers do not mention this. It changes how a passcode screen should be built, so here is how.

You will never receive a signal saying the passcode arrived, so a screen that waits for one waits forever. Build for the absence instead:

  • Treat status: "sent" as the success condition for your UI. It means the carrier accepted the handoff, which is the last thing anyone can actually observe.
  • Show a resend countdown from the moment you send, not from a delivery event that will not come. Thirty to sixty seconds is enough to stop double-sends without stranding a user on a slow network.
  • Never render delivery_status: unknown as a failure. It is the normal terminal state for most Bangladeshi traffic, and a red cross against it will generate support tickets for messages that arrived fine.
  • Key the resend to the same idempotency key as the first attempt if it is genuinely the same attempt, and to a new one if the user is asking for a fresh code. The difference is whether you want a duplicate suppressed or a second message sent.
How delivery status works →The OTP reference →
OTP / QUESTIONS

Passcode questions,
answered plainly.

Is there a separate OTP endpoint or a verify API?
No. A passcode is a message, sent through POST /v1/messages like any other. You generate and verify the code yourself, which means you own the expiry window, the attempt limit and the storage — and you are not locked into somebody else’s verification flow. The OTP reference
Can I confirm the passcode was delivered?
Not on the primary Bangladesh route, which returns no delivery receipts. Those messages end at sent with delivery_status: unknown, permanently. Design the flow around a resend timer rather than a delivery signal — the section above covers what that looks like. Delivery status in full
Does a Bangla passcode cost more than an English one?
Not if it is short. Bangla encodes as UCS-2 at 70 characters per segment instead of 160, but a passcode body is far under both limits, so both are one segment and one credit. Bangla only becomes expensive once the body grows — an expiry sentence and a support number will push it over 70.
Will Nishchit rewrite my passcode body?
Never. If the body is classified as a passcode but does not match the shape carriers handle best, the response carries a non-blocking warning and the message goes out exactly as submitted. A message that arrives differently from how it was sent is worse than one that does not arrive.
Do I need a registered sender ID to send passcodes?
No. You send on a Nishchit-managed sender from signup, with no registration and no waiting. Alphanumeric sender IDs on the major Bangladeshi networks require operator pre-registration that takes weeks, which is a real constraint and one you can skip entirely in V1.
NISHCHIT / SMS INFRASTRUCTURE

Your product has something to say.

Give it a reliable way to say it.

Start buildingRead the docs
NO KYC

Self-serve signup, live immediately. Content checked instead of paperwork.

PAY PER SEGMENT

One credit per segment at ৳0.35. No contract, no minimum.

TEST FIRST

An nk_test_ key never reaches a carrier or spends a credit.

BANGLADESH ONLY

One country, done properly — Bangla pricing, observable delivery.