Load messaging registration catalogues

Load choices before building a registration form

Use the current messaging registration catalogue to populate choices instead of hardcoding registry values. For a brand form, the portal loads business type, industry, alternate business identifier type, brand relationship, country, US state and stock exchange catalogues. For a campaign form, it loads use cases, valid sub-use cases and connectivity partners. Keep each returned machine value with its display label; use the value, not a translated label, when building a later request.

Choose a catalogue

Catalogues used by the portal
Name	Purpose
usecase	Campaign use-case definitions. Add validSubUsecase=true when loading sub-use-case choices.
entityType	Business or organization type for a brand.
vertical	Industry choices for a brand.
altBusinessIdType	Alternative business identifier categories.
brandRelationship	Relationship choices used by the registration form.
country	Registry country choices; these are separate from phone-number availability countries.
usState	US state choices for registration addresses.
stockExchange	Exchange choices where the brand's business type requires them.
cnp	Connectivity partner identifiers. Choose the partner supported by your account's campaign workflow.

Handle the TCR response directly

The response body belongs directly to the TCR API. Unlike many older /v3 endpoints, it has no added status/response wrapper. Check the HTTP status before interpreting it. A catalogue can contain string labels or structured definitions, so do not assume every value has the same fields. If the HTTP request succeeds but the body is not valid JSON of the expected shape, report a failed lookup instead of silently replacing it with an empty list.

Separate catalogue choices from qualification and pricing

A general use-case catalogue does not tell you which use cases an individual brand qualifies for. The current portal performs a brand-specific qualification lookup before campaign creation and checks the selected carrier requirements. Likewise, a supplier's fee metadata is not the account's final retail price. Review the applicable account price and registration terms separately. Loading a catalogue does not approve a brand, campaign or messaging number.

Handle unavailable catalogues

Preserve the customer's form entries if a lookup fails. Show the error, respect Retry-After when returned, and use backoff. Do not repeatedly reload every catalogue or treat a rate-limit or transport error as an empty valid catalogue. This GET does not require an idempotency key and is not replayed from the mutation idempotency store.

Request

Use an enabled API account over HTTPS from an allowed source IP address. The current route supports the account authentication policy, including Basic authentication and enabled bearer API accounts. Do not use provider credentials.

GET with a supported catalogue name in the path. Pass applicable catalogue filters in the query string. No request body is needed.

curl --fail-with-body --silent --show-error \
  --user "$API_USER:$API_PASSWORD" \
  "https://api.multitel.net/tcr/v2/enum/usecase?validSubUsecase=true"

Path parameters
Name	Type	Required	Description
`type`	string	Yes	Catalogue name, with its original case. The portal uses usecase, entityType, vertical, altBusinessIdType, brandRelationship, country, usState, stockExchange and cnp. These are catalogue names, not brand or campaign identifiers.

Query parameters
Name	Type	Required	Description
`validSubUsecase`	boolean	No	For the usecase catalogue, the portal requests true to load valid sub-use-case choices. Omit it when loading the ordinary use-case catalogue. Availability and definitions are supplied by the registry.

Response

This TCR route returns the registry body directly with its HTTP status. It does not use the older v3 status.code/status.msg/response envelope. Catalogue shapes differ: some map values to descriptive objects; others map values to strings. Preserve the machine-readable keys when submitting a later form. The abbreviated fictional usecase example illustrates an object-valued map, not a live catalogue or guaranteed complete schema. Check both HTTP status and the expected JSON shape.

Illustrative response shape; not live account data or a current quote.

{
  "2FA": {
    "displayName": "Authentication",
    "description": "Example authentication use case"
  }
}

Errors

401: Account authentication failed. Check the API credential, enabled state and applicable source-IP restrictions.
400/404 and other registry errors: Invalid or unavailable catalogue or filter. The current route preserves the upstream HTTP status and response body; there is no universal v3 error envelope.
429: Account or shared provider request limit reached. Respect Retry-After and retry with backoff.
502: The registry could not be reached. Availability is unknown; do not substitute empty choices as a successful result.
503: The request limiter or upstream service is unavailable. Inspect the body and any Retry-After header before retrying.

Availability and side effects

This catalogue GET does not create a brand or campaign, submit a registration, reserve a resource or charge a registration fee in the reviewed path. It contacts the provider and writes request-audit records.
Catalogue definitions and any supplier fee metadata are not a customer retail quote. The current portal obtains retail campaign pricing separately; the legacy getCampaignPrice helper and old enum price annotations must not be treated as this route's pricing contract.
A supported catalogue entry is not proof that a particular brand qualifies for that use case. Complete brand-specific qualification, declarations, consent and account pricing review before a later registration request.