Three REST requests register a number you own elsewhere as a verified caller ID. You submit the code you heard, and redial the verification call if you missed it.
identity
The claim
You send three requests. POST /api/relay/rest/verified_caller_ids carries the number and a display name; the vendored REST spec titles it “Create verified caller ID”. PUT /api/relay/rest/verified_caller_ids/{id}/verification carries verification_code, titled “Validate verification code”. POST to that same path is “Redial verification call”. The SDK wraps the three as create, submit_verification and redial_verification on client.verified_callers.
Why it holds
The verifier checks the three requests against that spec. It marks number as the one required field on create and verification_code as required on the PUT. The spec’s response schema carries id, number, name, verified, verified_at and status.
POST /api/relay/rest/verified_caller_ids
{"number": "+15557654321", "name": "Shop mobile"}
PUT /api/relay/rest/verified_caller_ids/<id>/verification
{"verification_code": "482913"}
POST /api/relay/rest/verified_caller_ids/<id>/verification
The id in the second and third paths is the id the first response returned, per the spec’s response schema. verified and status in that schema are how you read the outcome.
Limitations
The verifier proves the three requests. Whether the phone rings, what the code is, and when verified flips are the platform’s side of a live run.
What to change first
Remove name=name from start and run the verifier. The exact-body assertion fails, though the spec would still accept the request: name is optional and number is the only required field.