Läs ett varumärkes kampanjkrav

Håll varumärket och användningsfallet tillsammans

Använd varumärkes-ID:t på ditt konto och ett användningsfallsvärde som returnerats av samma varumärkes kvalificeringslista. Kundarbetsflödet kontrollerar ägarskap före leverantörsbegäran. Bekräfta att det returnerade objektets usecase matchar det valda värdet. En uppslagning för ett varumärke eller användningsfall fastställer inte krav för ett annat.

Läs de aktuella kraven

Tillämpa de valda operatörernas krav tillsammans

Operatörskrav kan skilja sig åt. När ingen uttrycklig operatörslista anges beaktar portalen all operatörsmetadata i svaret; en icke-tom lista begränsar kontrollerna till de valda ID:na. Använd inte enbart den första operatörens exempelantal eller deklarationer. Välj operatörer från svaret, kontrollera stöd och kvalificering, uppfyll det högsta tillämpliga minimiantalet exempel och uppfyll obligatoriska deklarationer för opt-in, opt-out och hjälp över hela det urvalet. Portalen avvisar valda operatörs-ID:n som saknas i det aktuella svaret och avvisar ett urval utan någon behörig operatör.

Kraven beskriver vad som måste tillhandahållas; de bevisar inte att kundens samtyckesprocess eller kampanjinnehåll uppfyller dessa krav. Samla in sanningsenliga, representativa exempel och deklarationer. Slå inte automatiskt på deklarationer för att få ett formulär att gå igenom.

Förbered exempel och abonnentsvar

Det aktuella kampanjformuläret använder sample1 till och med sample5 för meddelandeexempel. Om kraven inte kan uppfyllas inom det tillgängliga formuläret, stanna upp och lös valet tillsammans med supporten. För en aktiverad abonnentdeklaration, ange dess motsvarande nyckelord och svarstext: optinKeywords/optinMessage, optoutKeywords/optoutMessage och helpKeywords/helpMessage. Håll exemplen förenliga med det valda användningsfallet och kundens faktiska meddelanden.

Granska före varje registreringsbegäran

Uppdatera kraven när valet av varumärke, användningsfall eller operatör ändras. Portalen validerar på nytt det valda användningsfallet, antalet underanvändningsfall, operatörsbehörighet, exempel och deklarationer före skapandet. Granska kontots prissättning och registreringsvillkor separat. Denna GET registrerar eller godkänner inte en kampanj, delar den inte med meddelandeoperatören och tilldelar inget telefonnummer. Skapande och provisionering är separata åtgärder.

Hantera en misslyckad uppslagning av krav

Om begäran misslyckas, returnerar oväntad JSON eller inte matchar det valda användningsfallet, låt formuläret förbli ofullständigt och låt kunden försöka igen efter att felet har åtgärdats. Ersätt inte otillgängliga krav med ett tomt objekt och anta inte att saknade data innebär att inga krav finns. Respektera Retry-After och använd backoff vid hastighetsbegränsningar och tillgänglighetsfel.

Begäran

Använd ett aktiverat API-konto över HTTPS från en tillåten käll-IP-adress. Den aktuella rutten stöder kontots autentiseringspolicy, inklusive Basic-autentisering och aktiverade API-konton med bearer-token. Använd inte leverantörens inloggningsuppgifter.

GET med varumärkes-ID:t och det valda användningsfallsvärdet i URL-sökvägen. Ingen begärandekropp krävs.

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

Svar

Den aktuella TCR-rutten returnerar registrets JSON-kropp direkt och bevarar dess HTTP-status. Den lägger inte till det äldre v3-höljet status/response. Det förkortade fiktiva exemplet är inte ett verkligt kvalificeringsresultat. Kontrollera HTTP-status och den förväntade JSON-formen innan du använder det. Portalen förväntar sig ett objekt vars usecase matchar det valda användningsfallet. Operatörskrav finns under mnoMetadata, nycklade efter operatörs-ID. Exemplets operatörs-ID och krav är fiktiva. Andra leverantörsfält kan returneras.

Illustrativ svarsform; inte verkliga kontodata eller en aktuell offert.

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

Fel

• 401: Kontoautentiseringen misslyckades. Kontrollera API-inloggningsuppgifterna, aktiveringsstatusen och tillämpliga käll-IP-begränsningar.
• 404: Varumärket är inte kopplat till det autentiserade kontot, eller så kan leverantören inte hitta det begärda varumärket eller valet. Ett lokalt ägarskapsavslag returneras före en leverantörsbegäran.
• Övriga registerfel: Uppströms HTTP-status och kropp bevaras. Ett ogiltigt eller otillgängligt användningsfall är inte en lyckad tom kravuppsättning.
• 429: Kontots eller den delade leverantörens begärandegräns har nåtts. Respektera Retry-After.
• 502/503: Tillgänglighetsfel i transport, leverantör eller hastighetsbegränsare. Bevara formuläret och försök igen med backoff.

Tillgänglighet och sidoeffekter

• Den granskade GET kontrollerar befintligt varumärkesägarskap, kontaktar registret och skriver granskningsposter för begäran. Den skapar inte ett varumärke eller en kampanj och debiterar ingen registreringsavgift.
• Leverantörens avgiftsmetadata är inte en detaljhandelsoffert för MultiTEL-kunder. Portalen granskar kontots prissättning separat före en senare registreringsbegäran.
• Kvalificering och krav kan ändras. Uppdatera dem för det valda varumärket och användningsfallet före inskickning. En lyckad uppslagning är inte ett kampanjgodkännande, en nummertilldelning eller ett tillstånd att börja skicka meddelanden.