Integrations & API
Push a candidate in. Get status events back. No re-keying.
Pre-built connectors cover the ATS and HRIS platforms most Indian HR teams already run. Everything they can do, the REST API can also do directly — the same events, the same payload shapes, for the stack we have not built a connector for yet.
- 8pre-built connectors
- 6webhook event types
A live feed of webhook events: case created, check started, check completed, discrepancy raised, and report ready.
Every screening product wants to be its own portal.
A recruiter working from Keka or Lever shouldn't need a second login, a second status page, and a second place candidates ask where their check has got to. The integration layer exists so background verification behaves like a feature of the systems your team already runs, not a separate app someone has to remember to check.
Nothing here talks to anything else. The recruiter is the integration.
The same five checks, none of them a destination the recruiter has to visit.
- A recruiter re-enters the candidate's details a second time, by hand, in a separate portal.
- Status lives behind a login only ops sees — someone has to open the dashboard and report back.
- A closed case doesn't move the ATS stage forward on its own; someone does that by hand too.
- The candidate record already in your ATS or HRIS opens the case — no re-entry.
- Status events land as webhooks; your own dashboard shows progress without a second login.
- A signed report syncs back and can advance the candidate's stage automatically.
Pre-built connectors for your HRIS and ATS.
Our native integrations cover the platforms Indian HR teams run.
Event: case.status_updatedCandidate reaches the offer stage in Keka; Papertrail opens a case against the employee record Keka already holds.
{
"webhook_event": "case.status_updated",
"case_id": "PT-24917",
"candidate_id": "CND-88213",
"keka_employee_id": "EMP-4471",
"check_status": "in_progress",
"checks_completed": 2,
"checks_total": 6,
"updated_at": "2026-08-20T09:14:02+05:30"
}Every feature, available programmatically.
The exact same endpoints our own frontend and connectors use.
| Method | Path | Purpose |
|---|---|---|
POST | /v1/candidates | Create or update a candidate record |
POST | /v1/cases | Open a case against an existing candidate |
GET | /v1/cases/:id | Retrieve a case's current status and check results |
GET | /v1/checks/:id | Retrieve a single check's verdict and evidence references |
POST | /v1/webhooks | Register a webhook endpoint and select which events it receives |
DELETE | /v1/webhooks/:id | Remove a webhook endpoint |
GET | /v1/reports/:caseId | Download the signed report — PDF and structured JSON |
Try a call
Pick an endpoint to see the shape of what it actually returns.
Create or update a candidate record
{
"candidate_id": "CND-88220",
"name": "Neha Kulkarni",
"email": "[email protected]",
"status": "created",
"created_at": "2026-08-20T07:58:11+05:30"
}Event-driven updates, no polling required.
Subscribe your services to real-time status updates.
The first event in a case's life. Carries the checks requested and your own external reference if you supplied one, so you never have to look up the mapping later.
Fires once per check in the package, at the moment that specific check starts — a database lookup and a registrar-dependent check in the same case start (and fire this event) at very different times.
Includes the verdict — clear, flag, or review — for that one check. A case with six requested checks emits this event up to six times before it closes.
Carries the field, the declared value and the verified value. Corroborating detail — like an exit reason gaining a qualifier — is not treated as a discrepancy and does not fire this event.
The report URL in the payload is a signed, expiring link, not a permanent one — fetch it or forward it promptly, and re-request through the API if it has already expired.
This is the only event your own action controls — Papertrail never closes a case on your behalf. Everything before it is generated by the verification process itself.
Integrations, answered
A pre-built connector — Keka, DarwinBox, Zoho People, Lever, Workday, BambooHR or SAP SuccessFactors — is typically live within a day, mostly spent on field mapping. A direct REST API integration depends on your own onboarding service, but the API surface itself is small enough that most engineering teams have a working case-creation call within an afternoon.
Delivery is retried with backoff for 24 hours. If your endpoint is still unreachable after that, the event stays queryable through the API — nothing is dropped, and a case's full event history is always available on request even if a webhook delivery failed.
Yes. The REST API and the webhook events behind it are the same ones every connector uses internally, so anything a connector does, a direct integration can do too — this is the option for a stack we have not built a connector for.
Yes. Every webhook request carries a signature header computed from your endpoint's shared secret, so your receiving service can verify a payload actually came from Papertrail before acting on it.
Yes. A sandbox API key issues fictional candidates and check results on the same event schedule as production, so you can build and test a full integration — including discrepancy handling — before a single real candidate is submitted.
Build it with us
Bring your stack — we will map the fields.
Whether it is one of the eight connectors above or a direct API integration, our team joins the first call to plan the field mapping and event handling together.