PLAS API · Public Library API Specification
Library data behind one shared standard
Digital library services should be built across systems and data sources — without every service building and maintaining integrations of its own.
The model
From fragmented integrations to one shared layer
Without a shared standard, every connection needs its own integration. With PLAS, the source implements the Provider API once, and every service calls the same interface.
App
Web
Info screen
Service X
Service Y
Service Z
PLAS — shared API standard
The Provider API side
The source exposes
The Vendor API side
The source consumes
Implementing the Provider API
Builds an API per the Provider API specification
Integrating with the Vendor API
Builds an integration per the Vendor API specification
Source X — e.g. a library system
The reference
Two entry points, one shared specification
The Provider API is what the library system exposes. The Vendor API is the other direction — what the service exposes back. Search and Content are profiles of Provider that can be implemented on their own.
-
Provider API
The library system's own interface — patrons, loans, reservations, payment and holdings. Implemented by the library system, called by the services.
-
Vendor API
The surface the service itself exposes, so the library system can send events and complete single sign-on. Implemented by the service, called by the system.
Who does what
Libraries
Can contribute needs, use cases and requirements for the services.
System vendors
Can implement the specification and help shape it.
Data providers
Can make their data and services available through the standard.
Developers
Can build new services on top and propose improvements.
What the standard gives you
One standard, six concrete gains
Library systems, metadata, search, digital media, events, identity and payment often each have their own integration interface. PLAS brings access together behind one shared standard — and that changes everyday work for libraries and vendors alike.