Provider API v0.6.5

The Provider API is the main surface of PLAS. Once a library system implements it, any product that speaks PLAS can work with that library without knowing the system underneath — and a product built against one library works at the next.

It covers what a library does every day: the patron and her consents, loans and renewals, reservations, fees and payment, holdings and locations, checkout and checkin, search across works and publications, and the events the library publishes. Each part has its own group in the menu.

How to integrate

Three things have to be in place, listed in the order you meet them:

1. The base URL. The specification has no servers block, so the address belongs to the provider and is agreed with them. Do not assume it is the same from library to library, even with the same provider.
2. A token. POST /authentication/oauth2/token with client_id, client_secret and grant_type=client_credentials returns a Bearer token, which every other call carries.
3. The version. Send version as a query parameter on each call. If the provider does not support it you get error code 600 — an error you can act on, rather than a response that merely looks right.

The one call that needs neither a token nor an agreement is GET /version. Start there: if it answers, the base URL is right. The whole path, with examples, is in Get started.

How it relates to the other APIs

The Search API and the Content API are profiles of this surface: every one of their operations is here too, with the same operationId, method and path. They exist so a system can implement one area on its own — search, or events — without implementing the whole Provider API. If you implement Provider, you already have both.

The Vendor Consumer API is the opposite direction: the surface your own product exposes, so the library system can send something to you.