> ## Documentation Index
> Fetch the complete documentation index at: https://docs.otp.id/llms.txt
> Use this file to discover all available pages before exploring further.

# OTP.ID: Multi-Channel OTP Delivery & Verification API

> Learn what OTP.ID is, how the API works, and what you can build with multi-channel OTP delivery over WhatsApp, SMS, Email, and more.

OTP.ID is a developer API that lets you send and verify one-time passwords through the channels your users already trust — WhatsApp, SMS, Email, Missed Call, and WhatsApp Inbound — with a single, consistent HTTP interface. Whether you're adding two-factor authentication to a web app, verifying phone numbers at signup, or securing sensitive transactions, OTP.ID handles the delivery infrastructure so you can focus on building.

## What is OTP.ID?

OTP.ID gives you programmatic control over the full OTP lifecycle: request delivery, track status, and verify the code your user enters — all through a REST API served from `https://api.otp.id`. Every request is authenticated with a Bearer API key tied to your merchant account, and billing is prepaid, meaning your balance is deducted only when a message is successfully sent.

### Supported Channels

OTP.ID delivers one-time passwords across five channels:

| Channel                 | Description                                                               |
| ----------------------- | ------------------------------------------------------------------------- |
| **WhatsApp** (outbound) | Sends an OTP message via WhatsApp to the user's number                    |
| **SMS**                 | Delivers the OTP as a standard text message                               |
| **Email**               | Sends the OTP to the user's email address                                 |
| **Missed Call**         | Triggers a missed call; the last digits of the calling number are the OTP |
| **WhatsApp Inbound**    | User sends a message to your WhatsApp number to trigger verification      |

## How the API Works

The OTP.ID API is organized around three core operations: **creating** an OTP, **verifying** it, and **polling** its status. All endpoints live under the `/v3/` path prefix and accept and return JSON.

### Creating an OTP

You have two ways to create an OTP depending on whether you want OTP.ID to generate the code or supply your own:

* **`POST /v3/request`** — OTP.ID generates a random code and delivers it to the user. This is the recommended approach for most use cases.
* **`POST /v3/send`** — You supply your own OTP code in the request body. Use this when you need to generate the code yourself (for example, to display it in your UI before delivery).

Both endpoints accept a `channel`, a `number` (or `email`), and a `brand` name that appears in the delivered message.

### Verifying an OTP

Once the user enters the code they received, call **`POST /v3/verify`** with the `otp_id` returned from the creation step and the code the user submitted. OTP.ID checks the code against what was sent and returns a `verified: true` or `verified: false` result. A mismatch returns HTTP `200` — it is a valid response, not an error.

### Polling Status

If you need to check the delivery state of an OTP without waiting for a webhook, call **`GET /v3/otp/{otp_id}`**. This is useful for polling patterns or for debugging delivery issues.

### Async Notifications via Webhook

OTP.ID can push real-time events to your backend. When a code is successfully verified, OTP.ID fires an **`otp.verified`** webhook event to the URL you configure in your dashboard. This removes the need to poll for verification results in server-to-server flows.

## The Response Envelope

Every response from the OTP.ID API — whether a success or an error — is wrapped in a consistent envelope:

```json theme={null}
{
  "success": true,
  "data": { ... },
  "error": null
}
```

On failure, `success` is `false`, `data` is `null`, and `error` contains a machine-readable `code` and a human-readable `message`:

```json theme={null}
{
  "success": false,
  "data": null,
  "error": {
    "code": "UNAUTHORIZED",
    "message": "Unknown API key"
  }
}
```

This consistent shape means you can always check `success` first and branch from there, without inspecting HTTP status codes for every edge case.

## Billing Model

OTP.ID uses a **prepaid balance model**. You top up your account balance in the dashboard, and each successful OTP delivery deducts the channel rate for that message. If a message fails to deliver, your balance is not charged. The `last_balance` field in every successful send response shows your remaining balance after the deduction, so you can monitor usage inline with your API calls.

## Where to Go Next

<CardGroup cols={2}>
  <Card title="Quickstart" icon="bolt" href="/quickstart">
    Send and verify your first OTP in under 5 minutes with step-by-step curl examples.
  </Card>

  <Card title="Authentication" icon="key" href="/authentication">
    Learn how to obtain your API key and authenticate every request.
  </Card>

  <Card title="Channels" icon="satellite-dish" href="/concepts/channels">
    Understand the five delivery channels and choose the right one for your use case.
  </Card>

  <Card title="API Reference" icon="code" href="/api-reference/request-otp">
    Explore the full endpoint reference with request schemas and response examples.
  </Card>
</CardGroup>