# About PLAS Last updated 21 October 2026 Source: https://plasapi.com/about-plas/ PLAS is a shared, open and vendor-neutral API specification for library data and functions. The aim is to move from fragmented integrations to library services that work together. ## Why PLAS exists A library's digital world is no longer just the library system. An app, a website, a staff tool or an AI service needs data and functions from many sources: holdings, patron data, metadata, e-books and audiobooks, events, identity and payment. Without a shared standard, access runs through a mix of SIP2, NCIP, local APIs, and vendor-specific integrations. SIP2 and NCIP were built for the needs of earlier generations and give access to only part of what modern services need. The result is many separate integrations, each with its own data model, higher development and running costs, more dependence on a single system, and a longer road from idea to new service. | | Without PLAS | With PLAS | |---|---|---| | Access | Part of what services need, through SIP2 and NCIP | One shared interface to the library's data and functions | | Integrations | One integration per connection, each with its own data model | Each party integrates once against the same specification | | Freedom of choice | The library system's integration options decide which services can be connected | Services that speak PLAS can be taken into use without a separate integration | | Tenders | Every library writes its own API requirements | A tender can refer to a specific PLAS version | | Development | Effort goes into integrations, and the road to a new service is long | Effort can go into the service rather than the integration | ## What PLAS is PLAS is the integration layer between the library's data sources and the services patrons and staff use. It brings access together behind one shared standard — not the data. The specification is REST and JSON, described in OpenAPI. Underneath PLAS, the data sources can be technically very different — Bibliofil, Cicero, Koha, a metadata repository or a digital content service, for example — while the service on top meets one shared, predictable interface. The standard can grow gradually to cover the library's core domains: search, bibliographic data, holdings, patron data, circulation, interlibrary loan, digital media, events and shared services such as identity, single sign-on, payment and library cards. ## What it can give A shared standard makes it possible to move effort from integration to the services people actually meet. **Libraries** can choose the services that best support their staff and patrons, without the choice being set by what the library system can integrate with. They can get better access to their own data and set requirements for the experience, not just the technical connection. **Vendors** can develop against one shared specification instead of one integration per library system: build once, integrate across, and reach more libraries. That means less integration work, more predictable product development and room to specialise. Library systems can implement one standard and help shape it, and the content of data and service providers can become part of the user's journey. **Patrons** can get one joined-up experience — one search, one overview, one account — whoever supplies the content, and wherever they meet the library. **Staff** can get tools that bring together what they need, so they don't have to switch between systems. And **developers** can put their effort into the experience rather than the integration. ## The principles Seven principles guide how the standard is developed — and what you can count on as a library, a vendor or a developer. 1. **Access is standardised — not the systems** — The data sources stay different; it is the way in to them that becomes the same. PLAS doesn't replace the library system or require today's protocols to be removed, so a library doesn't have to change systems to use PLAS. 2. **Machine-readable first** — The specification is described in OpenAPI, and the reference on this site is generated from the same files. Developers work from one precise description that the reference can't drift from. 3. **Versioning** — The standard is released in versions, and the published OpenAPI files [can be downloaded here](https://plasapi.com/apis/#spec-filer). A library can therefore set precise requirements in a tender — "must support PLAS version X.X", for example. 4. **Domain by domain** — The standard grows gradually, domain by domain and at its own pace, starting with the most important shared functions. 5. **Open documentation and an open process** — The specification is open here, and the process is meant to be just as open. Anyone can read what the standard requires before they decide. 6. **Needs before timeline** — The standard is developed on the basis of needs and input from libraries and vendors — not from a fixed timeline. 7. **The standard belongs to the sector — not one vendor** — PLAS isn't a vendor's product and isn't a decision about which systems libraries should use. The specification is open, and any system or service can build on it. ## What PLAS supports today Today the standard covers search, metadata, holdings, patrons, circulation, payment and single sign-on through an identity provider, and events in part. The features are grouped in three areas, and the numbers are derived from the feature list and the specification in production: [Search and discovery](https://plasapi.com/features/search-and-discovery/) (12 of 34 supported), [The patron](https://plasapi.com/features/patron/) (41 of 52 supported), and [Library and content](https://plasapi.com/features/library-and-content/) (2 of 13 supported). The direction is to extend the standard with digital media, full event coverage, logistics, personalisation, AI and services no one has imagined yet — in step with libraries' needs. ## Vision and purpose > One open digital ecosystem for libraries. The aim isn't to decide which systems libraries should use. The aim is to make it possible to connect them — so the library's data and functions become available in a consistent, modern way, and better digital services can be developed faster, at lower cost and across systems. ## Take part in PLAS A standard grows strong when many develop and use it. Libraries and public organisations can bring needs, use cases and requirements for the digital services of the future — and write PLAS into tenders. Library system vendors can implement the Provider API and help shape the specification. Data and service providers can make data and functions available through PLAS, so their services are easier to combine with the rest of the library's ecosystem. Developers can use the specification, propose improvements and build new services on top. And organisations and partners are invited to take part in its strategic development. PLAS is meant as an open industry initiative with open, shared governance, where libraries and vendors define the standard together. That is the direction; the formal model isn't in place yet. **Needs, proposals and questions:** Write to [contact@plasapi.com](mailto:contact@plasapi.com) — from a library, from a vendor or as a developer. ## Next steps - [Get started](https://plasapi.com/get-started/) — Find your role, and make the first call. - [See the features](https://plasapi.com/features/) — What PLAS supports today — and what is not there yet. - [See the four APIs](https://plasapi.com/apis/) — How they fit together, and the spec files. - [Read the changelog](https://plasapi.com/changelog/) — What came in each release.