Provider API v0.6.3

The Provider API is the main entry point to PLAS. When a library system implements it, a service that speaks PLAS can work with the library without knowing the system underneath.

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

How to integrate

Three things need to be in place, 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 it. Don’t 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 is sent with the calls that follow. Only GetVersion, AuthenticateClient and RevokeToken work without one.
3. The version. The client can send the version it expects in the version query parameter. If the provider doesn’t support it, it responds with error code 600.

The way to the first call, with examples, is in Get started.

How it relates to the other APIs

The Search API and the Content API are profiles of the Provider API: each of their operations is also here, with the same operationId, method and path. They can be implemented on their own, so a system can offer search or events without the whole Provider API. If you implement the Provider API, you already have both.

The Vendor API runs the other way: it is what the service itself exposes, so the library system can send events and send the patron back after a login.