Reverify a messaging brand

Recheck corrected business identity

Use this operation when an existing organization brand needs its corrected identity information checked again. First update the existing brand, then read its current identity status. An ordinary profile update does not submit this separate paid attempt. Reverification does not create another brand or register a campaign.

Use your own enabled API account over HTTPS from an allowed source IP. The brand must belong to that account. Keep brand records private: they contain business and contact information.

Review the brand before submitting

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID" \
  --output current-brand.json

Check that the returned brand is the intended business and that the correction is present. A pending original registration cannot be reverified yet. The registry can reject a request when the business information is unchanged. Missing special attributes may require an appeal rather than another identity check. Sole-proprietor brands use the appropriate identity/PIN workflow; do not treat this endpoint as a substitute.

Confirm the separate charge

The currently configured production reverification fee is US$5.00 per accepted attempt, checked October 24, 2026. It uses the standard brand fee, including when the original entity has a different registration price. Purchases must be enabled; prepaid accounts need sufficient balance before submission.

A 202 response means the request was accepted for further processing, and the fee is dispatched at acceptance. It does not mean the business is verified. A later new attempt can incur another fee. Do not create a new attempt merely because verification remains pending.

Submit one intended attempt

curl --silent --show-error --fail-with-body --user "$API_USER:$API_PASSWORD" \
  --request PUT \
  --header "Idempotency-Key: $IDEMPOTENCY_KEY" \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID/revet"

No profile body is required: this checks the brand details already stored. Use a unique idempotency key for the intended attempt, and keep the exact method, path, query and body unchanged for retries. Keys support 1–128 printable ASCII characters without spaces. An in-progress duplicate can return 409 with Retry-After; a completed attempt can replay its saved result, including an error.

The public API also accepts Bearer authentication for an enabled token account. Account ownership and permitted source IP checks still apply. Stored mock brands skip this production fee path, but a sandbox result is not production identity verification.

Read the result and follow its status

The proxy refreshes its local brand record after an accepted mutation; that refresh does not itself prove a final verification outcome. A business can remain unverified or pending. Use the current brand status rather than HTTP acceptance alone before continuing campaign setup.

Recover an uncertain result

A transport failure can produce a cached 502. A request accepted upstream followed by local persistence or billing failure can produce a cached 500 with requestId. Preserve that identifier and reconcile the current brand and billing state with support. Generating another key can create a separately billable attempt; do not retry under a new key blindly.

Using the customer portal

The portal offers reverification for an UNVERIFIED production organization after reviewing the current profile and charge. It checks that the profile and price have not changed and rejects another accepted submission for the same current details. Sandbox and sole-proprietor brands are excluded from this portal action.

Those portal safeguards are additional workflow checks. Direct API clients must perform their own review and must not assume the API requires the portal’s version or price-confirmation fields. Saving an ordinary brand correction is a separate action and does not automatically submit reverification.