Hoe komt een assessmentresultaat als status in je ATS?
Via statusmapping. Dat is de regel die een assessmentuitkomst (geslaagd, gezakt, onvolledig, afgebroken of proctoring mislukt) vertaalt naar een fase of status in Recruitee of SmartRecruiters. Pas daarna kan het ATS uitnodigen, afwijzen of een recruiter waarschuwen. Belangrijkste regel, onvolledig is nooit hetzelfde als gezakt.

Wat statusmapping is en waarom het misgaat zonder

Zodra Selection Lab een assessment heeft verwerkt, moet de uitkomst zichtbaar worden als status in het ATS voordat er iets anders kan gebeuren. Ontbreekt een vaste mappinglaag, dan zie je twee dingen gebeuren. Recruiters grijpen bij elk resultaat handmatig in, of automatische regels vuren verkeerd en wijzen kandidaten af die alleen een technisch probleem hadden.

Vier begrippen bepalen hoe het systeem werkt.

• Statusmapping is de ingestelde regel die een uitkomstcategorie vertaalt naar een specifieke ATS-fase of statuswaarde.
• Afwijsflow is het pad dat start als een uitkomst naar een afgewezen fase wijst, inclusief het bericht aan de kandidaat en het sluiten van de sollicitatie.
• Automatische uitnodiging is de vervolgactie (interviewuitnodiging sturen, onderdrukken of recruiter informeren) die start zodra de ATS-fase is bijgewerkt.
• Synchronisatierichting onderscheidt de twee kanten. Van ATS naar partner voor het aanmaken van de order en het versturen van de uitnodiging, van partner naar ATS voor resultaten en statusupdates.

Eén onderscheid weegt zwaarder dan alle andere. Onvolledig is niet gezakt. Een kandidaat die de sessie afbrak, verbinding verloor of in een proctoring-hold terechtkwam, is niet gezakt voor het assessment. Wie incomplete rechtstreeks naar een afgewezen fase stuurt, krijgt onterechte afwijzingen en recruiters die het systeem niet meer vertrouwen. Stuur onvolledige uitkomsten altijd naar een aparte fase als "actie nodig" of "in beoordeling", in afwachting van een menselijke check of een nieuwe uitnodiging.

De hele keten ziet er zo uit.

Intake / order aangemaakt
  → Kandidaat krijgt toegang tot het assessment
    → Uitkomst berekend (pass / fail / incomplete)
      → Uitkomst gemapt naar ATS-fase of status
        → ATS-fase bijgewerkt via API of webhook
          → ATS-automatisering start (uitnodigen / onderdrukken / melden)

De standaardmapping van Selection Lab

Selection Lab automatiseert selectiebeslissingen tot aan het interview en zet assessmentresultaten direct in het ATS, terwijl de kandidaat een gesprek voert via SmartChat, dat binnen 10 seconden reageert op WhatsApp en webchat. De standaardtabel hieronder volgt dat werkmodel.

In een standaardpipeline (apply → phone_screen → interview → evaluation → hire) gaat fail naar disqualified en blokkeert daarmee elke verdere uitnodiging. incomplete gaat naar needs_action en niet naar disqualified, zodat een recruiter kan besluiten om opnieuw uit te nodigen of de sollicitatie te sluiten. Deze voorzichtige standaard is wat de uitval in flows van Selection Lab 27% lager houdt dan in onbeheerde flows (Selection Lab Main Deck 2026, maart 2025).

Mapping aanpassen per vacature

De standaardmapping geldt op accountniveau, maar je kunt hem overschrijven per vacature, per offer en per assessmentpakket. Dat is nodig omdat het afwijsbeleid per functie verschilt. Bij volumewerving voor een magazijn is automatisch afwijzen bij een fail vaak acceptabel, terwijl bij een juridische functie elk afgerond resultaat eerst bij een recruiter moet komen voordat er een fase verandert.

Je stelt twee dingen in.

