Dev Mode & Test Pairs

Dev mode lets you drive a complete verification flow — request, deliver, verify — without sending a single message to anyone. You get a temporary test pair: a synthetic phone number and a matching OTP. Send the OTP request to that number, type that code, and the transaction succeeds exactly as a real one would.

Nothing is sent, nothing is billed

A test-pair verification is synthesized server-side. No WhatsApp, SMS, Telegram or email message is dispatched, no charge is applied, and no delivery webhook fires. Run it as many times as you like — nothing is sent or billed. Your own callback and redirect still fire each time, and the redirect carries isTest=true, so make sure your handler checks it before granting a session or fulfilling an order.

Dev mode is a dashboard control, not an API

You enable dev mode and rotate its test pair from the Akedly dashboard. There is no public API-key endpoint for turning it on — this is deliberate, so a leaked production key can never enable a verification bypass.

How it works

Enable dev mode on the surface you're integrating against:

V1.2 REST API → enable it on the pipeline.
V2.0 Widget SDK → enable it on the widget.

Akedly then mints a test pair and holds it for a 60-minute window. While that window is open, any verification request whose phone number matches the test pair's number is treated as a test: the stored test OTP becomes the transaction's OTP, and the whole delivery path is skipped.

Any other phone number sent to the same pipeline or widget during that window behaves completely normally — real code, real delivery, real billing. Dev mode does not put your integration into a global test state; it only special-cases the one number. (One exception: V1.2's optional bypass toggles, which are pipeline-wide — see Proof-of-work and Turnstile below.)

The window expires — it does not renew

After 60 minutes the pair stops matching and requests to that number fall through to the normal path. Re-enable or rotate from the dashboard to get a fresh window. Rotating always mints a new phone number and a new OTP — the previous pair stops working immediately.

Choosing the OTP length

When you enable or rotate a test pair you can choose whether its OTP is 4, 5 or 6 digits. This is the length you will actually type, and it is the length the transaction is created with — so it is how you test a non-default digit length end to end.

Name
Length
Type
4 | 5 | 6
Description
The number of digits in the minted test OTP. Defaults to 6.
Name
Scope
Type
per rotation
Description
The length is a property of the pair you just minted, not a saved pipeline or widget setting. Rotate again at a different length and the new pair simply has a different length.

Because the length lives in the pair itself, the rule is simply: the test pair's OTP length is the length. There is no separate setting that could drift out of sync with the code you were given.

V2 widgets adapt automatically

For a V2 Widget attempt against a test pair, Akedly derives the attempt's digits from the stored pair, and the hosted widget renders that many input boxes. Rotate the pair to 4 digits and the widget shows a 4-box input on the next attempt — no configuration and no code change on your side.

The stored pair wins — but validation still runs first

On a test-pair request the OTP and its length always come from the stored pair: a valid digits value that differs from the pair's length is not applied, and any custom otp you pass is ignored. Request validation still runs first — on V2 an out-of-range digits or a mismatched otp is rejected with INVALID_OTP_DIGITS / OTP_DIGITS_MISMATCH before the test pair is even considered, while V1.2 keeps its lenient posture and falls back to the default. To test a different length, rotate the pair to that length.

What is skipped

A test transaction deliberately bypasses the machinery that would otherwise have real-world side effects:

Skipped	Why it matters
Message delivery	No WhatsApp, SMS, Telegram or email is sent — the successful delivery is synthesized for display.
Billing	The transaction carries no billing state, so repeated testing costs nothing.
Delivery webhooks	`metaWebhookForwardUrl` is not attached, so your endpoint is not called with test traffic.
Operational alerts	Test transactions do not raise the internal success/failure notifications real traffic does.
Rate limiting & circuit breaker	Both are skipped for the test number, and test traffic is excluded from the counters and buckets they measure — so a tight test loop neither consumes your budget nor trips the breaker for real users.

Your own callbacks still fire, and the redirect carries isTest=true so your application can tell a test verification from a real one.

Proof-of-work and Turnstile are handled differently

These two are not simply "off in dev mode", and they differ by surface:

V2.0 Widget SDK — proof-of-work is skipped for the test-pair attempt only; real traffic against the same widget keeps full protection. Turnstile is still required for test attempts, but the hosted widget completes it for you, so it costs you nothing.
V1.2 REST API — proof-of-work and Turnstile still apply to the test number. If your test client cannot solve them, the dev-mode panel offers two explicit opt-in toggles, Bypass PoW and Bypass Turnstile.

The V1.2 bypass toggles are pipeline-wide

Bypass PoW and Bypass Turnstile are not scoped to the test number. While the dev-mode window is live they disable that check for every request to the pipeline. They are off by default and become inert as soon as the window expires or dev mode is switched off — but never enable them on a pipeline that is serving production traffic.

Using it

Enable dev mode on the pipeline (V1.2) or widget (V2) in the dashboard, choosing an OTP length of 4, 5 or 6.
Copy the test pair — the dashboard shows the synthetic phone number and its OTP.
Start a verification for that phone number exactly as you would for a real user.
Submit the test OTP. The transaction verifies, your callbacks fire, and nothing is sent or billed.

Never ship a test pair

The test number and its code are development aids. Do not hard-code them into application logic, and do not leave dev mode enabled on a pipeline or widget serving production traffic — while the window is open, anyone who knows the pair can complete a verification for that number.