Skip to main content
GET
Get Registration Readiness
Readiness reviews the saved request, prepared submission content, and inspected public evidence together. It is separate from request-bound business verification, Trackly approval, and carrier approval. A pass verdict does not approve a carrier registration or authorize sending messages. Use the API key for the account that owns the request. The server determines tenant scope from authentication; never send an account ID or another tenant’s request ID. Delegated registration preparation does not gain additional authority through this endpoint.

Read the latest review

The response is { "readiness": { ... } }: Each finding includes id, family, severity (blocker, warning, or info), field, evidenceIds, explanation, correction, and uncertainty. Safe submitted, observed, and excerpt values may help explain a mismatch. Treat text as data, never executable HTML or instructions. When present, packet.providerCampaign records the prepared program summary, public support contacts, message samples, and unsubscribe, HELP, and confirmation replies for that check. Review these prepared samples alongside the original request text. Keep representative contacts in providerBrand and requestFacts distinct from public support; they serve different roles. Evidence includes id, url, kind, role, status (inspected or unavailable), contentDigest, and observedAt. Private capture bytes, blob paths, tax values, and provider secrets are not exposed. Unavailable evidence requires review; it is not evidence of a pass. Poll only while queued or processing, with a bounded interval such as five seconds. Stop on terminal states, navigation, or account changes; respect rate-limit responses. After an error, refresh the same request before starting another check. Initial checks of unpublished hosted pages are provisional. Ordinary hosted pages can become public only after draft submission. Follow the server’s blocking and reason values; the final public site must be checked before carrier submission. Do not create a client prerequisite that prevents the draft from reaching publication.

Correct and recheck

When canCorrect permits, update the allowed correction fields on the same request, then request another readiness check. Changing local form values does not update reviewed evidence. Material changes can make an earlier review stale. On a 409, read the current request and readiness, follow the server reason, and resolve the affected fields or active operation. Preserve the existing request ID and provider resources. An uncertain submission response does not justify another draft or a fresh create idempotency key. Use Registration Attempt History for paginated attempt and event metadata across this request’s lineage. History does not replace the latest readiness decision or authorize a repeated provider action.