Authenticatie

Elk verzoek draagt je sleutel mee in een header. Er is geen inlogstap, geen token dat verloopt en geen refresh: één sleutel, elk verzoek.

De header

Stuur je sleutel mee als X-Rouwkaart-Access-Token. Meer is er niet.

Name
X-Rouwkaart-Access-Token
Type
verplicht
Description
Je sleutel, zoals je hem van ons hebt gekregen. Begint met rk_live_ of rk_test_.
Name
Content-Type
Type
verplicht
Description
application/json.
Name
Idempotency-Key
Type
optioneel
Description
Maakt opnieuw versturen veilig. Zie Kaarten.

Een geauthenticeerd verzoek

curl https://memoriam.rouwkaart-online.nl/partner/api/2026-10/graphql \
  -H "X-Rouwkaart-Access-Token: {access_token}" \
  -H "Content-Type: application/json" \
  -d '{"query":"{ themes(first: 1) { nodes { title } } }"}'

Twee sleutels

Je krijgt er twee. Ze werken op hetzelfde adres en spreken hetzelfde schema; het verschil zit in wat er met de kaarten gebeurt.

Name
rk_test_…
Type
teststand
Description
Kaarten krijgen test: true, alle post gaat naar het testadres dat wij voor jou hebben ingesteld, en niets telt mee in rapportages of facturatie. Hier begin je, en hier blijf je testen, ook als je al live bent.
Name
rk_live_…
Type
livestand
Description
Echte kaarten. Een bestelling is een echte bestelling en de familie krijgt echte post.

Test- en livekaarten staan los van elkaar. Een dossiernummer dat je in de teststand hebt gebruikt kun je in de livestand gewoon opnieuw gebruiken: het zijn twee gescheiden werelden.

Het voorvoegsel is er voor de mens: zo zie je in een .env-bestand of een logregel meteen in welke stand je zit. Wij leiden de stand af uit de sleutel zelf, niet uit het voorvoegsel.

Hoe wij je sleutel bewaren

Niet. Wij slaan alleen de SHA-256 van je sleutel op, en zoeken je daarop op. Dat heeft twee gevolgen die je moet weten:

Raakt onze database ooit uit, dan kan niemand daarmee verzoeken doen.
Raak jij je sleutel kwijt, dan kunnen wij hem ook niet opzoeken. Wij geven dan een nieuwe uit en de oude stopt op dat moment met werken.

Als de sleutel niet klopt

Je krijgt HTTP 401 met één melding. Dit is nog geen GraphQL-antwoord (er is niets uitgevoerd), dus errors is hier een tekst en geen lijst.

Wij maken geen onderscheid tussen "geen sleutel" en "verkeerde sleutel". Er is één uitzondering: stuur je iets mee dat niet op een sleutel lijkt, dan zeggen we dat erbij. Dat komt vaker voor dan je denkt, bijvoorbeeld als iemand per ongeluk een hash kopieert in plaats van de sleutel.

401, sleutel onbekend

{
  "errors": "[API] Invalid API key or access token (unrecognized login or wrong password)"
}

401, dit is geen sleutel

{
  "errors": "[API] Invalid API key or access token (unrecognized login or wrong password) Verwacht een sleutel in de vorm rk_live_… of rk_test_…; wat in de database staat is de hash ervan, niet de sleutel zelf."
}

Waar je sleutel niet hoort

Deze API is server-to-server. Met je sleutel kan iemand kaarten aanmaken op jouw naam en sessielinks opvragen naar kaarten van jouw dossiers. Zet hem dus nooit in browsercode, een mobiele app, een repository of een frontend-build.

Bewaar hem zoals je een databasewachtwoord bewaart: in de omgevingsvariabelen van je server, of in een secrets-kluis. Vermoed je dat hij is uitgelekt, mail ons. Wij geven binnen een dag een nieuwe uit en kunnen de oude per direct intrekken.

De playground is de uitzondering

De knop Playground rechtsboven opent een werkblad waarin je wél een sleutel invult. Het verschil met browsercode is wie hem ziet: jij typt hem in je eigen tabblad, hij gaat nergens anders heen dan naar ons endpoint, en zodra je het tabblad sluit is hij weg. Er komt geen sleutel in een pagina die je uitlevert aan een bezoeker.

Neem er toch je testsleutel voor. Wat je in de playground doet gebeurt echt, en met een live sleutel raakt dat echte kaarten en echte families.