Overview
What ParkOnce Is
ParkOnce is an aggregation layer for parking payments. We connect drivers to multiple parking providers through
a single mobile interface — users scan a QR code or enter a zone number, choose a duration, and pay from one app.
We handle the user identity, payment collection, and session lifecycle; your API handles enforcement authorization.
The integration model is simple: ParkOnce calls your session API on behalf of the user. You receive properly
authorized session start/stop calls exactly as if the user opened your own app. We never store payment credentials
on your end — we own the user payment relationship and forward session authorization to you.
Our role
User acquisition + payment
Your role
Session enforcement + authorization
Technical Architecture
How It Works End-to-End
The data flow from user action to enforcement authorization:
┌────────────────────────────────────────────────────────────────┐
│ REQUEST FLOW │
└────────────────────────────────────────────────────────────────┘
User App
│ Scan QR / enter zone → choose duration → confirm payment
▼
ParkOnce Middleware (parkonce.ca)
│ • Validates user identity + payment method
│ • Fetches zone/lot metadata from provider config
│ • Calculates cost, applies 2.5% service fee
│ • On payment confirm → calls Provider API
▼
Provider REST API (e.g., api.passportinc.com/parking/v2)
│ POST /sessions { zone_number, license_plate, duration }
│ ← returns { session_id, start_time, end_time, status }
│ POST /sessions/:id/stop (on early end)
│ GET /sessions/:id (on status check)
▼
Enforcement
│ Session ID valid in your system → officer LPR check passes
└─ Receipt emailed to driver by ParkOnce + your system
Your API receives standard OAuth2-authenticated REST calls. No webhook setup required from your side —
we poll session status and handle expiry logic locally.
Integration Requirements
What We Need to Connect
-
1
Authentication — OAuth2 Client Credentials or API Key
We support OAuth2 client_credentials grant (preferred) or a static bearer/API key. We cache tokens and refresh automatically.
-
2
REST Endpoints for Session Lifecycle
We need endpoints to start a session, optionally extend it, stop it early, and check its status. Exact field names vary by provider — we adapt to your schema.
-
3
Zone / Lot Identifiers
A mapping of your zone numbers or lot IDs to geographic coordinates so we can surface locations in our app. A CSV export or static API endpoint works fine.
-
4
Sandbox / Test Environment
We build against sandbox first. We need sandbox credentials and a test zone/lot ID that accepts sessions without real enforcement.
Session API — Minimum Required Endpoints
| Method |
Endpoint (pattern) |
Purpose |
| POST |
/sessions |
Start a new parking session (zone + plate + duration) |
| GET |
/sessions/:id |
Retrieve session status & details |
| POST |
/sessions/:id/stop |
End session early (user-initiated) |
| POST |
/sessions/:id/extend |
Extend active session duration (nice to have) |
| GET |
/rights?license_plate=X |
Check active sessions for a vehicle (nice to have) |
Authentication Pattern (OAuth2)
This is how we authenticate against providers using the OAuth2 client credentials flow:
// 1. Exchange credentials for bearer token
POST https://auth.{provider}.com/oauth/token
Content-Type: application/json
{
"grant_type":
"client_credentials",
"client_id":
"<your_client_id>",
"client_secret":
"<your_client_secret>"
}
// 2. Use token in all API calls (auto-refresh before expiry)
POST https://api.{provider}.com/parking/v2/sessions
Authorization: Bearer <access_token>
Content-Type: application/json
{
"zone_number":
"1234",
"license_plate":
"ABC1234",
"duration": 60,
"receipt_email":
"driver@example.com"
}
If you use API keys instead of OAuth2, we support both Authorization: Bearer <key> and X-Api-Key header patterns.
Integration Status
Live & In Pipeline
We're actively building out the provider network. Current status:
Sandbox integration live — OAuth2 + full session lifecycle. Production credentials pending.
Data API live — lot discovery, real-time pricing & occupancy for 5+ downtown locations.
In outreach — integration adapter built, awaiting sandbox credentials.
In outreach — integration adapter built, awaiting sandbox credentials.
Next Steps
What We Need From You
To start the integration, we need three things:
-
1
Sandbox credentials
Client ID + secret (OAuth2) or API key for your test environment. These stay in our encrypted secrets vault, never logged or exposed.
-
2
API documentation
Developer docs or Postman collection for your parking session API. A PDF, URL, or shared portal access — whatever format you have.
-
3
A test zone or lot ID
One sandbox location we can use to run end-to-end tests without triggering real enforcement events.
Integration Timeline
1
Day 1–2 — Sandbox setup
We receive your credentials + docs. Auth flow validated, test session created end-to-end.
2
Day 3–5 — Full lifecycle integration
Session start, extend, stop, status endpoints integrated. Locations seeded to our app. QA pass.
3
Day 6–10 — Staging validation
Real-device testing with sandbox. Edge cases handled (timeout, fallback, error states). Deployed to staging.
✓
Week 2 — Production switch
Swap sandbox credentials for production. Soft launch with limited locations. Full launch after soak period.
Ready to Connect?
Send us your sandbox credentials and API docs and we'll have a working integration in your test environment within 5 business days.
Integration timeline
1–2 weeks from sandbox access
Current providers live
Passport Labs · INRIX/ParkMe