OAI-PMH and IIIF for Aggregators
Alongside the human-facing Public Portal, Archivers.ai exposes open, machine-readable interfaces 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.
Visitors who need them find them in the portal footer, under For developers. The Reuse this data page lists every address, in three families — a plain JSON API, OAI-PMH, and IIIF — with a sentence about each, a real sample response, and the rate limit that applies.
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.
Two metadata formats are offered:
oai_dc— simple Dublin Core.oai_qdc— qualified Dublin Core, which additionally carriesdcterms:provenance.
Limit: 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.
The shared feed, and opting out
The platform-wide endpoint is a feed shared by every archive on Archivers.ai, so a service that gathers catalogues from many archives can collect yours along with the rest. Settings → Public Portal → General → Status carries the toggle — Include our published records in the shared archive feed. Switch it off and harvesters can still collect your records, but only from your own per-organisation feed.
Registering with an aggregator
You don't have to work these addresses out. Settings → Public Portal → General has a section titled Registering with Archives Hub and other services, with a copy button beside each of the details an aggregator asks for:
- Feed address — your own OAI base URL
- Record identifiers start with — the OAI identifier prefix
- Set name — your organisation's set spec, and the pattern for the per-collection sets
- Image viewer address (IIIF) — your IIIF collection URL
They appear once you've set your portal's web address under Subdomain.
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.
The JSON read API
For an integrator who wants neither OAI-PMH nor IIIF, the portal also serves plain JSON under /api/public/<your-slug>/:
| Address | What it returns |
|---|---|
/api/public/<slug> | A summary of the portal |
/api/public/<slug>/funds | Every published collection |
/api/public/<slug>/funds/<id> | One collection |
/api/public/<slug>/accessions/<id> | One accession |
/api/public/<slug>/items/<id> | One item |
/api/public/<slug>/dossiers | Every published exhibit |
/api/public/<slug>/dossiers/<id> | One exhibit |
/api/public/<slug>/search?q=… | A search across published records |
Search is rate-limited; the Reuse this data page on your own portal prints the current number, so it's the address to send an integrator to rather than this page.
What to tell an integrator
- "Harvest us over OAI-PMH; we expose Dublin Core (
oai_dc) and qualified Dublin Core (oai_qdc), not EAD." - "There's a plain JSON API too, and a Reuse this data page on the portal that lists every address."
- "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.