Read a brand’s campaign requirements

Keep the brand and use case together

Use the brand ID on your account and a use-case value returned by that same brand's qualification list. The customer workflow checks ownership before the provider request. Confirm that the returned object's usecase matches the selected value. A lookup for one brand or use case does not establish requirements for another.

Read the current requirements

Requirements used by the current campaign form
Field	How the portal uses it
minSubUsecases / maxSubUsecases	Minimum and maximum number of sub-use cases for this selection. Choose values from the valid sub-use-case catalogue rather than free text.
mnoMetadata	Carrier-specific requirements keyed by carrier ID. Use IDs present in the current response for carrier selection.
mnoSupport / qualify	Carrier support and qualification. The portal excludes carriers explicitly marked false for either field and requires at least one eligible selected carrier.
minMsgSamples	Required sample count for a carrier. The portal requires at least one nonempty sample and meets the highest minimum among the eligible selected carriers.
reqSubscriberOptin / reqSubscriberOptout / reqSubscriberHelp	Required subscriber declarations. Where required, the corresponding declaration must be true. Enabled declarations also need their keyword and response-message fields.
noEmbeddedLink / noEmbeddedPhone	Restrictions on embedded links or phone numbers. The portal rejects a declared feature if an eligible selected carrier prohibits it.

Apply the selected carriers' requirements together

Carrier requirements can differ. When no explicit carrier list is supplied, the portal considers all carrier metadata in the response; a nonempty list limits the checks to those selected IDs. Do not use only the first carrier's sample count or declarations. Select carriers from the response, check support and qualification, meet the highest applicable sample minimum, and satisfy required opt-in, opt-out and help declarations across that selection. The portal rejects selected carrier IDs absent from the current response and rejects a selection with no eligible carrier.

Requirements describe what must be supplied; they do not prove that the customer's consent process or campaign content meets those requirements. Gather truthful, representative samples and declarations. Do not automatically turn declarations on to make a form pass.

Prepare samples and subscriber responses

The current campaign form uses sample1 through sample5 for message samples. If the requirements cannot be met within the available form, stop and resolve the selection with support. For an enabled subscriber declaration, provide its corresponding keywords and response text: optinKeywords/optinMessage, optoutKeywords/optoutMessage, and helpKeywords/helpMessage. Keep samples consistent with the chosen use case and actual customer messaging.

Review before any registration request

Refresh requirements when the brand, use case or carrier selection changes. The portal revalidates the selected use case, sub-use-case count, carrier eligibility, samples and declarations before creation. Review account pricing and registration terms separately. This GET does not register or approve a campaign, share it with the messaging carrier or assign a phone number. Creation and provisioning are separate operations.

Handle a failed requirements lookup

If the request fails, returns unexpected JSON or does not match the selected use case, keep the form incomplete and let the customer retry after the error is resolved. Do not replace unavailable requirements with an empty object or assume that missing data means no requirements. Respect Retry-After and use backoff for rate limits and availability failures.

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 ID and selected use-case value 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/usecase/$USECASE"

Path parameters
Name	Type	Required	Description
`brand_id`	string	Yes	The registry brand ID associated with your authenticated MultiTEL account. Use the brand ID, not a local database row ID, campaign ID or business tax number. Encode it as one URL path segment.
`usecase`	string	Yes	The machine-readable usecase value selected from this same brand’s qualification list. Preserve its case; do not send a translated display label. Encode it as one URL path segment.

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 portal expects an object whose usecase matches the selected use case. Carrier requirements are under mnoMetadata, keyed by carrier ID. The example carrier ID and requirements are fictional. Other provider fields may be returned.

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

{
  "usecase": "2FA",
  "minSubUsecases": 0,
  "maxSubUsecases": 0,
  "mnoMetadata": {
    "12345": {
      "mnoSupport": true,
      "qualify": true,
      "minMsgSamples": 1,
      "reqSubscriberOptin": true,
      "reqSubscriberOptout": true,
      "reqSubscriberHelp": true,
      "noEmbeddedLink": false,
      "noEmbeddedPhone": false
    }
  }
}

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.