Ler os requisitos de campanha de uma marca

Mantenha a marca e o caso de uso juntos

Utilize o ID de marca da sua conta e um valor de caso de uso devolvido pela lista de qualificação dessa mesma marca. O fluxo de trabalho do cliente verifica a propriedade antes do pedido ao fornecedor. Confirme que o campo usecase do objeto devolvido corresponde ao valor selecionado. Uma consulta para uma marca ou um caso de uso não estabelece requisitos para outra marca ou outro caso de uso.

Ler os requisitos atuais

Aplique em conjunto os requisitos das operadoras selecionadas

Os requisitos das operadoras podem diferir. Quando não é fornecida nenhuma lista explícita de operadoras, o portal considera todos os metadados de operadoras presentes na resposta; uma lista não vazia limita as verificações a esses IDs selecionados. Não utilize apenas o número de amostras ou as declarações da primeira operadora. Selecione operadoras a partir da resposta, verifique o suporte e a qualificação, cumpra o mínimo de amostras mais elevado aplicável e satisfaça as declarações exigidas de opt-in, opt-out e ajuda em toda essa seleção. O portal rejeita IDs de operadoras selecionadas ausentes da resposta atual e rejeita uma seleção sem nenhuma operadora elegível.

Os requisitos descrevem o que tem de ser fornecido; não provam que o processo de consentimento do cliente ou o conteúdo da campanha cumpre esses requisitos. Recolha amostras e declarações verdadeiras e representativas. Não ative automaticamente declarações para fazer passar um formulário.

Prepare amostras e respostas ao subscritor

O formulário de campanha atual utiliza sample1 a sample5 para amostras de mensagens. Se os requisitos não puderem ser cumpridos no formulário disponível, pare e resolva a seleção com o suporte. Para uma declaração de subscritor ativada, forneça as palavras-chave e o texto de resposta correspondentes: optinKeywords/optinMessage, optoutKeywords/optoutMessage e helpKeywords/helpMessage. Mantenha as amostras coerentes com o caso de uso escolhido e com as mensagens reais enviadas pelo cliente.

Reveja antes de qualquer pedido de registo

Atualize os requisitos quando a marca, o caso de uso ou a seleção de operadoras mudar. O portal revalida o caso de uso selecionado, o número de subcasos de uso, a elegibilidade das operadoras, as amostras e as declarações antes da criação. Reveja separadamente os preços da conta e os termos de registo. Este GET não regista nem aprova uma campanha, não a partilha com a operadora de mensagens nem atribui um número de telefone. A criação e o aprovisionamento são operações separadas.

Lidar com uma consulta de requisitos falhada

Se o pedido falhar, devolver JSON inesperado ou não corresponder ao caso de uso selecionado, mantenha o formulário incompleto e permita que o cliente tente novamente depois de o erro ser resolvido. Não substitua requisitos indisponíveis por um objeto vazio nem presuma que a ausência de dados significa ausência de requisitos. Respeite Retry-After e utilize backoff para limites de pedidos e falhas de disponibilidade.

Pedido

Utilize uma conta de API ativada através de HTTPS a partir de um endereço IP de origem permitido. A rota atual suporta a política de autenticação da conta, incluindo autenticação Basic e contas de API bearer ativadas. Não utilize credenciais do fornecedor.

GET com o ID de marca e o valor do caso de uso selecionado no caminho do URL. Não é necessário nenhum corpo de pedido.

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

Resposta

A rota TCR atual devolve diretamente o corpo JSON do registo e preserva o respetivo estado HTTP. Não adiciona o envelope status/response legado da v3. O exemplo fictício abreviado não é um resultado de qualificação real. Verifique o estado HTTP e a forma JSON esperada antes de o utilizar. O portal espera um objeto cujo usecase corresponda ao caso de uso selecionado. Os requisitos das operadoras encontram-se em mnoMetadata, indexados por ID de operadora. O ID de operadora e os requisitos do exemplo são fictícios. Podem ser devolvidos outros campos do fornecedor.

Forma de resposta ilustrativa; não são dados reais da conta nem uma cotação atual.

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

Erros

• 401: A autenticação da conta falhou. Verifique as credenciais da API, o estado de ativação e as restrições aplicáveis de IP de origem.
• 404: A marca não está associada à conta autenticada, ou o fornecedor não consegue encontrar a marca ou a seleção pedida. Uma recusa local de propriedade é devolvida antes de um pedido ao fornecedor.
• Outros erros do registo: O estado HTTP e o corpo a montante são preservados. Um caso de uso inválido ou indisponível não é um conjunto de requisitos vazio bem-sucedido.
• 429: Limite de pedidos da conta ou limite partilhado do fornecedor atingido. Respeite Retry-After.
• 502/503: Falha de disponibilidade de transporte, do fornecedor ou do limitador de taxa. Preserve o formulário e tente novamente com backoff.

Disponibilidade e efeitos secundários

• O GET revisto verifica a propriedade existente da marca, contacta o registo e escreve registos de auditoria de pedidos. Não cria uma marca nem uma campanha e não cobra uma taxa de registo.
• Os metadados de taxas do fornecedor não são uma cotação de retalho para clientes MultiTEL. O portal revê separadamente os preços da conta antes de um pedido de registo posterior.
• A qualificação e os requisitos podem mudar. Atualize-os para a marca e o caso de uso selecionados antes da submissão. Uma consulta bem-sucedida não é uma aprovação de campanha, uma atribuição de número nem uma permissão para começar a enviar mensagens.