De campagnevereisten van een merk lezen

Houd merk en use case bij elkaar

Gebruik de merk-ID van uw account en een use-casewaarde die door de kwalificatielijst van datzelfde merk is teruggegeven. De klantworkflow controleert het eigendom vóór het providerverzoek. Bevestig dat de usecase van het teruggegeven object overeenkomt met de geselecteerde waarde. Een opzoeking voor het ene merk of de ene use case stelt geen vereisten vast voor een ander merk of een andere use case.

Lees de huidige vereisten

Pas de vereisten van de geselecteerde carriers gezamenlijk toe

Carriervereisten kunnen verschillen. Wanneer geen expliciete carrierlijst wordt opgegeven, neemt het portaal alle carriermetadata in het antwoord in aanmerking; een niet-lege lijst beperkt de controles tot die geselecteerde ID's. Gebruik niet alleen het aantal voorbeelden of de verklaringen van de eerste carrier. Selecteer carriers uit het antwoord, controleer ondersteuning en kwalificatie, voldoe aan het hoogste toepasselijke minimumaantal voorbeelden en voldoe aan de vereiste opt-in-, opt-out- en helpverklaringen voor die hele selectie. Het portaal wijst geselecteerde carrier-ID's af die in het huidige antwoord ontbreken en wijst een selectie zonder in aanmerking komende carrier af.

Vereisten beschrijven wat moet worden aangeleverd; ze bewijzen niet dat het toestemmingsproces of de campagne-inhoud van de klant aan die vereisten voldoet. Verzamel waarheidsgetrouwe, representatieve voorbeelden en verklaringen. Schakel verklaringen niet automatisch in om een formulier te laten slagen.

Bereid voorbeelden en abonneeantwoorden voor

Het huidige campagneformulier gebruikt sample1 tot en met sample5 voor berichtvoorbeelden. Als binnen het beschikbare formulier niet aan de vereisten kan worden voldaan, stop dan en los de selectie op met de ondersteuning. Geef voor een ingeschakelde abonneeverklaring de bijbehorende trefwoorden en antwoordtekst op: optinKeywords/optinMessage, optoutKeywords/optoutMessage en helpKeywords/helpMessage. Houd voorbeelden consistent met de gekozen use case en de werkelijke klantberichten.

Controleer vóór elk registratieverzoek

Vernieuw de vereisten wanneer de selectie van merk, use case of carrier verandert. Het portaal valideert de geselecteerde use case, het aantal sub-use cases, de carriergeschiktheid, de voorbeelden en de verklaringen opnieuw vóór het aanmaken. Beoordeel de accountprijzen en registratievoorwaarden afzonderlijk. Deze GET registreert geen campagne, keurt deze niet goed, deelt deze niet met de berichtencarrier en wijst geen telefoonnummer toe. Aanmaken en provisionering zijn afzonderlijke bewerkingen.

Een mislukte opzoeking van vereisten afhandelen

Als het verzoek mislukt, onverwachte JSON retourneert of niet overeenkomt met de geselecteerde use case, houd het formulier dan onvolledig en laat de klant het opnieuw proberen nadat de fout is opgelost. Vervang niet-beschikbare vereisten niet door een leeg object en neem niet aan dat ontbrekende gegevens betekenen dat er geen vereisten zijn. Respecteer Retry-After en gebruik backoff bij snelheidslimieten en beschikbaarheidsstoringen.

Verzoek

Gebruik een ingeschakeld API-account via HTTPS vanaf een toegestaan bron-IP-adres. De huidige route ondersteunt het authenticatiebeleid van het account, inclusief Basic-authenticatie en ingeschakelde bearer-API-accounts. Gebruik geen providerreferenties.

GET met de merk-ID en de geselecteerde use-casewaarde in het URL-pad. Er is geen verzoekbody vereist.

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

Antwoord

De huidige TCR-route retourneert de JSON-body van het register rechtstreeks en behoudt de HTTP-status ervan. Ze voegt niet de verouderde v3-status/response-envelop toe. Het verkorte fictieve voorbeeld is geen live kwalificatieresultaat. Controleer de HTTP-status en de verwachte JSON-vorm voordat u het gebruikt. Het portaal verwacht een object waarvan de usecase overeenkomt met de geselecteerde use case. Carriervereisten staan onder mnoMetadata, gesleuteld op carrier-ID. De carrier-ID en vereisten in het voorbeeld zijn fictief. Er kunnen andere providervelden worden geretourneerd.

Illustratieve antwoordvorm; geen live accountgegevens of een actuele offerte.

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

Fouten

• 401: Accountauthenticatie mislukt. Controleer de API-referenties, de ingeschakelde status en de toepasselijke bron-IP-beperkingen.
• 404: Het merk is niet aan het geauthenticeerde account gekoppeld, of de provider kan het gevraagde merk of de gevraagde selectie niet vinden. Een lokale eigendomsweigering wordt geretourneerd vóór een providerverzoek.
• Overige registerfouten: de upstream-HTTP-status en -body worden behouden. Een ongeldige of niet-beschikbare use case is geen geslaagde lege set vereisten.
• 429: Verzoeklimiet van het account of van de gedeelde provider bereikt. Respecteer Retry-After.
• 502/503: Beschikbaarheidsstoring van transport, provider of snelheidsbegrenzer. Behoud het formulier en probeer het opnieuw met backoff.

Beschikbaarheid en neveneffecten

• De beoordeelde GET controleert het bestaande merkeigendom, neemt contact op met het register en schrijft verzoekauditrecords. Ze maakt geen merk of campagne aan en brengt geen registratiekosten in rekening.
• Providerkostenmetadata is geen retailofferte voor MultiTEL-klanten. Het portaal beoordeelt de accountprijzen afzonderlijk vóór een later registratieverzoek.
• Kwalificatie en vereisten kunnen veranderen. Vernieuw ze voor het geselecteerde merk en de geselecteerde use case vóór indiening. Een geslaagde opzoeking is geen campagnegoedkeuring, nummertoewijzing of toestemming om te beginnen met het versturen van berichten.