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.

Illustration of a library system exchanging data with apps, users and services through one shared interface

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.

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.

  • Illustration of an API described as code in a window, connected to the services that use it

    Provider API

    v0.6.7 · 22 groups · 59 operations · 420 schemas

    The library system's own interface — patrons, loans, reservations, payment and holdings. Implemented by the library system, called by the services.

  • Illustration of layered code windows: a surface built on top of a shared specification

    Vendor API

    v0.6.7 · 3 groups · 4 operations · 153 schemas

    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.

The principle

PLAS standardises access — not the systems

The sources stay different. What becomes the same is the way in.

No library has to change systems to benefit from the standard. PLAS sits on top of what the library already runs and makes access to data and functionality consistent across it.

  • The specification

    REST and JSON with a machine-readable description

    Bibliofil, Cicero or Koha can each keep their own technical foundation underneath — while the service on top meets the same interface. The reference here is generated from the OpenAPI files, version by version, so a library can name one specific version in a tender.

  • The domains

    The library's domains, one at a time

    Search, bibliographic data, holdings, patron data, circulation, interlibrary loan, digital media, events and shared services such as identity, single sign-on and payment. The standard can grow gradually to cover them all — the features show what is supported today.

  • Getting started

    Open documentation from the first call

    Base URL, authentication and the first call — everything you need before calling a library system. Every version is open with its OpenAPI file, and the standard is developed on the basis of needs and input from libraries and vendors.

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.

A developer in profile at a large screen in an open-plan office, with a colleague at work in the background

The vision

One open digital ecosystem for libraries

The aim isn't to decide which systems libraries use, but to make it possible to connect them. PLAS should be built by the sector, for the sector — and proposals are welcome.