Integration levels

KNOT station API can be integrated to a mobility system at different levels, depending on the time available and the desired features.

Comparison

	Minimal	Basic	Full integration
Unlock	✔	✔	✔
Lock	✔	✔	✔
Integrate with existing free-floating scooter	✔	✔	✔
Can work without free-floating (station only)	✘	✔	✔
Station displayed on the app	✘	✔	✔
RFID badge reader support	✘	✘	✔
Monitoring	KNOT Manager	KNOT Manager	Your own solution
Alert	KNOT Manager	KNOT Manager	Your own solution
Require changes on app	No	Yes	Yes
Estimated time to integrate (man-days)	2 to 5 days	5 to 25 days	25 days +

Minimal

If your mobility system includes an App and a Backend that manages free-floating scooter solutions, you can proceed with the quick integration.

1. You need to add on your scooter database 3 data sets: KNOT vehicle identifier, KNOT station identifier where scooters are locked and the spot number.
2. Then you need to adjust the unlocking process from your side : instead of just sending unlock to the scooter from your backend, you also need to send unlock to the station in which the scooter is locked.
3. Last step, you have to connect the locked event to mark the scooter locked in a station, stop the rental for the user and send 'locked' to the free-float scooter.

For your end users the UX remains the same, the minimal integration doesn't require any modifications on your app. Station won't be shown on the map, the end user will only see multiple scooters at the same place.

That’s basically what we need to start working together.

Basic

On this level you show KNOT stations on the map and allow users to find them easily. This level of integration requires more effort as you have to update your app. You also need to add an endpoint to get stations to your backend and add it to your database.

We recommend to create a table for stations with at least an internal id (auto increment, uuid, etc.), a display name (for the end users), a KNOT station identifier (to store the KNOT id of the station), a latitude and a longitude and two dates (creation date, deletion date). A second table or an array (depending on your database structure) can be used to store spots, with the following data: number (1 to 32), lock status (to store the state of the lock, open or close), and a contained vehicle. Last database change, as in "minimal integration" you need to put a KNOT vehicle identifier to your scooters table.

We also recommend you to create a table to track all unlock requests made by users (unlock id, time, user identifier). The unlock identifier should be an integer (up to 64 bits) and should be sent with the unlock request - it will allow you to easily retrieve which user unlocked a scooter, because we forward back this id in the unlocked event (when the scooter is out of the station).

For the unlock process, if you already have free floating scooters, you have to do the same actions described in the "minimal integration". Otherwise, you only have to send the unlock request to the KNOT Station API.

Once the backend and app has been adapted (don't show scooters that are on a station, use another pin to show the station and how much scooter is in, etc.), you have to implement an endpoint for the locked event to mark the scooter locked in a station, stop the user rent and send 'locked' to the free-float scooter. Except if you already have free-float scooter (and the logic to start a rent when it is unlocked), you should also implement an endpoint for the unlocked event to handle it.

Full integration

The full integration is the same as basic, + all other events not related with lock/unlock functions. The idea is to get a complete overview of station status as well: extreme temperature or vandalism events, power cut, rfid badge, etc). This will allow you to have full control of the KNOT station from your own dashboard / monitoring system.

Of course, you can also implement only the features you need.