English
English Norsk Dansk
English Norsk Dansk

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 model

One layer between source and products

The source implements the Provider API and exposes its data, and the products call that same interface. When the source needs telling, it goes the other way through the Vendor API.

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.

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

    Provider API

    v0.6.5 · 22 groups · 54 operations · 379 schemas

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

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

    Vendor API

    v0.6.5 · 3 groups · 3 operations · 152 schemas

    The surface the product itself exposes, so the library system can send events and complete patron sign-in. Implemented by the vendor, called by the system.

    Open Vendor API

The principle

PLAS standardises access — not the systems

Read the principles

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 application 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

    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. Each area is described on its own, with its own operations and responses, and a library system implements them when it makes sense.

  • Getting started

    Open documentation and a transparent process

    Base URL, authentication and the first call — everything you need before calling a library system. The standard begins with the most important shared functionality and 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.

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.

Get started Contact us about PLAS