Can this local OTP branch send a real message?

The problem and the decision

A small B2B team adds a phone field to signup and wants to confirm the person can receive a code. The downloadable four-branch example in the verification_delivery directory includes an otp branch, so it looks like OTP is covered. It is not. The guide states that OTP delivery is unsupported here, and the current free live phone route also does not request line type, ownership, reachability or OTP delivery. Your decision is therefore not whether to trust the fixture to send codes, but which component in your own system owns OTP delivery, and how your code behaves when the phone step answers with unsupported.

What the otp branch actually returns

Running the phone task with the otp branch prints this tested output: mode is synthetic_fixture, branch is otp, otp_sent is false, live_line_type_available is false, state is unsupported, valid is null, line_type is null, and next is customer_otp_provider. Every field matters. otp_sent false is the direct answer to this article's question: nothing was sent. state unsupported means the fixture declines the task rather than simulating success. valid and line_type are null, so there is no number assessment to lean on either. next is a label for your code to route on, not an action the fixture performed. The same otp_sent false and live_line_type_available false appear on every branch, including normal, which returns a simulated mobile line_type only inside the fixture.

A worked hypothetical scenario

Hypothetically, imagine a team whose signup handler calls the phone step, then shows a "enter the code we sent" screen. In their test run, the step returns state unsupported and next customer_otp_provider. A proposed application design: the handler checks otp_sent before showing any code screen; because it is false, it does not render that screen. It routes on next instead, handing the number to the team's own OTP provider integration, which they must separately configure and be authorized to use. If no such provider exists yet, the handler marks the signup as awaiting a channel check and leaves account creation to the team's existing policy. This is design you would write; the fixture only supplies the returned fields.

Failure handling your code owns

Treat each branch differently. normal returns state simulated, valid true, line_type mobile and next continue_customer_policy: continue with your own rules, never infer ownership or reachability. unknown returns state unknown with null valid and line_type and next review_or_existing_otp: route to review or to an OTP flow you already operate. provider_failure also returns state unknown but next bounded_retry_then_review: retry a limited number of times, then review, rather than rejecting. otp returns unsupported: do not wait for a code. An unrecognized branch raises UNSUPPORTED_FIXTURE; surface that as a configuration error, not a user failure. Never let a null field default to true.

What is implemented versus proposed

Implemented in the fixture: a dependency-free Python function returning the four branch results above with no network calls or credentials, plus tests. Not implemented: sending SMS or any other message, provider adapters, live line type, and ownership checks. The account-free HTTP trial is a separate thing from this four-branch download and should not be described as it. Synthetic results are not production approval, and the live free phone route available to eligible businesses still does not deliver OTP. Retry limits, review queues and OTP provider selection are your application's responsibility.

Acceptance checklist

Before shipping: run the phone task with the otp branch and confirm otp_sent false, state unsupported and next customer_otp_provider. Confirm no code entry screen appears when otp_sent is false. Confirm your handler routes on next for all four branches and logs UNSUPPORTED_FIXTURE separately. Confirm null valid and line_type never become a pass. Confirm provider_failure retries are bounded. Confirm OTP delivery is wired to a provider you are separately authorized to use, and that tests against the fixture are never presented as evidence that live messages are sent. Then decide whether a saved sandbox request fits your task.

Run the checked synthetic example

Download and extract https://gridzen.ai/downloads/verification-delivery.zip, enter verification_delivery, then run with Python 3.10+. This local example makes no network calls. Use a fresh database for an independent identity run.

python3 delivery.py phone --branch unknown
python3 delivery.py phone --branch provider_failure

Sources and scope

https://gridzen.ai/guides/phone-otp-identity/ https://gridzen.ai/guides/current-capabilities/ Based on the checked source snapshot and local fixture; proposed application rules are design advice, not proven production behavior. Written with AI assistance and reviewed independently.