Integrations & API
Your systems stay in place. We connect to them.
This page is written for IT and implementation teams. It describes how data moves between FastAssist24 and your environment, how access is protected, and which boundaries apply. No keys, no example tokens, no internal implementation details.
Exchange models
Three ways to exchange data
Which model fits depends on your environment. The three are not mutually exclusive — in practice they are often used side by side.
| Model | Direction | Typical use | Requirement on your side |
|---|---|---|---|
| REST API | your system → FastAssist24 | Create interventions, register vehicles, check coverage and retrieve the state of a case. | Your system can make outbound HTTPS calls and pass a key in the authorisation header. |
| Webhooks | FastAssist24 → your system | Receive state changes of a case without continuous polling. | You provide a reachable HTTPS endpoint that accepts and acknowledges the notification. |
| Structured import / export | both directions | Exchange vehicle lists, coverage configurations and intervention data in file form. | Suitable for environments without direct API access or with a fixed export window. |
The full endpoint reference and field specifications are provided during the technical intake. They are not published here.
Access and key management
Who may do what, and with which credential
API access is separate from portal access. Both are scoped per organisation.
- Key per organisation or partner
- Every B2B organisation and every partner works with its own key. A key never grants access to another organisation’s data.
- Hashed storage
- Keys are stored only as a SHA-256 hash. The key itself cannot be retrieved again after issuance.
- Revocable per key
- A key can be revoked individually without interrupting the other integrations.
- Tenant isolation
- Organisation data is strictly separated in a multi-tenant model. That boundary applies to the API as well as the portal.
- Role-based access
- Roles and permissions are separated for the platform, B2B organisations and providers.
- Audit log per case
- Every state change and action is traceable with a full timeline — regardless of whether it happened through the portal or the API.
Idempotency
A repeated call does not create a second case
Network errors, timeouts and retries are part of every integration. Writes are therefore idempotent: you pass your own reference on creation. If the same reference is presented again, you receive the existing case instead of a duplicate.
The same principle applies on the administrative side when cancellations and refunds are processed.
- call 1 · reference ORD-8841case created
- timeout on your sideno confirmation received
- call 2 · same reference ORD-8841the same case is returned
- resultone case, no duplicate intervention
State vocabulary
The states an intervention case moves through
This is the vocabulary your system receives back. It is identical to what your staff sees in the portal.
| State | What has happened |
|---|---|
| Pending | The request is registered and awaits assignment to a provider. |
| Accepted | A provider has accepted the job. The assignment is fixed. |
| Dispatched | The provider is on the way to the given location. |
| Arrived | The provider is on site with the vehicle. |
| Completed | The intervention is finished and the case can be processed administratively. |
| Cancelled | The case has been stopped. The reason is recorded in the case. |
System categories
What organisations connect in practice
The categories below occur most often. Every connection runs through one of the three exchange models above.
- Fleet systems
- ERP platforms
- Claims platforms
- Dispatch systems
- Partner APIs
- Accounting & invoicing
- Real-time events
- Import / Export
- Messaging systems
- Rental partners
- Payment providers
- Reporting & analytics
Integration boundaries
What we want to establish up front
- Whether a connection is feasible depends on your environment, access rights, data format and technical validation. That is assessed per project and not promised in advance.
- We publish no keys, no example tokens and no internal implementation details. Technical documentation goes through the intake.
- An integration is first tested in a bounded environment before it is connected to live cases.
- The accuracy and legal basis of the data your system supplies remain your responsibility. Processing arrangements are set contractually.
- What is on this page describes how the platform works today. We make no commitments here about future possibilities.
Implementation path
From intake to phased scale-up
- 01
Operational intake
We map your current intake, dispatch, tracking and reporting.
- 02
Configuration
Services, roles, providers and SLA rules tuned to your operation.
- 03
Controlled pilot
A scoped live environment; you measure dispatch, acceptance and SLA on your own interventions.
- 04
Phased scale-up
Expansion per region, fleet or service — with reporting and integration positioning.
Designed to connect to existing fleet, leasing, insurance and mobility processes. Belgian launch, designed for European scale.
Let us look at your environment.
In a technical intake we go through your systems, access rights and data formats, and determine which exchange model fits.
Operational demo · 30 minutes · no obligations