Certn — Integration Setup

CMDash reads screening status only. It never reads the report, the records in it, or the result. See What CMDash deliberately does not read below — that section is the most important one on this page.

Certn is the non-US half of the background-screening pack. Checkr is US-centric; Certn is the common choice for Canadian, UK and international screening. A distributed workforce often means both, and connecting both is supported — each reports its own population.

Prerequisites

• A Certn account with API access enabled
• Permission to create an API key
• CMDash Essentials tier or above

Step 1: Create an API key

1. Sign in to the Certn dashboard.
2. Go to Settings → API (ask your Certn account manager if the section is not visible — API access is enabled per account).
3. Create a key and copy it. It is shown once.

Step 2: Connect in CMDash

1. Navigate to Integrations in your CMDash dashboard.
2. Find Certn and click Connect.
3. Enter your API key.
4. Click Save & Test Connection.

Certn uses Authorization: Api-Key <key>, not Bearer. CMDash sends the correct scheme; you paste the key only. It is called out here because a wrong scheme returns a 401 that looks exactly like a bad key, which is a bad afternoon if you go hunting for the wrong problem.

What Syncs

What CMDash deliberately does not read

CMDash calls the applications list and nothing else. It never requests per-application detail, which is where the report lives. The following never leave Certn, even where Certn returns them inline on the applicant object:

• The report and every record in it — criminal record checks, identity verification contents, credit reports, education and employment verification
• The result — every terminal state that means "the screening came back" is stored as completed, whatever it came back with, and the distinction is discarded at ingestion
• National identifiers — SIN, SSN, tax ids
• Date of birth, home address, personal phone

Why the result is dropped. The control being evidenced is SOC 2 CC1.4: background screening is performed on personnel per policy. That is answered by "a check was run for this person and it finished, on this date". What the check found answers a different question — one belonging to your HR process, inside Certn, under the adverse-action procedures of the jurisdictions you hire in. Putting it in a compliance dashboard your account admins can read, to evidence a control that never asked for it, is not a trade CMDash makes on your behalf.

This is not a filter applied after storage. The distinction is discarded in the adapter, before anything is written — never received, rather than received and hidden.

How the numbers are computed

• Screening coverage is completed checks over checks still in flight or done. Canceled and expired applications are excluded from both sides — a withdrawn request is not an incomplete screening.
• Stale pending count is applications outstanding for more than 30 days, and it is the number to act on. A request that went out and never came back is the realistic CC1.4 failure, and a coverage percentage counts it as merely not-yet-done, forever.
• An application the candidate has not submitted is pending, not canceled. An invitation nobody has acted on is outstanding work, and it ages into the stale count accordingly.
• action_required and waiting_on_applicant map to suspended — the screening is paused on someone else, which is a different situation from one sitting in a queue.

Controls this evidences

CMDash seeds a suggested mapping for SOC 2 CC1.4 (stalePendingCount == 0), keyed on a count of zero rather than a coverage percentage: one screening stuck for two months is a real finding, and a 95%-coverage threshold would pass an organisation with exactly that gap.

Pair this with an HRIS integration (BambooHR, Rippling, Gusto, Workday). The roster says who works here, Certn says who was screened, and the gap between them is what an auditor samples.

Troubleshooting

• 401 Unauthorized: the key is wrong or revoked. If you are testing the API by hand, check you sent Authorization: Api-Key <key> — Bearer returns the same 401.
• 403 Forbidden: API access is not enabled on the account. Contact your Certn account manager.
• Applications appear but applicant email is blank: the application was created without an applicant email, so it cannot be joined to your roster. It still counts toward screening coverage.
• Application count is lower than Certn shows: the 5,000-application ceiling truncated the walk. Check the sync log for the warning.

Rate Limits & Sync Behavior

Credential Rotation

1. In Certn: Settings → API → create a new key.
2. In CMDash: Settings → Integrations → Certn → Edit, enter the new key, Save.
3. Confirm a successful sync, then revoke the old key.

Known Limitations

• No result or risk signal. Certn's result and risk fields are not read. That is an HR decision with a legal process around it, and it is not CC1.4 evidence.
• No per-application detail. You cannot drill from CMDash into what a check covered beyond the package name. Follow the application into Certn for that.
• The 5,000-record ceiling is a truncation, not a sample. Larger accounts are cut off and the sync log carries a warning.
• Continuous monitoring is not a separate signal. Ongoing checks surface as further applications.
• No write-back. CMDash never orders a screening, never cancels one, and never sends applicant data to Certn.