Check a brand’s available campaign use cases

Select an existing brand on your account

Start with the registry brand ID already associated with your MultiTEL account. This lookup does not create a brand or attach someone else's brand to your account. The current customer workflow checks ownership before requesting qualifications. If the lookup returns 404, verify the selected account and brand instead of substituting a local row ID.

Build the use-case choices from this result

The general use-case catalogue describes registry options. This brand-specific lookup supplies the choices for the selected brand. Keep each returned usecase value and combine it with the catalogue's display label and description. Do not offer every general catalogue entry as if the brand qualified for it.

The portal expects this response to be a JSON list. If it is missing, malformed or an error, preserve the customer's form and show that qualification could not be loaded. Do not silently treat it as approval for a default use case. Fields beyond the abbreviated example may be returned by the registry.

Load requirements for the selected use case

After a customer chooses a returned use-case value, request /tcr/v2/campaignBuilder/brand/{brand_id}/usecase/{usecase} for the same brand. That response supplies sub-use-case bounds and carrier-specific requirements. Use it to gather message samples, consent and other required declarations. The qualification list alone is not enough to construct a complete campaign registration.

Review account pricing separately

Provider fields such as monthlyFee, quarterlyFee or annualFee, when returned, describe provider fee metadata. They do not replace the customer's account price or the registration terms. The current portal reads retail campaign prices separately and combines them with qualification data for its review screen. Do not infer a customer charge from the old enum helper's hardcoded prices.

Refresh when the brand or use case changes

Discard the previous brand's choices when switching brands and load qualifications for the new selection. Refresh the selected use case's requirements before submission. These GET requests do not submit a registration, activate a campaign or assign numbers.

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 the brand identifier in the URL path. No request body is required.

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

Response

The current TCR route returns the registry JSON body directly and preserves its HTTP status. It does not add the legacy v3 status/response envelope. The abbreviated fictional example is not a live qualification result. Check HTTP status and the expected JSON shape before using it. The current portal expects a list of qualification records, each identifying a usecase. It combines those records with the usecase catalogue for display labels and reads retail prices separately. Additional provider fields can be present.

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

[
  {
    "usecase": "2FA"
  }
]

Errors

• 401: Account authentication failed. Check the API credentials, enabled state and applicable source-IP restrictions.
• 404: The brand is not associated with the authenticated account, or the provider cannot find the requested brand or selection. A local ownership denial is returned before a provider request.
• Other registry errors: The upstream HTTP status and body are preserved. An invalid or unavailable use case is not a successful empty requirement set.
• 429: Account or shared provider request limit reached. Respect Retry-After.
• 502/503: Transport, provider or rate-limiter availability failure. Preserve the form and retry with backoff.

Availability and side effects

• The reviewed GET checks existing brand ownership, contacts the registry and writes request-audit records. It does not create a brand or campaign or charge a registration fee.
• Provider fee metadata is not a MultiTEL customer retail quote. The portal reviews account pricing separately before a later registration request.
• Qualification and requirements can change. Refresh them for the selected brand and use case before submission. A successful lookup is not a campaign approval, number assignment or permission to begin messaging.