Register a messaging brand

Register the business behind your messages

A messaging brand identifies the business sending US 10DLC messages. Register the brand before choosing a campaign use case. Use the business’s legal details and a contact who can complete any required validation. A returned brand ID is not, by itself, approval to send messages.

Use this current account-owned route over HTTPS with an enabled API account and its permitted source IP address. Do not submit user_id, username or another customer’s owner identifier. MultiTEL records ownership from the authenticated account.

Start with an explicit sandbox request

The portal defaults its form to sandbox mode; a direct API request must explicitly include the JSON boolean mock: true when you intend a mock brand. Omitting that flag is not a sandbox guarantee and can create a billable production registration. The portal’s mode field is not a substitute for the API’s mock field.

Prepare a local brand.json file using the fields below. Replace the placeholders with appropriate test details and current catalogue codes. This example is a private-profit business; other entity types have different requirements.

{
  "entityType": "PRIVATE_PROFIT",
  "displayName": "Example business",
  "companyName": "Example legal business name",
  "ein": "YOUR_TAX_ID",
  "einIssuingCountry": "US",
  "phone": "+12025550123",
  "street": "123 Example Street",
  "city": "Example City",
  "state": "NY",
  "postalCode": "10001",
  "country": "US",
  "email": "contact@example.invalid",
  "brandRelationship": "BASIC_ACCOUNT",
  "vertical": "CURRENT_VERTICAL_CODE",
  "referenceId": "your-business-reference",
  "mock": true
}

The business, address, phone and identifier above are placeholders, not a registration-ready business identity. Get current values for entityType, vertical, country, state, brandRelationship and other enumerations from the messaging catalogues.

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  --header 'Content-Type: application/json' \
  --header "Idempotency-Key: $IDEMPOTENCY_KEY" \
  --data-binary @brand.json \
  'https://api.multitel.net/tcr/v2/brand/nonBlocking'

Business and contact fields

Brand registration fields
Fields	What to provide
entityType, displayName	Current entity-type code and the recognizable brand name. Maximum lengths are 20 and 255 characters respectively.
country, street, city, state, postalCode	The actual business address. Use the two-letter country code and a current US state code when applicable. Limits: street 255, city 100, state 20 and postalCode 10 characters.
email, phone	A working contact email, up to 100 characters, and a phone number in international +country-code format, up to 20 characters. Keep business details consistent across the registration.
companyName, ein, einIssuingCountry	For organizations, provide the legal company name and business tax identifier. The identifier’s issuing country is a separate two-letter field. Limits: companyName 255 and ein 21 characters. A sole proprietor uses personal-name fields instead of an organization’s tax identity.
brandRelationship, vertical	The relationship to the business and its industry, using current catalogue codes. Organizations require these; the sole-proprietor rules differ. Do not substitute translated display labels for API codes.
firstName, lastName, mobilePhone	Required for a sole proprietor. Name fields allow up to 100 characters each. Supply an eligible mobile number for the required OTP validation, in international format.
stockSymbol, stockExchange, website, businessContactEmail	A public company also needs its stock symbol/exchange, website and an eligible business-contact email for the additional validation process. Limits: stockSymbol 10, website 255 and businessContactEmail 255 characters.
altBusinessIdType, altBusinessId	Optional alternative business identifier. Supply its type and value together. Use the current type catalogue; the value allows up to 50 characters.
referenceId	Your business reference, up to 50 characters. Include it for sole-proprietor registration under the current entity-specific requirements. It is business metadata, not the request’s idempotency key.
website, ipAddress, tag	Additional website, originating-IP metadata and tag values when applicable. These do not establish account ownership or replace identity checks.
mock	A JSON boolean. Use true only for the intended mock workflow; use false for an explicitly reviewed production registration. Do not send the string "false" as a substitute for a JSON boolean.

Sole proprietors are supported for US or Canadian registrations and need OTP verification before campaign eligibility. Public companies can require a business-contact validation step. GOVERNMENT is for US-based government entities; confirm the correct entity category for other organizations. Follow the entity-specific requirements as well as the returned validation errors.

Keep a stable idempotency key

Generate one Idempotency-Key for this intended registration. It must contain 1–128 printable ASCII characters without spaces. Reuse the same key only with the same HTTP method, path, query string and exact request-body bytes. Reformatting JSON, even without changing its meaning, changes the request fingerprint.

A completed keyed request can replay its stored response without another registration submission. A duplicate still being processed returns HTTP 409 and can include Retry-After. A changed request with the same key conflicts. Do not generate a new key merely because a request timed out or returned an error: the business may already have been registered.

Keep brand.json unchanged while resolving that request. A cached 500 or 502 can replay the original error rather than retry the registration. Retain any returned brandId, requestId and correlation headers; reconcile the existing brand before starting a different request.

Read the brand and its status

This API uses HTTP status codes and a direct JSON body, rather than the v3 status/response envelope. Successful registration returns a brand object including brandId. Store that identifier and inspect the returned validation or identity status. Extra fields depend on the entity and registration state.

curl --silent --show-error --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/tcr/v2/brand/$BRAND_ID"

Read only a brand belonging to your account. A 404 can mean that the brand is not available to this account. Complete any required validation, then use brand qualification to find its available campaign use cases. Mock resources cannot be assumed eligible for production sending.

Production fees

Current configured brand registration fees
Registration	Fee
Standard organization	$5.00
Sole proprietor	$4.45
Mock brand	No brand-registration debit in the mock workflow

These retail amounts were checked against the current portal configuration on 24 October 2026. Confirm the current fee in the portal before production registration. Campaign charges, additional vetting and messaging usage are separate. A production registration checks purchase permission and available funding before submission; successful registry creation and local billing are separate processing steps, so retain the resource ID and reconcile transactions if an error or billing issue occurs.

Changing a mock brand to production is a separately confirmed workflow and can create a new production identity and charge. Do not assume that editing mock to false on a later request converts the existing brand.

Handle errors without duplicating the brand

Registration failures
HTTP result	What to check
400	Read the field errors. Registry validation errors can be an array of code/description objects. Local idempotency-key validation can also return 400.
401, 403 or 404	Check API credentials, the API account’s allowed source IP, customer permissions and ownership. A registry response can also carry its own authorization error.
402	Review funding and purchase permission. Do not treat an unfunded production request as a sandbox test.
409	Keep the same key and unchanged request when waiting for an in-progress request. A changed body/key conflict or an unrecoverable prior response needs reconciliation first.
429 or a limiter-unavailable response	Honor Retry-After when present. Retry the same intended request and key after the limit clears.
500 or 502	The remote operation may have been accepted. A local-processing error can include requestId. Save it and check the existing resource; do not assume a replacement registration is needed.