Leggere i requisiti di campagna di un brand

Mantenere insieme brand e caso d'uso

Usa l'ID del brand presente sul tuo account e un valore di caso d'uso restituito dall'elenco di qualificazione dello stesso brand. Il flusso di lavoro del cliente verifica la titolarità prima della richiesta al provider. Conferma che il campo usecase dell'oggetto restituito corrisponda al valore selezionato. Una ricerca per un brand o un caso d'uso non stabilisce i requisiti per un altro.

Leggere i requisiti attuali

Requisiti usati dal modulo di campagna attuale
Campo	Come lo usa il portale
minSubUsecases / maxSubUsecases	Numero minimo e massimo di sotto-casi d'uso per questa selezione. Scegli i valori dal catalogo dei sotto-casi d'uso validi anziché usare testo libero.
mnoMetadata	Requisiti specifici per operatore, indicizzati per ID operatore. Per la selezione degli operatori usa gli ID presenti nella risposta attuale.
mnoSupport / qualify	Supporto e qualificazione dell'operatore. Il portale esclude gli operatori esplicitamente contrassegnati come false per uno dei due campi e richiede almeno un operatore selezionato idoneo.
minMsgSamples	Numero di esempi richiesto per un operatore. Il portale richiede almeno un esempio non vuoto e soddisfa il minimo più alto tra gli operatori selezionati idonei.
reqSubscriberOptin / reqSubscriberOptout / reqSubscriberHelp	Dichiarazioni dell'abbonato richieste. Dove richiesta, la dichiarazione corrispondente deve essere true. Le dichiarazioni abilitate necessitano inoltre dei relativi campi di parola chiave e messaggio di risposta.
noEmbeddedLink / noEmbeddedPhone	Restrizioni sui link o sui numeri di telefono incorporati. Il portale rifiuta una funzionalità dichiarata se un operatore selezionato idoneo la vieta.

Applicare insieme i requisiti degli operatori selezionati

I requisiti degli operatori possono differire. Quando non viene fornito un elenco esplicito di operatori, il portale considera tutti i metadati degli operatori presenti nella risposta; un elenco non vuoto limita i controlli agli ID selezionati. Non usare solo il numero di esempi o le dichiarazioni del primo operatore. Seleziona gli operatori dalla risposta, verifica supporto e qualificazione, soddisfa il minimo di esempi più alto applicabile e rispetta le dichiarazioni richieste di opt-in, opt-out e help per l'intera selezione. Il portale rifiuta gli ID operatore selezionati assenti dalla risposta attuale e rifiuta una selezione priva di operatori idonei.

I requisiti descrivono ciò che deve essere fornito; non dimostrano che il processo di consenso del cliente o il contenuto della campagna soddisfi tali requisiti. Raccogli esempi e dichiarazioni veritieri e rappresentativi. Non attivare automaticamente le dichiarazioni per far superare la convalida a un modulo.

Preparare esempi e risposte per gli abbonati

Il modulo di campagna attuale usa i campi da sample1 a sample5 per gli esempi di messaggio. Se i requisiti non possono essere soddisfatti con il modulo disponibile, fermati e risolvi la selezione con il supporto. Per una dichiarazione dell'abbonato abilitata, fornisci le parole chiave e il testo di risposta corrispondenti: optinKeywords/optinMessage, optoutKeywords/optoutMessage e helpKeywords/helpMessage. Mantieni gli esempi coerenti con il caso d'uso scelto e con la messaggistica reale del cliente.

Rivedere prima di qualsiasi richiesta di registrazione

Aggiorna i requisiti quando cambia la selezione del brand, del caso d'uso o degli operatori. Il portale riconvalida il caso d'uso selezionato, il numero di sotto-casi d'uso, l'idoneità degli operatori, gli esempi e le dichiarazioni prima della creazione. Rivedi separatamente i prezzi dell'account e i termini di registrazione. Questa GET non registra né approva una campagna, non la condivide con l'operatore di messaggistica e non assegna un numero di telefono. La creazione e il provisioning sono operazioni separate.

Gestire una ricerca dei requisiti non riuscita

Se la richiesta fallisce, restituisce un JSON inatteso o non corrisponde al caso d'uso selezionato, mantieni il modulo incompleto e lascia che il cliente riprovi dopo che l'errore è stato risolto. Non sostituire i requisiti non disponibili con un oggetto vuoto e non presumere che l'assenza di dati significhi assenza di requisiti. Rispetta Retry-After e usa il backoff per i limiti di frequenza e i guasti di disponibilità.

Richiesta

Usa un account API abilitato tramite HTTPS da un indirizzo IP di origine consentito. La route attuale supporta la policy di autenticazione dell'account, inclusa l'autenticazione Basic e gli account API bearer abilitati. Non usare le credenziali del provider.

GET con l'ID del brand e il valore del caso d'uso selezionato nel percorso dell'URL. Non è richiesto alcun corpo della richiesta.

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

Parametri di percorso
Nome	Tipo	Obbligatorio	Descrizione
`brand_id`	string	Sì	L'ID del brand nel registro associato al tuo account MultiTEL autenticato. Usa l'ID del brand, non un ID di riga del database locale, un ID di campagna o un numero di identificazione fiscale dell’impresa. Codificalo come un unico segmento del percorso URL.
`usecase`	string	Sì	Il valore usecase leggibile dalla macchina selezionato dall'elenco di qualificazione dello stesso brand. Mantieni le maiuscole e minuscole; non inviare un'etichetta di visualizzazione tradotta. Codificalo come un unico segmento del percorso URL.

Risposta

La route TCR attuale restituisce direttamente il corpo JSON del registro e ne conserva lo stato HTTP. Non aggiunge l'involucro legacy v3 status/response. L'esempio abbreviato e fittizio non è un risultato di qualificazione reale. Verifica lo stato HTTP e la forma JSON attesa prima di usarlo. Il portale si aspetta un oggetto il cui usecase corrisponda al caso d'uso selezionato. I requisiti degli operatori si trovano sotto mnoMetadata, indicizzati per ID operatore. L'ID operatore e i requisiti dell'esempio sono fittizi. Possono essere restituiti altri campi del provider.

Forma illustrativa della risposta; non si tratta di dati reali dell'account né di un preventivo attuale.

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

Errori

401: Autenticazione dell'account non riuscita. Controlla le credenziali API, lo stato di abilitazione e le restrizioni applicabili sull'IP di origine.
404: Il brand non è associato all'account autenticato, oppure il provider non trova il brand o la selezione richiesti. Un rifiuto locale per titolarità viene restituito prima di una richiesta al provider.
Altri errori del registro: lo stato HTTP e il corpo upstream vengono conservati. Un caso d'uso non valido o non disponibile non è un insieme di requisiti vuoto restituito con successo.
429: Raggiunto il limite di richieste dell'account o del provider condiviso. Rispetta Retry-After.
502/503: Guasto di disponibilità del trasporto, del provider o del limitatore di frequenza. Conserva il modulo e riprova con backoff.

Disponibilità ed effetti collaterali

La GET revisionata verifica la titolarità esistente del brand, contatta il registro e scrive record di audit delle richieste. Non crea un brand o una campagna e non addebita una tariffa di registrazione.
I metadati sulle tariffe del provider non sono un preventivo al dettaglio per il cliente MultiTEL. Il portale rivede separatamente i prezzi dell'account prima di una successiva richiesta di registrazione.
La qualificazione e i requisiti possono cambiare. Aggiornali per il brand e il caso d'uso selezionati prima dell'invio. Una ricerca riuscita non è un'approvazione della campagna, un'assegnazione di numero o un permesso per iniziare la messaggistica.