English

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, patrons and services through one shared 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 product exposes back. Search and Content are profiles of Provider that can be implemented on their own.

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.

  • Illustration of an API described as code in a window, connected to the services that use 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 application on top meets the same interface.

    • Machine-readable

      The reference here is generated straight from the OpenAPI files — what you read is what the specification says.

    • Versioned

      A library can write one specific version into a tender, and the client sends it along on every call.

  • Illustration of a domain described in a document, connected to the data it gives access to

    The domains

    Eight areas, rolled out one at a time

    Search, bibliographic data, holdings, patron data, circulation, interlibrary loan, digital media, and shared services such as identity, single sign-on and payment.

    • Self-contained

      Two entry points and two profiles, each divided into groups with their own operations, parameters and responses.

    • At its own pace

      A library system implements the domains when it makes sense, and the version table shows what is in production.

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

    Getting started

    Open documentation and a transparent process

    PLAS begins with the most important shared functionality and grows from there — at the pace libraries need.

    • Freely available

      Base URL, authentication and the first call — everything you need before calling a library system.

    • Needs before roadmap

      The standard grows as libraries and vendors bring new needs, not to a schedule set in advance.

Who does what

  • Libraries

    Contribute needs and examples from everyday work.

  • System vendors

    Implement the specification and help shape it.

  • Data providers

    Make their data and services available through the standard.

  • Developers

    Build new services on top and propose improvements.

What the standard gives you

One standard, six concrete gains

Today, library systems, metadata, search, digital media, events, identity and payment each come with their own integration interface. PLAS brings that access together — and it changes daily 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

Join PLAS

A standard grows strong when many people use it

PLAS should be built by the sector, for the sector — not by a single vendor.

Among the libraries Redia works with today

Get started with PLAS

Redia proposes PLAS and maintains the documentation here — but the standard belongs to the sector. Start with the first call, or write to us if you want to help shape it.