Skip to main content

OAI-PMH and IIIF for Aggregators

Alongside the human-facing Public Portal, Archivers.ai exposes two open, machine-readable standards for library and archive integrators — no account or API key needed, and no separate setting to turn on. Only what you've published to the Public Portal is exposed; nothing private, no blob URLs, no transcripts, no sensitivity data.


OAI-PMH 2.0

A standards-compliant OAI-PMH provider, useful for harvesting into aggregators such as Archives Hub.

  • Platform-wide endpoint: https://app.archivers.ai/oai
  • Per-organisation endpoint: https://app.archivers.ai/oai/<your-slug> — scopes harvesting to just your organisation, useful for aggregator registration under your own name

All six standard OAI-PMH verbs are supported (Identify, ListMetadataFormats, ListSets, ListIdentifiers, ListRecords, GetRecord), with proper OAI error responses and resumption tokens for paging through large harvests. Sets are available both per organisation and per fonds, so a harvester can pull just one collection if they want to.

Limit: the only supported metadata format is oai_dc (Dublin Core). EAD-over-OAI is not supported — if a harvester needs EAD, point them at your EAD3 finding-aid export instead, which is a genuine nested multilevel export, just not delivered through OAI-PMH.


IIIF Presentation API v3

Published images and their descriptive metadata are available as IIIF Presentation v3 manifests and collections, for use in any IIIF-compatible viewer (Mirador, Universal Viewer, and similar).

  • A collection of everything published for your organisation
  • A collection per fonds
  • A manifest per published item

served with correct content types, CORS headers, and caching, at /api/public/<your-slug>/iiif/... paths referencing your portal's own image-delivery URLs.

Limit: this is Presentation API v3 only — there is no IIIF Image API (no deep-zoom tiling service). Images are served through the app's own display-image proxies, which is fine for viewing but won't give a viewer pixel-level deep zoom the way a dedicated IIIF image server would.


What to tell an integrator

  • "Harvest us over OAI-PMH; we currently expose Dublin Core (oai_dc), not EAD."
  • "Our IIIF is Presentation v3 — manifests and collections, standard viewer-compatible — without an Image API tiling service behind it."
  • Only published, public content is ever exposed through either interface.

See also