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 (SSO) 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.1d Register and login user via OIDC [preferred]
These SSO flows are no longer used for new integrations, and are included only for reference.
1.1a Register and login user (Partner exposes Account API) [legacy]
1.1b Register and login user (Partner does not expose API) [legacy]
1.1c Preregister user (without SSO) [legacy]
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.