The other direction — what the service itself exposes, so the library system can send events and send the patron back after a login.

2 groups · 2 operations · 2 paths · 152 schemas Generated from vendor_v0_6_3.yaml · OpenAPI 3.0.0 Download the OpenAPI file
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

  1. Register the receiver. The service registers its address and a secret with RegisterEventReceiver in the Provider API. The secret must be at least 16 characters and should be randomly generated.
  2. Check the sender. The event receiver is secured with that secret (EventReceiverSecretAuth in the specification). The receiver responds 204.
  3. Receive the patron. After a login, the patron is sent back with code and state — or error if 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

  • version In query · Version · optional · used by 1 of 2 The 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

  • HttpCode400 Errors · used by 1 of 2 The list of errors.
  • HttpCode401Secret No response body. · used by 1 of 2 Secret is invalid.