This is a contributors guide and NOT a user guide. Please visit these docs if you are using or evaluating SuperTokens.
The core driver interface (CDI) is an interface that defines how the backend SDK communicates with the core service.
For example, when the backend's sign up API is called, it would need to create a new user in the core. So the create new user is exposed via the core and the API spec that defined it is called the core driver interface.
You can find the Open API spec here.
It has its own versioning system with the format
Xvalue is incremented when there is a breaking change to the API spec. Breaking changes are defined by if an existing API is changed without / removed.
- We increment the
Yvalue for most changes - these include non breaking changes like adding new APIs
Zvalue never really gets incremented, and can be ignored.
Each backend SDK and the core has a list of CDIs they are compatible with. For example, see this file. These values determine if a backend SDK and a core version can work together or not.
One exception is that the consumer of the CDI (that is the backend SDKs) may be compatible with a CDI version, but may not consume all of its APIs. For example, a backend SDK may only work with the session recipe and still be compatible with a CDI that has other recipes as well.
However, the same does not apply to the core service - for it, to be compatible with a CDI version, it needs to have implemented ALL the APIs that the CDI spec says. This is because it's the provider of the CDI APIs and not the consumer.