Läser register…
Avdelning 03
Suppression-API:et låter er kontrollera en identifierare mot registrerade spärrar — men det tar aldrig emot en identifierare i klartext. Ni beräknar en hash själva, med er egen peppar, och skickar bara den. Vi tar aldrig emot en e-postadress eller ett telefonnummer.
sha256:<er egen peppar + värdet> lokalt, innan något skickas över TLS. Formen är strikt: sha256: följt av exakt 64 hexadecimala tecken. Ett rått värde som anna@example.se är inte ens ett försök till en giltig identifier_hash — det matchar inte formatet och avvisas som 400.mm_live_… i produktion, mm_test_… mot staging — inte samma Bearer-token som resten av API:et. Fel miljö, okänd nyckel eller ingen nyckel ger samma 401 i alla tre fallen; inget läcks om vilka nycklar som finns.curl -sS https://api.marketmute.com/v1/suppression/check \
-H "Authorization: Bearer mm_live_..." \
-H "Content-Type: application/json" \
-H "Idempotency-Key: <example-idempotency-key>" \
-d '{
"channel": "email",
"purpose": "direct_marketing",
"identifier_hash": "sha256:9f1a3c00e2b7d4f1a0c5e6b7d8f9a0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7",
"sender_ref": "kampanj-2026-h2"
}'
{
"error": "tokenization_not_provisioned",
"message": "Spärrkontrollen kan inte besvaras för den här identifieraren. ...",
"receipt_id": "sup_rcpt_...",
"checked_at": "2026-08-24T10:15:00Z"
}
POST /v1/suppression/batch tar samma channel/purpose plus en lista identifier_hashes. Taket är 10 000 hashar per anrop — en batch över taket avvisas i sin HELHET med 400 batch_too_large; inget trunkeras tyst för er.Spärrarna i registret lagras som MarketMute-beräknade HMAC-token över det normaliserade värdet. En hash som NI beräknat med er egen peppar går inte att jämföra mot dem, och råvärdet som skulle behövas för att räkna om finns med avsikt inte kvar hos oss — det är hela poängen med att aldrig ta emot klartext. Ett per-avsändarindex för den jämförelsen saknas därför i datamodellen.
Anropet valideras, bokförs mot er kvot och loggas som vanligt. Det som uteblir är just matchningsutfallet. Vi svarar hellre 501 med en förklaring än 200 med ett hittepå-värde — samma princip som resten av API:et följer när en yta inte är i drift än.
Nio möjliga svar, ett åt gången — fäll ut koden ni faktiskt fick för att läsa vad den betyder och vad ni gör härnäst.
tokenization_not_provisionedAlltid detta för ett strukturellt giltigt anrop idag.
Läs message och receipt_id. Vänta inte på ett annat svar — bevaka i stället ändringsloggen för när matchningen går live.
invalid_bodyKroppen saknas eller går inte att tolka som JSON.
Rätta anropet.
invalid_identifier_hashEtt värde matchar inte sha256:<64 hex> — inklusive råa identifierare.
Beräkna hashen lokalt innan ni skickar.
empty_batchidentifier_hashes saknas eller är tom (endast /batch).
Skicka minst en hash.
batch_too_largeFler än 10 000 hashar i en batch. Hela anropet avvisas.
Dela upp i flera anrop.
unauthorizedNyckeln saknas, är okänd eller hör till fel miljö.
Kontrollera Authorization-headern och mm_test_/mm_live_-prefixet.
idempotency_conflictIdempotency-Key återanvänd med en ANNAN kropp.
Använd en ny nyckel per unik begäran.
unsupported_scopeOkänt channel eller purpose.
Se giltiga värden nedan.
rate_limitedKvoten för nyckeln är förbrukad.
Vänta det antal sekunder Retry-After anger.
| Fält | Värden |
|---|---|
| channel | phone, email, sms, direct_mail, profiling, crm_marketing, all_direct_marketing |
| purpose | direct_marketing, profiling |
Kvoten räknas per API-nyckel, inte per IP — annars kunde en enda batch på 10 000 hashar kringgå anropstaket. Ett svar bär alltid headern RateLimit-Remaining; ett 429-svar bär även Retry-After i sekunder.
| Gräns | Standardvärde | Vid överskridande |
|---|---|---|
| Anrop / minut | 1 000 | 429 |
| Hashar / minut | 100 000 | 429 |
Hur spärregistret hålls åtskilt från personuppgifterna beskrivs i avdelning 05. Ändringar i registret kan i framtiden levereras som signerade händelser — se avdelning 04.