IOKI API
APIs and webhooks for integration into external systems
Our APIs are REST-based and use json as the carrier format. There is an Open API 3.0.2 specification for all our APIs and webhooks, which can be used by our integration partners to generate model frameworks with type checks and API wrappers for our endpoints within their tools.
The API and webhook documentation is generated from these open API specifications and made available to our partners as part of the ioki developer programme. The ioki developer programme also provides access to a shared bug tracker and plays a crucial role in communicating API changes. The documentation consists of the API Guide, Passenger API, Driver API, Platform API and Webhooks.
API Guide
The API guide contains the instructions for correct use
Passenger API
Enables the development of fully fledged DRT Passenger clients
Driver API
Platform API
Webhooks
Developer Program
Joining the ioki developer program is mandatory when integrating our APIs.
A prerequisite is an NDA with ioki: Depending on your relation to ioki, your key account manager, sales contact or engineering partner will be glad to guide you through this simple process. This NDA is also needed in case you are doing a requirements analysis or feasibility study and simply need to recheck the documentation with your team. As soon as the NDA is signed we will create accounts for you and your team members to access our developer GitLab instance.
Through this account you will have access to the most recent API documentation and the bug tracker. We are strict on this process as our APIs are not public and usually need some clarification upfront nevertheless as they are complex. Also: While access to the documentation and issue trackers might be the obvious part, there is more to the developer program and it will pay off by having streamlined processes.
Full list of benefits
- Access to all of our documentation and Open API definitions: API guidelines, Passenger API, Driver API, Platform API and Webhook documentation
- Access to a shared issue tracker for staying in the loop about questions, requests and bug reports
- Technical support: responsible for the corrospondency with your developer teams
- Provision of test environment customised to usecase
- Kickoff with a ioki-developer to provide valuable technical details
- During the integration, we will assist your development team with a weekly video check in from a ioki developer
API Guide
The ioki APIs share common design principles. Examples are: Which headers are needed, how does pagination work, how does the API expose errors and many more topics. Parts of this documentation may be relevant for most, but not necessarily all APIs, endpoints and usecases. Make sure to skim at least over the topics before starting the development.
Passenger API
The Passenger API is the interface that enables the development of fully fledged DRT Passenger clients in all flavors. Most basic clients may consist of a rather simple UI where a user can request a ride from A to B, is presented a basic result and can book or discard it. The API exposes much more, if you want to go full lengths. Booking now or in the future in different geographical boundaries, preflight service information, rating, payment, tipping, seeing the position of the approaching vehicle, station details, pedestrian information, live updates and time recalculations, past and future rides, receipts and much more. Everything we do – you can integrate with it.
Driver API
This API exposes all primitives to write a driver client. This might be a simple application listing addresses and times to drivers, but as with the passenger API you can go all in: We consume our own APIs and provide a reference client with a fully fledged turn by turn navigation system, passenger check in / check out functionality, assisting the drivers from the very moment they leave the depot until they return.
Platform API
While the Passenger and Driver APIs are consumed by clients running on mobile devices, the Platform API is our interface for full integration with foreign backends. We aim at feature parity with our standard product, and there is nearly no feature you can’t steer through these endpoints. You can create, modify or delete all kinds of resources, for instance create new stations, reconfigure your fleet, setup shifts and synchronize the usebases. Our DRT platform is designed to integrate with all kinds of data flows and usecases, it is possible to operate multiple products with multiple clients and even share userbases across different integration partners. For specific usecases, the platform API even allows issuing access tokens to the driver and passenger APIs, in case your backend needs to act on behalf of particular passengers or drivers.
Webhooks
Webhooks are a common way to get notified about events happening within a system. Our webhooks enable you to stay up to date with state changes and facilitate usecases as simple as reading single pieces of data along and as complex as triggering logic on your end which might then utilize the other APIs again. Webhooks can be set up manually, but also programmatically via the platform API. They can fire whenever something happens or they may get scoped to specific events. They are secured by being signed with a preshared secret. Undelivered webhooks will retry with an exponential backoff algorithm and it is possible to also refetch missed data via the platform API. The Webhook payload is not containing indefinitely nested data structures (the platform API can be used to fetch additional data if needed) but still: We send a fully fledged serialized representation of the object associated with the event along. So the data contained is usually sufficient for most usecases.
Our experts are happy to assist
Laura Reupke
Start shaping the future of mobility of your existing transport or develop new ideas together with our experts. We look forward to hearing from you.