Without any integration with a partner, a user registers by providing a unique bike plan code to identify their employer and the specific plan to which they have access. The email address of the user is used as an identifier for the user. This implies that for each email address there can only be one account.
This technique is always possible, but—in case of an integration with a partner—we can also offer a Single Sign-On experience to the user. Depending on what can be implemented on the side of the partner, this can happen in various degrees going from just pre-registering the users to providing a link that will login a user (and possibly create an account if it does not yet exist).
1.1a Register and login user (Partner exposes Account API)
1.1b Register and login user (Partner does not expose API)
1.1c Preregister user (without SSO)
Once a user has an account, they can start requesting a bike. During this process we offer many hooks where a partner can be notified of the progress as well as perform certain actions. Note that these are not webhooks in the strict sense, these are moments in our process where we can call an external API, but each of these calls is—at the moment—a custom implementation. Therefore, we can easily tie into any already existing API: we just need to map the journeys of an order both system to each other.
If the typical type of two-way API communication is not possible, there is also (less preferred) the option for the partner to periodically poll our system.
We do however prefer the first approach as — in our experience — this two-way communication gives less overhead, less manual intervention, and provides a much smoother experience for the user. Nevertheless, the set of calls to poll our system can be useful to set up a data check system.