Integration Patterns
Choose how your application and Izix share users, rights, reservations and gate access.
Most partner integrations combine two layers:
- Provisioning: your system is the source of truth for users. It creates, updates and removes profiles in Izix and decides which access rights they hold.
- End-user experience: how your users book a spot and open the gate. Either Izix renders the experience inside your app (embedded web app with SSO), or you build it yourself on the API (native integration).
In both cases the parking hardware (ANPR cameras, controllers, barriers) is operated or integrated by Izix. Your end user application never talks to the hardware directly.
flowchart LR
HR["Your back office"] -- "1. Provisioning" --> API["Izix Public API"]
APP["Your end-user app"] -- "2a. Native integration" --> API
APP -- "2b. Embedded web app" --> WEB["Izix web app"]
WEB -. "SSO" .-> IDP["Your identity provider"]
API --> GATE["Izix gate hardware"]
WEB --> GATE
Pattern overview
| Provisioning | Embedded web app with SSO | Native integration | |
|---|---|---|---|
| Who builds the end-user UI | n/a | Izix | You |
| Authentication of the end user | n/a | Your identity provider, via SSO | Your own app session |
| API credentials | Client credentials | None for the UI layer | Client credentials |
| Typical effort | Low | Low | Medium to high |
| Feature coverage | Users and rights | Full Izix end-user feature set, updated by Izix | What you implement |
| Guide | Profile provisioning | Embedding the Izix web app with SSO | Native end-user integration |
How to choose
Embedded web app with SSO fits when you want parking available in your app quickly, with the full Izix end-user feature set (booking, gate opening, plates) and no UI to maintain. Your app opens the Izix web app in a webview, and the user is signed in through your identity provider.
Native integration fits when parking must look and behave like the rest of your app, or when your customer asks for an API-only setup. You call the Public API for availability, reservations and gate opening, and render everything yourself.
The two can coexist: provisioning is identical in both patterns, and the choice of end-user experience can be made per customer.
If your product is an access control or parking management system that should use Izix as a validation layer at the gate, see Acting as Third Party Access Control instead.
What the gate hardware does
When Izix hardware equips the parking, the gate decision is always taken by Izix:
- Local recognition (ANPR, QR etc): the reader reads the plate, qr etc. Izix checks it against the informations stored on the profile and the profile's access rights and reservations, then opens the barrier. No action is needed from your app.
- Remote opening: the user taps "open" in the embedded web app or in your native app, which calls the Izix API. Izix checks the rights, and the user's position when geofencing is enabled on the gate, then sends the command to the controller.
Plates are therefore part of provisioning: a profile without a registered plate can only enter through remote opening or other configured credentials (code, QR).
Updated 7 days ago