Vendor API v0.6.7
- Implemented by
- The service — the vendor's own backend
- Called by
- The library system, when something has happened or a login needs completing
The other three APIs describe what a service can call on the library system. The Vendor API describes what the system sends to the service — which is why the service implements it instead of calling it.
It has four operations. The library system sends events to
POST /events/receiver, so the service doesn’t have to ask again and again. It
sends the patron’s browser back to the service’s callbacks after a single
sign-on login or a registration (GET /callbacks/patron) and after a deletion
(GET /callbacks/patron/delete). And GET /version is there as in the other
APIs.
How to integrate
- Register the receiver. The service registers its address and a secret
with
Registerin the Provider API. The secret must be at least 16 characters and should be randomly generated.Event Receiver - Check the sender. The event receiver is secured with that secret
(
Eventin the specification). The receiver respondsReceiver Secret Auth 204. - Receive the patron. After a login, the patron is sent back with
codeandstate— orerrorif it didn’t succeed. The flow is in Get started.
How it relates to the other APIs
The Vendor API is an entry point alongside the Provider API, not a subset
of it: only GET /version is in both. They are the two directions of the same
collaboration — a service that both fetches and receives calls the Provider API
and implements the Vendor API.
Shared across operations
These definitions are shared by the API’s operations. They are documented once here; an operation lists only what is specific to it, plus the codes it can return.
Authentication
EventReceiverSecretAuth · apiKey
Parameters
-
versionThe version of Open Library the vendor expects to receive, if this version isn't supported by the provider an error code 600 (Unsupported Open Library API version) is returned.
Error responses
-
HttpCode400The list of errors. -
HttpCode401SecretSecret is invalid.