Skip to main content

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

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