1. Uitkomst naar fase. Naar welke ATS-fase of statuswaarde elke uitkomstcategorie wijst.
2. Uitnodigingsbeleid. Of het bereiken van de gemapte fase een automatische uitnodiging start, die onderdrukt of doorzet naar de inbox van een recruiter.

De drie meest gebruikte patronen naast elkaar.

Een mapping wijzigen nadat kandidaten al zijn verwerkt, draait hun status niet met terugwerkende kracht opnieuw. Het systeem schrijft een no-op auditregel voor elke kandidaat van wie de combinatie (candidateId, jobId, orderId) al een vastgelegde uitkomst heeft. Wil je een specifieke kandidaat opnieuw door de nieuwe mapping halen, dan vraag je dat expliciet aan. Dat levert een nieuw auditrecord op in plaats van een overschrijving van het origineel.

Webhook- en API-voorbeelden

Recruitee

Webhooks in Recruitee stel je in onder Settings > Apps and Plugins > Webhooks. Je endpoint moet HTTPS gebruiken en de configuratie krijgt pas de status "Verified and created" nadat je service met HTTP 200 antwoordt op het eerste testverzoek. De gebruiker die dit instelt heeft de rol-bevoegdheid "Manage webhooks" nodig.

Elk webhook-event bevat deze velden.

{
  "id": "evt_01abc23def",
  "attempt_count": 1,
  "created_at": "2026-08-29T10:00:00Z",
  "event_type": "candidate_moved",
  "event_subtype": "disqualified",
  "payload": {
    "candidate_id": "cand_99887766",
    "job_id": "job_11223344",
    "details": {
      "to_stage": "disqualified",
      "disqualify_reason": "Assessment score below threshold"
    }
  }
}

Bij een fasewissel vooruit (pass gemapt naar interview) is het event_subtype stage_changed en bevat payload.details zowel from_stage als to_stage. Bij een afwijzing is het event_subtype disqualified en bevat payload.details to_stage plus disqualify_reason. Het subtype requalified draait een eerdere afwijzing terug, wat relevant is als een handmatige beoordeling een automatische afwijzing overrulet.

Controleer elk binnenkomend event door een HMAC-SHA256-digest van de ruwe request body te berekenen met je webhook-secret en die te vergelijken met de header X-Recruitee-Signature (hex-gecodeerd). Wijs events met een afwijkende signature af met een niet-200-status, zodat de fout in de afleverlogs van Recruitee terechtkomt.

SmartRecruiters

De assessmentpartner-integratie van SmartRecruiters werkt met OAuth. Na het uitwisselen van credentials ontvangt de partner een callback voor het aanmaken van een order zodra een kandidaat de assessmentfase bereikt. Selection Lab stuurt de resultaten terug met een PATCH op het status-endpoint van de order en vult het resultaatobject met onder meer status (bijvoorbeeld COMPLETED of FAILED), score en completedAt. Het ATS verwerkt die callback en zet de kandidaat door of houdt hem vast op basis van zijn eigen automatiseringsregels, die moeten aansluiten op de fasemapping van die vacature.

Geef orderId, packageId en het interne assessmentSessionId van Selection Lab in beide richtingen mee als correlatie-identifiers. Mislukt een callback en volgt een retry, dan kan de ontvangende kant de combinatie (candidateId, orderId) controleren en het verwerken overslaan als de faseupdate al is toegepast.

Foutafhandeling en retry-logica

Drie soorten fouten vragen elk een eigen aanpak.

1. Afleverfout. Het webhook-endpoint gaf geen HTTP 200 terug binnen de time-out.
2. API-fout. De API van de ATS-partner gaf een 4xx of 5xx terug op een statusupdate.
3. Inhoudelijke fout. De payload kwam aan, maar bevat ontbrekende scores, een afgebroken sessie of een proctoring-hold, waardoor geen definitieve pass of fail te bepalen is.

