Urban Hub — Product Preview • Demonstration Environment
Urban Control

Checker Integration

Presentation plan, data inventory and open questions for the screening provider.

Compliance Center
Planning stage

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.

Live in appDemo dataTo confirm

Connection & environment

Every request detail comes from the provider documentation — nothing here is assumed.

0/6 ready
Provider answers in writing
0/28 questions answered
Endpoint and request mapping
Base URL, create path and request template
API key stored as a secret
Test the connection after saving the key
Result mapping
Where the outcome lives, and how it maps to our states
Consent and retention defined
Consent text version and retention window
Go-live confirmed
Required before production checks

The API key and the webhook secret live only in app secrets. Webhook URL for the provider dashboard:/functions/checkerWebhook?token=…

Presentation runbook

Two-minute path through the onboarding and compliance flow. Every link opens the real screen.

1
Open the driver application

Four stages: personal details, documents, authorization, review. The applicant never sees the internal verification model.

Open form
2
Submit a sample applicant

Use fictional data only. Documents go to private storage, and consent is recorded with its text version.

Fill & submit
3
Show the applicant status

The driver sees the five verification points and what is still pending. No internal reviewer notes are exposed.

View status
4
Switch to Compliance Center

Operator side. Seed applications already sit in different states so the queue is never empty on stage.

Open center
5
Review one candidate

Open documents with time-limited links, mark each check as verified or failed, and leave a reviewer note.

Review
6
Decide

Request more information, approve or reject. Approval creates the driver profile, and every action is timestamped.

Decide

Keep the demo honest: the five verification checks are simulated. Real screening starts only after the Checker sandbox is validated.

Data we already hold

What the application collects today, and what still has to be added for a screening provider.

Applicant identity

Full name, email, phone, home address, city, state, ZIP

Live in app
Driver license

Number, issuing state, expiration date, years of experience

Live in app
Vehicle

Make, model, year, plate, vehicle type

Live in app
Documents

License, insurance and registration files, stored privately with signed links

Live in app
Consent

Consent flag, timestamp and text version captured at submission

Live in app
Partner affiliation

Optional partner company the applicant drives for

Live in app
Verification outcomes

Per-check status: identity, license, background, vehicle, insurance

Demo data
Provider identifiers

Order/report IDs and raw result payloads returned by the provider

To confirm
Monitoring history

Re-checks and continuous monitoring events after approval

To confirm

Questions for the Checker

28 total28 unresolved0 answered0 blocked

Verification scope

0/4
P1

Which screening products are available for our account?

Identity, driver license/MVR, criminal background, vehicle and insurance — which are in scope.

P1

Which states and countries does coverage include?

Driver and criminal checks may not cover every operating area we serve.

P2

What turnaround should we expect per check?

Standard versus expedited, and whether checks run in parallel.

P2

Do you support continuous monitoring after approval?

Ongoing monitoring for active drivers versus one-time pre-hire checks.

Consent & compliance

0/4
P1

Do you provide the disclosure and authorization text, or do we supply our own?

The wording the applicant signs before screening is legally sensitive.

P1

Who handles a dispute or adverse action end to end?

We need our obligations clear if an applicant contests a result.

P2

Is a separate consent required for ongoing monitoring?

Our current consent covers a single screening at application time.

P1

Do you require a signed agreement before sandbox access?

This decides whether tomorrow's meeting can unlock test credentials.

Documents & applicant data

0/4
P1

Which document formats and size limits do you accept?

We store license, insurance and registration as private uploads today.

P1

Do applicants upload documents to your portal or to ours?

The flow we show tomorrow assumes everything stays inside our app.

P1

Which applicant fields are mandatory for a check?

We already capture name, address, license number, state and expiration.

P2

How do you handle non-US licenses or applicants without a US address?

Some partner drivers may hold foreign documents.

API & authentication

0/4
P1

Is there a REST API, and how is it authenticated?

API key per account, OAuth, or both — we build against whichever you support.

P1

Do you publish an API reference or OpenAPI spec?

We need it to map requests onto our application model.

P1

Which identifiers come back so we can match a result to our record?

We need a stable external reference stored on the application.

P2

Are there rate limits or quotas we should design around?

Bulk submissions during partner onboarding.

Sandbox & testing

0/3
P1

Is there a sandbox with test applicants and simulated outcomes?

We cannot test pass and fail paths with real people.

P1

How do we trigger pass, fail, flag and additional-information outcomes in sandbox?

Those are the four states our reviewer flow already displays.

P2

How long does sandbox provisioning take after contract?

It sets the earliest date for a live demonstration.

Results & webhooks

0/3
P1

Do you push results to us, or do we poll for status?

Our compliance screen expects near real-time updates.

P1

Which result statuses do you return, and which is terminal?

We map them onto the five checks already shown in the app.

P1

How are callbacks secured and retried?

Signature verification, source allowlist and retry behaviour.

Failures & operations

0/3
P2

What is the retry and backoff policy for failed checks?

Some failures are permanent (bad data), others are temporary.

P2

How are errors surfaced, and what is the support escalation path?

Error codes, messages and an SLA for stuck checks.

P2

Can a check be re-run without creating a new applicant?

Re-checks after an expired document or a dispute.

Retention & security

0/3
P1

How long do you retain documents and results?

It drives the retention policy we still owe legal.

P1

Can we request deletion for an applicant, and in what timeframe?

Deletion requests must be honoured across both systems.

P1

Which security certifications do you hold, and where is data stored?

SOC 2 or ISO 27001 and data residency matter to our partners.

Next steps

Ordered by what unblocks what. Nothing here is a confirmed provider requirement.

  1. 1
    Service agreement and product scope

    Which screening products we buy, for which states and countries.

    Blocks everything else
  2. 2
    API documentation and sandbox credentials

    Endpoints, authentication, test applicants and simulated outcomes.

    Needed to write code
  3. 3
    Disclosure and authorization text

    Legal review of the consent the applicant signs before screening.

    Blocks first real check
  4. 4
    Document retention and deletion policy

    How long files and results are kept, and how deletion is handled.

    Blocks first real document
  5. 5
    Sandbox adapter and webhook receiver

    Map provider results to the five checks already shown in the app.

    After credentials
  6. 6
    Validate every outcome in sandbox

    Pass, fail, flag and additional-information paths, including retries.

    Before go-live

Demonstration environment · Fictional applicant data only