Carregar catálogos para registro de mensagens

Carregue as opções antes de criar um formulário de registro

Use o catálogo atual de registro de mensagens para preencher as opções em vez de fixar os valores do registro no código. Para um formulário de marca, o portal carrega os catálogos de tipo de empresa, setor, tipo de identificador empresarial alternativo, relação com a marca, país, estado dos Estados Unidos e bolsa de valores. Para um formulário de campanha, carrega casos de uso, subcasos de uso válidos e parceiros de conectividade. Mantenha cada valor retornado para processamento automático junto com seu rótulo de exibição; ao montar uma solicitação posterior, use o valor, não um rótulo traduzido.

Escolha um catálogo

Processe diretamente a resposta de TCR

O corpo da resposta vem diretamente da API de TCR. Ao contrário de muitos pontos de acesso antigos de /v3, ele não tem um invólucro status/response adicional. Verifique o código de status HTTP antes de interpretá-lo. Um catálogo pode conter rótulos de texto ou definições estruturadas, portanto não presuma que todos os valores tenham os mesmos campos. Se a solicitação HTTP for bem-sucedida, mas o corpo não for um JSON válido com a estrutura esperada, informe que a consulta falhou em vez de substituí-lo silenciosamente por uma lista vazia.

Separe as opções do catálogo da elegibilidade e dos preços

Um catálogo geral de casos de uso não informa para quais casos de uso uma marca específica é elegível. O portal atual faz uma consulta de elegibilidade específica da marca antes de criar a campanha e verifica os requisitos das operadoras selecionadas. Da mesma forma, os metadados de tarifas de um fornecedor não representam o preço final de venda ao cliente da conta. Revise separadamente o preço aplicável à conta e os termos de registro. Carregar um catálogo não aprova uma marca, uma campanha ou um número de mensagens.

Lide com catálogos indisponíveis

Preserve os dados inseridos pelo cliente no formulário se uma consulta falhar. Exiba o erro, respeite Retry-After quando retornado e use intervalos progressivos entre as tentativas. Não recarregue todos os catálogos repetidamente nem trate um erro de limite de solicitações ou de transporte como um catálogo vazio válido. Esta solicitação GET não exige uma chave de idempotência e não é reproduzida a partir do armazenamento de idempotência de operações de alteração.

Solicitação

Use uma conta de API habilitada por meio de HTTPS a partir de um endereço IP de origem permitido. A rota atual aceita a política de autenticação da conta, incluindo autenticação Basic e contas de API habilitadas com autenticação por token de portador. Não use credenciais do provedor.

Faça uma solicitação GET com um nome de catálogo aceito no caminho. Inclua os filtros de catálogo aplicáveis na cadeia de consulta. Não é necessário um corpo de solicitação.

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

Resposta

Esta rota de TCR retorna diretamente o corpo do registro com seu código de status HTTP. Ela não usa o antigo invólucro status.code/status.msg/response de v3. As estruturas dos catálogos variam: alguns associam valores a objetos descritivos; outros associam valores a cadeias de caracteres. Preserve as chaves legíveis por máquina ao enviar um formulário posterior. O exemplo fictício abreviado de usecase ilustra um mapa cujos valores são objetos; não é um catálogo em produção nem garante um esquema completo. Verifique tanto o código de status HTTP quanto a estrutura JSON esperada.

Estrutura de resposta ilustrativa; não contém dados reais da conta nem constitui uma cotação vigente.

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

Erros

• 401: A autenticação da conta falhou. Verifique a credencial de API, se a conta está habilitada e as restrições de IP de origem aplicáveis.
• 400/404 e outros erros do registro: catálogo ou filtro inválido ou indisponível. A rota atual preserva o código de status HTTP e o corpo da resposta do serviço de origem; não existe um invólucro universal de erros da v3.
• 429: O limite de solicitações da conta ou o limite compartilhado do provedor foi atingido. Respeite Retry-After e tente novamente com intervalos progressivos.
• 502: Não foi possível acessar o registro. A disponibilidade é desconhecida; não apresente opções vazias em seu lugar como se fossem um resultado bem-sucedido.
• 503: O limitador de solicitações ou o serviço de origem está indisponível. Examine o corpo e qualquer cabeçalho Retry-After antes de tentar novamente.

Disponibilidade e efeitos colaterais

• Esta solicitação GET de catálogo não cria uma marca ou campanha, não envia uma solicitação de registro, não reserva um recurso nem cobra uma taxa de registro no caminho revisado. Ela contata o provedor e grava registros de auditoria das solicitações.
• As definições do catálogo e quaisquer metadados de tarifas do fornecedor não constituem uma cotação de venda ao cliente. O portal atual obtém separadamente os preços de venda das campanhas; a antiga função auxiliar getCampaignPrice e as antigas anotações de preços de enumerações não devem ser tratadas como o contrato de preços desta rota.
• Uma entrada de catálogo aceita não comprova que uma marca específica seja elegível para esse caso de uso. Conclua a avaliação de elegibilidade específica da marca, as declarações, o consentimento e a revisão dos preços da conta antes de fazer uma solicitação de registro posterior.