Bij Recruitee telt elke andere status dan 200 als afleverfout. Recruitee probeert het maximaal negen keer opnieuw, volgens dit schema uit de Recruitee Webhooks-documentatie.

Elke retry draagt hetzelfde id en verhoogt attempt_count. Je handler moet idempotent zijn. Controleer (candidateId, jobId, orderId) voordat je een fasewissel of uitnodigingsactie toepast. Elk verzoek wordt 30 dagen gelogd, met request body, response, het volgende geplande moment en de mogelijkheid om automatische retries te stoppen of direct een handmatige retry te starten.

Wat de limieten betreft, trial-accounts van Recruitee zijn begrensd op 5 webhook-verzoeken per minuut, alle andere accounts op 100 per minuut. Is de limiet bereikt, dan worden volgende verzoeken ongeveer 10 ± 5 minuten uitgesteld.

Bij SmartRecruiters geldt een callback als geslaagd bij een HTTP 2xx binnen de time-out van het platform. Behandel alle niet-2xx-antwoorden als herhaalbaar en voer dezelfde idempotentiecheck op orderId uit voordat je een statusupdate opnieuw toepast.

Bij inhoudelijke fouten geldt dat je een uitkomst abandoned of proctoring_failed nooit naar disqualified mapt zonder expliciete bevestiging van een recruiter. Stuur hem naar needs_action en zet het assessmentSessionId in het notitieveld van het ATS, zodat de recruiter de volledige context heeft.

Twee voorbeelden, reject-on-fail en notify-on-complete

Voorbeeld A, reject-on-fail

Mapping op vacatureniveau. fail → disqualified, pass → interview, incomplete → needs_action.

1. De kandidaat rondt het assessment van Selection Lab af.
2. Selection Lab berekent RESULT_FAIL en stuurt een fasewissel naar Recruitee (of een PATCH naar het order-endpoint van SmartRecruiters) met to_stage: disqualified en disqualify_reason: "Assessment score below threshold".
3. Het ATS start zijn automatisering voor de fase disqualified (afwijsmail, sollicitatie sluiten). Er gaat geen interviewuitnodiging uit.
4. Geeft de PATCH een niet-200 terug, dan zet Selection Lab een retry in de wachtrij. Bij elke retry controleert de handler of (candidateId, jobId, orderId) al naar disqualified wijst. Zo ja, dan geeft hij direct 200 terug zonder de fase opnieuw te schrijven, zodat er geen dubbele afwijsmails ontstaan.
5. De attempt_count in het Recruitee-event loopt op met elke afleverpoging. Daarmee zie je in je logs of er structureel iets mis is met je endpoint.

Voorbeeld B, notify-on-complete

Mapping op vacatureniveau. pass → interview (uitnodiging verstuurd), fail → evaluation (rapport opgeslagen, geen uitnodiging, geen automatische afwijzing), incomplete → needs_action.

1. De kandidaat rondt het assessment af. Selection Lab zet het volledige rapport in het ATS, ongeacht de uitkomst.
2. Bij pass zet het ATS de kandidaat door naar interview en start de uitnodigingsautomatisering.
3. Bij fail blijft de kandidaat in evaluation. De recruiter bekijkt het rapport en besluit of hij de sollicitatie sluit of de kandidaat voor een andere functie overweegt. Er wordt niet automatisch een afwijsfase geschreven.
4. Bij incomplete gaat de kandidaat naar needs_action. Na een instelbare wachttijd (bijvoorbeeld 48 uur) kan Selection Lab één nieuwe uitnodiging sturen als de recruiter niets heeft gedaan. Een teller per (candidateId, orderId) voorkomt lussen. Standaard is het maximum één nieuwe uitnodiging, daarna gaat het record alleen nog naar handmatige beoordeling.

Dit patroon past bij organisaties die geen automatische afwijzing toestaan zonder menselijke goedkeuring, en het houdt de pipeline schoon zonder dat recruiters elk gezakt resultaat direct hoeven te verwerken.

Veelgestelde vragen over statusmapping in je ATS