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

# Troubleshooting: RCS tester invite 425 PENDING_ACCEPTANCE and 422 INVITE_DECLINED

> Your RCS test-account verify-otp poll returns 425 PENDING_ACCEPTANCE while the tester invite waits on the handset and 422 INVITE_DECLINED when it was declined or expired. Decode each state, accept the invite in Google Messages, respect the rate caps, and read the demo quota before re-verifying.

# Troubleshooting: RCS tester invite 425 PENDING\_ACCEPTANCE and 422 INVITE\_DECLINED

Your poll of `POST /api/v1/rcs/test-account/verify-otp` is returning
`425 PENDING_ACCEPTANCE` or `422 INVITE_DECLINED`, and it reads like a
failure. It is not: both are states of the tester-invite flow, and the
difference between "waiting", "declined", and "actually broken" is the whole
of this page.

## The three-step flow and what each state means

1. **Send the invite.** `POST /api/v1/rcs/test-account/send-otp` with
   `{ "phone": "+14155552671" }` checks the handset's RCS capability,
   registers it as a tester device on Devotel's shared bot, and delivers the
   tester invite. It returns `verification_id`, `expires_in: 600`, and
   `verification_mode: "tester_invite_acceptance"` — there is no numeric code
   to type; the tap on the handset is the verification.
2. **Poll until accepted.** `POST /api/v1/rcs/test-account/verify-otp` with
   `{ "verification_id" }`. While the invite sits untapped on the handset,
   every poll answers `425 PENDING_ACCEPTANCE`. **That is the waiting state,
   not an error — keep polling.** The dashboard polls every \~4 seconds for up
   to 10 minutes, and your integration should do the same. Once the recipient
   accepts, the same call returns `{ "verified": true, "phone" }`.
3. **Read the boundary.** `GET /api/v1/rcs/test-account/status` shows
   `verified`, `verified_phone`, `daily_remaining`, `lifetime_remaining`, and
   `suspended` — check it before concluding anything is broken.

| Response on verify-otp | Meaning | Do |
| - | - | - |
| `425 PENDING_ACCEPTANCE` | Invite delivered, not yet tapped on the handset | Keep polling; on the handset, tap **Make me tester** |
| `422 INVITE_DECLINED` | The recipient declined the invite on the handset | Restart at `send-otp` |
| `422` "Invalid verification session" | Unknown `verification_id`, or one already consumed | Restart at `send-otp` |
| `422` "Verification window expired" | More than 10 minutes since `send-otp` | Restart at `send-otp` |
| `429 RATE_LIMITED` | A rate cap fired; `retry_after` carries the wait in seconds | Wait `retry_after` out, then resume polling |
| `503` | Transient upstream blip | Retry in a moment; the next poll simply re-checks |

There is no server-side acceptance ETA: acceptance happens when the person
holding the handset taps, and nothing you send accelerates it. If the
10-minute window expires first, the session is gone — start over from
`send-otp`.

## The handset side of the Dotgo RBM tester invite

The invite lands as an RCS message from the shared bot ("Orbit by Devotel
agent has invited you to be a tester") with native **Make me tester** /
**Decline** buttons, in Google Messages on an Android handset with RCS chat
features turned on. Until the tap happens the device is registered but
unverified, and every verify-otp poll 425s.

`send-otp` registers the number as a tester device before it invites, so a
handset that cannot participate in RCS is rejected at that first step: an
iPhone, an Android without Google Messages / Chat features, or a number the
RBM directory has no reachable entry for returns `422 RCS_NOT_SUPPORTED`
("Use an Android phone with Google Messages and RCS chat features turned
on"). That refusal is definitive for the handset — switch to an RCS-capable
Android device rather than retrying the same number. A `503` from `send-otp`,
by contrast, is a transient upstream blip — a retry after a moment is safe.

## Rate limits

| Call | Cap (per organization) | When the 429 clears |
| - | - | - |
| `POST /api/v1/rcs/test-account/send-otp` | 5 per hour; a rapid burst can also trip a shorter 3-per-10-minutes window | Wait the stated `retry_after` |
| `POST /api/v1/rcs/test-account/change-number` | 5 per hour | Wait the stated `retry_after` |
| `POST /api/v1/rcs/test-account/verify-otp` | 30 per minute | Under a minute — the window is per-minute |

Every `429 RATE_LIMITED` body carries `retry_after` in seconds: the time left
in the window, not a suggestion. Honor it instead of retrying — an immediate
repeat fails identically and keeps you inside the window. A 429 mid-poll on
verify-otp is harmless to the flow: because the window is per-minute, it
clears in under a minute and the next tick resumes where it left off.

## The demo boundary counters

The test account is a demo surface with two counters, both per organization:

* **20 demo sends per day** — resets when the UTC date rolls over.
* **200 demo sends per account lifetime.**

Both counters **deliberately survive**
`POST /api/v1/rcs/test-account/change-number`: re-verifying a new handset
does not reset either one, because the boundary caps demo usage, not
handsets. So if `daily_remaining` or `lifetime_remaining` on
`GET /api/v1/rcs/test-account/status` reads 0, re-running send-otp /
verify-otp or changing the number will not "fix" the quota — wait for the
daily reset, or move to your own approved brand and launched bot
([RCS onboarding guide](https://docs.orbit.devotel.io/guides/rcs-onboarding.md)). A send past either counter
returns `429 RATE_LIMIT_EXCEEDED` naming the limit it hit.

## What not to do

* **Do not treat `425 PENDING_ACCEPTANCE` as a fault** or stop polling on it —
  it is the flow working as designed; alerting on it pages you for a waiting
  human.
* **Do not re-fire `send-otp` to speed acceptance up.** Acceptance happens on
  the handset; a resend only spends one of your hourly sends and re-notifies
  the recipient.
* **Do not retry `422 INVITE_DECLINED` or an expired session with the same
  `verification_id`.** A declined or expired session can never flip to
  accepted — restart from `send-otp`.
* **Do not re-verify to restore quota.** The counters survive
  `change-number` by design.

## When to escalate

Escalate to [support@devotel.io](mailto:support@devotel.io) when a `503`
persists across retries, when the invite never arrives on a handset that is
verifiably RCS-capable, or when verify-otp 425s for the full 10-minute window
although the recipient did tap **Make me tester**. Include:

1. The **`verification_id`** returned by `send-otp`.
2. Your **organization id** (dashboard → Settings → Organization, or
   `organizationId` on `GET /api/v1/me`).
3. The verbatim `code` and `message` from the failing response, plus the
   handset model and messaging app on the receiving side.

## See also

* [RCS channel guide — test account](https://docs.orbit.devotel.io/channels/rcs.md#test-account) — the flow
  and its quotas as reference
* [RCS channel guide — tester devices](https://docs.orbit.devotel.io/channels/rcs.md#tester-devices) —
  per-bot tester registration once you have your own bot
* [RCS onboarding guide](https://docs.orbit.devotel.io/guides/rcs-onboarding.md) — the path from the demo to
  your own approved brand and launched bot
* [RCS questions, answered](https://docs.orbit.devotel.io/reference/faq.md#rcs) — the FAQ's RCS section


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.