> ## 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.

# How to Integrate Missed Call OTP

> Use OTP.ID Missed Call verification when the caller ID carries the OTP and the user enters the trailing digits from the missed-call number.

Use this guide when you want OTP.ID to verify a user with a Missed Call flow. You send `channel: "misscall"` to [`POST /v3/request`](/api-reference/request-otp) or [`POST /v3/send`](/api-reference/send-otp), OTP.ID places a call, and the caller ID carries the OTP. There is no SMS and no message body for this channel.

Your UI must use `verification.prefix` and `verification.otp_length` from the direct request or send response to guide the user. The full calling number is not returned by V3, so your form should show the prefix as read-only context and collect only the trailing digits that the user sees in the call log.

## How the flow works

<Steps>
  <Step title="Create or send the Missed Call transaction">
    Call [`POST /v3/request`](/api-reference/request-otp) when you want OTP.ID to generate the transaction, or call [`POST /v3/send`](/api-reference/send-otp) with `channel: "misscall"` when your application starts the same channel flow from the client-supplied endpoint.
  </Step>

  <Step title="OTP.ID places and disconnects the call">
    OTP.ID triggers the Missed Call and disconnects it so the user can inspect the caller ID in their phone call log.
  </Step>

  <Step title="The user checks the call log">
    Instruct the user to open the phone call log and find the OTP.ID number that just called. There is no SMS fallback and no message content to read.
  </Step>

  <Step title="Show the prefix and trailing slots">
    Render `verification.prefix` and display `verification.otp_length` empty input slots after it. This UI tells the user how many trailing digits they must enter.
  </Step>

  <Step title="Collect the trailing digits">
    The user reads the end of the caller ID from the call log and enters only those trailing digits into your form.
  </Step>

  <Step title="Verify the collected digits">
    Submit the collected digits to [`POST /v3/verify`](/guides/verify-otp) as `otp` together with the transaction ID.
  </Step>
</Steps>

## Response mapping for Missed Call

The Missed Call response gives you only the verification hint your UI needs:

```json theme={null}
{
  "verification": {
    "prefix": "628559263",
    "otp_length": 4
  }
}
```

* The telephony vendor determines the code from the caller ID.
* When `otp_length` is `4`, the user enters the last four digits of the number that called them.
* `otp_length` and a supplied `otp` do not change the vendor-derived caller-ID code for this channel.
* Use the response prefix only to orient the user in your UI; do not treat it as a way to reconstruct or expose the full number.
* Request, send, replay, and status details remain defined by the canonical [POST /v3/request reference](/api-reference/request-otp) and [POST /v3/send reference](/api-reference/send-otp).

## UI reference

```text theme={null}
Missed call verification
We called your phone. Open your call log and find the OTP.ID number.

628559263 - [  ] [  ] [  ] [  ]
Enter the last 4 digits of the number that called you.

[ Verify ]                 Try again
```

| Element        | Required behavior                                                                           |
| -------------- | ------------------------------------------------------------------------------------------- |
| Status message | Tell the user that OTP.ID called and they should check the call log.                        |
| Prefix         | Render `verification.prefix` as read-only context.                                          |
| Digit inputs   | Render one input per `otp_length`; auto-advance, backspace navigation, and paste must work. |
| Accessibility  | Label the group as the trailing digits from the missed-call number.                         |
| Verify action  | Submit only the collected digits to `POST /v3/verify`.                                      |
| Retry action   | Start a new request or transaction; do not silently reuse a stale code.                     |
| Error states   | Explain invalid, expired, and maximum-attempt responses.                                    |
| Success state  | Confirm verification and continue the Client flow.                                          |

<Note>
  Do not ask the user to wait for an SMS or search for a message body. Missed Call verification comes from the caller ID only.
</Note>

## Request and verify examples

Use the canonical endpoint pages for shared fields and response schemas:

* [POST /v3/request reference](/api-reference/request-otp)
* [POST /v3/send reference](/api-reference/send-otp)
* [Verify OTP guide](/guides/verify-otp)

### Example: create a Missed Call transaction

```bash theme={null}
curl -X POST https://api.otp.id/v3/request \
  -H "Authorization: Bearer <api_key>" \
  -H "Content-Type: application/json" \
  -d '{
    "channel": "misscall",
    "number": "6281234567890",
    "brand": "TokoKita",
    "ttl": 300
  }'
```

You can omit `otp_length` for Missed Call requests. OTP.ID accepts the field for compatibility, but the telephony vendor still determines the caller-ID digits, so the value has no effect for this channel.

### Example: verify the collected trailing digits

If the user sees a number that ends with `4829`, submit only `4829` as the `otp` value.

```bash theme={null}
curl -X POST https://api.otp.id/v3/verify \
  -H "Authorization: Bearer <api_key>" \
  -H "Content-Type: application/json" \
  -d '{
    "otp_id": "OTP20260808ABCD000001",
    "otp": "4829"
  }'
```

## Delivery, retry, and verification guidance

* Failed delivery: if the Missed Call never appears in the user's log, ask them to confirm signal coverage and request a new transaction instead of reusing the current one.
* Expiry: if verification returns an expired response, start a new Missed Call flow and show that the previous caller ID can no longer be used.
* Retry: when the user taps `Try again`, create a fresh request so the next call is tied to a new active transaction.
* Verification limits: if the user reaches the maximum attempt response, stop the current flow and require a new request before they can verify again.
* Invalid code: if the trailing digits do not match, tell the user to re-check the last digits from the call log and submit again while attempts remain.

## Related pages

* [POST /v3/request reference](/api-reference/request-otp)
* [POST /v3/send reference](/api-reference/send-otp)
* [Verify a One-Time Password](/guides/verify-otp)