verify-verifications

Create the next verification channel attempt

Advances an in-progress verification to the next channel in its plan and sends a fresh passcode there. Identify the verification by the same to recipient used to create it; no verification ID is required.

The send bypasses the resend cooldown and does not draw on the recipient's hourly send cap; what bounds it is the channel plan, since each call advances by at most one channel. Passcodes sent earlier remain valid. The response sets last_channel to the most recent completed send. Concurrent requests each advance the plan by at most one channel and return committed state.

A recipient with no in-progress verification returns 404 E13000, whether none was ever created or the most recent one is already resolved. A recipient who has already verified is in that set, so a 404 here is not evidence they still need verifying, and creating another verification would send a passcode they no longer need. A plan with no further channel returns 422 NoNextChannel; create the verification again to resend on the current channel. If every remaining channel fails, the operation returns 422 NoAvailableChannel. Requests that exceed the send rate limit return 429.

post/v1/verify/verifications/next-channel

Request

  • Base URL: https://us1.platform.bird.com
  • URL: https://us1.platform.bird.com/v1/verify/verifications/next-channel
  • Auth: one of:
    • HTTP bearer
    • API key in cookie bird_session

Headers

Idempotency-Keystring

Client-supplied key. On operations supporting request deduplication, a retained response is replayed for duplicate requests with the same key within the idempotency window (3 hours by default). This protection requires a workspace, organization, or staff-account scope. User-only and unscoped unauthenticated operations, streams, and operations with a separate replay contract do not use this response replay.

On a supported operation, if idempotency protection is unavailable before execution, the API returns 503 IdempotencyUnavailable (E01033) without executing this attempt. Retry with backoff using the same key and request. An operation that takes effect before its response is retained can still execute again on retry.

Two distinct 409 errors signal misuse:

  • request_in_progress (E01004): The same key is currently being processed by a concurrent request. Wait briefly and retry. The lock expires within 30 seconds.
  • idempotency_key_reuse (E01005): The same key has already completed against a different request body or method. Generate a new key.

Recommended key format is <event-type>/<entity-id> (for example welcome-user/usr_abc123).

X-Workspace-Idstring

Workspace context for the request. Required for dashboard authentication and master keys. Workspace keys and access tokens already identify their workspace; send that workspace or omit the header. A different one is rejected.

X-Organization-Idstring

Organization context for the request. Required for dashboard authentication. An API key or access token carries its own organization, so send either that organization or no header at all; a different one is rejected.

Request body

Example request

{
  "to": {
    "phone_number": "+15551234567"
  }
}

Response

Verification state after the advance. last_channel identifies the most recent completed send.

idstring required
status'pending' | 'verified' | 'failed' | 'expired' | 'canceled' | 'blocked' required

The verification's current state:

  • pending: Awaiting a correct passcode.
  • verified: A correct passcode was submitted.
  • failed: The verification cannot be completed. Either too many incorrect passcodes were submitted, or no planned channel could deliver one. Read reason to tell those apart.
  • expired: The validity window elapsed before a correct passcode.
  • canceled: The verification was canceled before completion.
  • blocked: A fraud or abuse control stopped the verification.
reasonstring

Why a verification session reached its final state without succeeding: attempts_exhausted (too many incorrect passcodes), ttl_elapsed (the time window elapsed before a correct passcode), or undeliverable (no planned channel could deliver a passcode, so the recipient never had one to submit). Open enum: new reasons may be added over time, so treat any unrecognized value as a future reason rather than an error.

last_channelstring nullable

The channel the most recent passcode was sent on, or null before the first send. Open enum; new channels may be added over time, so treat any unrecognized value as a future channel rather than an error.

metadataobject

The key/value pairs attached when the verification was created.

expires_atstring date-time required

When the verification expires if no correct passcode is submitted first. After this time its status reports expired.

verified_atstring date-time nullable

When the verification was completed, or null if it is not yet verified.

created_atstring date-time required
updated_atstring date-time required

Example response

{
  "id": "vrf_01krdgeqcxet5s7t44vh8rt9mg",
  "status": "pending",
  "reason": null,
  "to": {
    "email": "user@example.com"
  },
  "channels": [
    {
      "channel": "email"
    }
  ],
  "last_channel": "email",
  "expires_at": "2026-05-20T09:24:52Z",
  "created_at": "2026-05-20T09:14:52Z",
  "updated_at": "2026-05-20T09:14:52Z"
}

Changes

No recorded changes to this operation across all 2 revisions of this API.