Presentation plan, data inventory and open questions for the screening provider.
No screening provider is connected until the settings below are complete. Until then the five verification checks are recorded by a reviewer, not returned by an API. Nothing on this page is a confirmed provider requirement — items stay open until the provider answers in writing.
Every request detail comes from the provider documentation — nothing here is assumed.
The API key and the webhook secret live only in app secrets. Webhook URL for the provider dashboard:/functions/checkerWebhook?token=…
Two-minute path through the onboarding and compliance flow. Every link opens the real screen.
Four stages: personal details, documents, authorization, review. The applicant never sees the internal verification model.
Use fictional data only. Documents go to private storage, and consent is recorded with its text version.
The driver sees the five verification points and what is still pending. No internal reviewer notes are exposed.
Operator side. Seed applications already sit in different states so the queue is never empty on stage.
Open documents with time-limited links, mark each check as verified or failed, and leave a reviewer note.
Request more information, approve or reject. Approval creates the driver profile, and every action is timestamped.
Keep the demo honest: the five verification checks are simulated. Real screening starts only after the Checker sandbox is validated.
What the application collects today, and what still has to be added for a screening provider.
Full name, email, phone, home address, city, state, ZIP
Number, issuing state, expiration date, years of experience
Make, model, year, plate, vehicle type
License, insurance and registration files, stored privately with signed links
Consent flag, timestamp and text version captured at submission
Optional partner company the applicant drives for
Per-check status: identity, license, background, vehicle, insurance
Order/report IDs and raw result payloads returned by the provider
Re-checks and continuous monitoring events after approval
Which screening products are available for our account?
Identity, driver license/MVR, criminal background, vehicle and insurance — which are in scope.
Which states and countries does coverage include?
Driver and criminal checks may not cover every operating area we serve.
What turnaround should we expect per check?
Standard versus expedited, and whether checks run in parallel.
Do you support continuous monitoring after approval?
Ongoing monitoring for active drivers versus one-time pre-hire checks.
Do you provide the disclosure and authorization text, or do we supply our own?
The wording the applicant signs before screening is legally sensitive.
Who handles a dispute or adverse action end to end?
We need our obligations clear if an applicant contests a result.
Is a separate consent required for ongoing monitoring?
Our current consent covers a single screening at application time.
Do you require a signed agreement before sandbox access?
This decides whether tomorrow's meeting can unlock test credentials.
Which document formats and size limits do you accept?
We store license, insurance and registration as private uploads today.
Do applicants upload documents to your portal or to ours?
The flow we show tomorrow assumes everything stays inside our app.
Which applicant fields are mandatory for a check?
We already capture name, address, license number, state and expiration.
How do you handle non-US licenses or applicants without a US address?
Some partner drivers may hold foreign documents.
Is there a REST API, and how is it authenticated?
API key per account, OAuth, or both — we build against whichever you support.
Do you publish an API reference or OpenAPI spec?
We need it to map requests onto our application model.
Which identifiers come back so we can match a result to our record?
We need a stable external reference stored on the application.
Are there rate limits or quotas we should design around?
Bulk submissions during partner onboarding.
Is there a sandbox with test applicants and simulated outcomes?
We cannot test pass and fail paths with real people.
How do we trigger pass, fail, flag and additional-information outcomes in sandbox?
Those are the four states our reviewer flow already displays.
How long does sandbox provisioning take after contract?
It sets the earliest date for a live demonstration.
Do you push results to us, or do we poll for status?
Our compliance screen expects near real-time updates.
Which result statuses do you return, and which is terminal?
We map them onto the five checks already shown in the app.
How are callbacks secured and retried?
Signature verification, source allowlist and retry behaviour.
What is the retry and backoff policy for failed checks?
Some failures are permanent (bad data), others are temporary.
How are errors surfaced, and what is the support escalation path?
Error codes, messages and an SLA for stuck checks.
Can a check be re-run without creating a new applicant?
Re-checks after an expired document or a dispute.
How long do you retain documents and results?
It drives the retention policy we still owe legal.
Can we request deletion for an applicant, and in what timeframe?
Deletion requests must be honoured across both systems.
Which security certifications do you hold, and where is data stored?
SOC 2 or ISO 27001 and data residency matter to our partners.
Ordered by what unblocks what. Nothing here is a confirmed provider requirement.
Which screening products we buy, for which states and countries.
Blocks everything elseEndpoints, authentication, test applicants and simulated outcomes.
Needed to write codeLegal review of the consent the applicant signs before screening.
Blocks first real checkHow long files and results are kept, and how deletion is handled.
Blocks first real documentMap provider results to the five checks already shown in the app.
After credentialsPass, fail, flag and additional-information paths, including retries.
Before go-liveDemonstration environment · Fictional applicant data only