DarwinBox can hand candidates to SpringVerify at two different points in the hiring journey — before the offer (Recruitment) and after offer acceptance (Onboarding). This article walks through every way the integration can be set up, and exactly when verification starts, what reports flow back, and what needs configuring.
In one line: Wherever the case begins, candidate details flow to SpringVerify automatically, verification runs, and the final report is delivered into the Verification Reports section of the onboarding form — where your team already works.
Recruitment and Onboarding are independent modules. Use either on its own, or both together for a full pre-offer-to-joining journey.
| Module | What it does | Best when |
|---|---|---|
| Module A — Recruitment only | DarwinBox acts as your ATS. A quick pre-BGV check runs before the offer letter is released, so you have a signal early. | You want a fast, early check during hiring and don’t run onboarding in DarwinBox. |
| Module B — Onboarding only | Candidates enter after they accept the offer. The full background verification runs before joining, with reports inside the onboarding form. | Verification belongs in onboarding and hiring happens outside DarwinBox. |
| Module A + B — Recruitment + Onboarding | A quick pre-offer check in Recruitment, then the same case carries seamlessly into Onboarding for the full verification — no re-entry, no duplicate. | You want both an early signal and the complete verification on record. |
Every path a candidate can take, from where the case starts to the final report. Follow whichever lane matches your setup — or both, when running Recruitment + Onboarding together.
The rules that differ between starting in Recruitment vs Onboarding — triggers, reports, and packages.
| Recruitment (Before the Offer) | Onboarding (After Offer Acceptance) | |
|---|---|---|
| Trigger | Instant notification created in DarwinBox, paired with a verification package | Your choice: form submission, candidate activation, or first form update |
| Fields sent | Only fields allowed by the package — package must include every field the verification needs | Candidate details + documents |
| Pre-BGV form | Optional. If enabled, must be completed before Pre-BGV is initiated. Pre-offer appears below Pre-BGV in DarwinBox by default but must still be done first. | — |
| Interim reports | Exactly one interim report, pushed once only — an early pre-offer signal | Pushed as each check completes |
| Final report | None — Recruitment gives an early pre-offer signal only | Delivered to the Verification Reports section of the onboarding form |
When Recruitment and Onboarding are connected, there are two ways to set up intake — and package selection differs between them.
Every candidate starts in Recruitment; Onboarding simply receives the continuing case.
You want candidate additions from Recruitment and directly from Onboarding.
The package defines which checks run and which candidate fields are collected. Where it’s chosen depends on where the case starts.
| How the candidate is added | Package in Recruitment | Package in Onboarding |
|---|---|---|
| Recruitment → Onboarding (Onboarding is passthrough only) | Real package — via a custom field at the recruitment step | Dummy package — only to open the onboarding form |
| Recruitment → Onboarding (also adding candidates from both sides) | Real package — via a custom field | Same real package, matched — e.g. Fresher in Recruitment → Fresher in Onboarding |
| Directly in Onboarding | — not used — | Real package — matched to your SpringVerify packages |
| Module | Interim updates | Final report |
|---|---|---|
| Recruitment | One interim report, pushed one time only — an early pre-offer signal | None |
| Onboarding | Pushed as each check completes | Delivered to the Verification Reports section of the onboarding form |
A one-time setup, usually completed in a single session with your DarwinBox account team. This applies to both Recruitment and Onboarding unless noted.
Recruitment runs on an instant notification, so the webhook must be configured in DarwinBox with two things: the webhook endpoint and an API key for authentication. SpringVerify can provide both — or you can find them yourself in the Integrations section of the SpringVerify portal.
SpringVerify × DarwinBox integration overview · Exact configuration — modules, verification start point, packages, and reports — is agreed during onboarding and can be tailored to your workflow.