canonical: https://jentic.com/apis/aucklandmuseum.com/aucklandmuseum

# Auckland Museum API

Jentic publishes the only available OpenAPI specification for Auckland Museum API, keeping it validated and agent-ready. The Auckland Museum API exposes the museum's Collections Online and Cenotaph databases, including the Pacific and New Zealand collections, library and archive material, and a record of every New Zealand service person held in the Cenotaph database. Data is queryable through simple keyword search, complex Elasticsearch-style queries, a SPARQL endpoint over the linked-data graph, and direct media retrieval. The API is a public research resource designed for cultural-heritage projects, education, and applications that surface Aotearoa New Zealand's collections.

## For AI agents

Search Auckland Museum's Collections Online and Cenotaph records, fetch detailed subject nodes, and retrieve associated media via REST or SPARQL.

## Scope

Does not handle ticket sales, event bookings, or membership management - use for Auckland Museum collections, Cenotaph records, media, and linked-data queries only.

## Capabilities

- Run a keyword search across collections via GET /search/{index}/{operation}
- Submit complex queries with POST /search/{index}/{operation} for filtered, facet-driven retrieval
- Fetch a full subject record by identifier via GET /id/{identifier}
- Retrieve images and other media tied to a record through GET /id/media/{path}
- Query the linked-data graph using GET or POST /sparql for federated research
- Combine Cenotaph and Collections indexes to build cross-domain heritage queries

## Use cases

### Education and research portals

Universities, schools, and heritage projects build research portals over Auckland Museum's collections without re-hosting the data. GET /search runs keyword retrieval across collections and Cenotaph indexes, GET /id/{identifier} pulls the full record, and GET /id/media/{path} returns the associated image or document. The combination is enough to build a class-facing or public-facing collection browser tied directly to live museum data.

Example prompt: Search the collections index for the keyword 'pou' via GET /search/collectionsonline/_search, then for the first three hits call GET /id/{identifier} and return the title, maker, and date for each.

### Family-history Cenotaph lookup

The Cenotaph database records New Zealand service people from the South African War onward. Family historians want to look up a relative by name or service number and retrieve the full record with photographs and narratives. POST /search/cenotaph/_search supports the complex query needed to combine surname, service number, and conflict, and GET /id/{identifier} returns the canonical record once a match is found.

Example prompt: POST to /search/cenotaph/_search with a query for surname='Smith' and conflict='World War 1', then return the top five results with their identifier, full name, and service number.

### Linked-data integration with cultural-heritage graphs

The /sparql endpoint exposes the museum's collections as RDF, which lets researchers federate queries with other GLAM (galleries, libraries, archives, museums) endpoints such as Europeana or DigitalNZ. A SPARQL agent can union resources across multiple collection graphs and build a single citation list for a research paper, with all subject identifiers traceable back to Auckland Museum URIs.

Example prompt: POST a SPARQL query to /sparql that returns the rdf:label and dcterms:creator for every subject linked to the concept 'waka', limited to 25 results.

### AI agent integration via Jentic

An education or heritage agent can use Jentic to call the Auckland Museum API without hardcoding endpoint paths. The agent searches an intent like 'search Auckland Museum collections', Jentic returns the matching operation and its input schema, and the call is executed against api.aucklandmuseum.com. Because the API is open, no credential is required, but Jentic still standardises the call format so the agent can compose this with other museum APIs in the same workflow.

Example prompt: Use Jentic search 'search Auckland Museum collections', load the schema for GET /search/{index}/{operation}, and execute it for index='collectionsonline' with the query 'kowhai'.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /search/{index}/{operation} | Run a simple search across an index |
| POST | /search/{index}/{operation} | Run a complex query with filters and facets |
| GET | /id/{identifier} | Retrieve a full subject record by identifier |
| GET | /id/media/{path} | Retrieve media (images, documents) tied to a record |
| GET | /sparql | Run a SPARQL query against the linked-data graph |
| POST | /sparql | Submit a SPARQL query body for complex linked-data retrieval |

## Key resources

- **Search** — Simple and complex search across the collectionsonline and cenotaph indexes
- **Subject** — Full record retrieval by identifier across collections and Cenotaph
- **Media** — Direct retrieval of images and other binary assets attached to a record
- **SPARQL** — Linked-data endpoint over the museum's RDF graph for federated queries

## Why Jentic

- **Setup:** Wiring the Auckland Museum API by hand means resolving its host and choosing between its search, id, media, and SPARQL paths, even though there is no credential to manage. Through Jentic you install once, import the Auckland Museum API from the API Directory, and your agent calls it with no key to configure.
- **Permission scoping:** The Auckland Museum API takes the index, operation, identifier, and query through path segments and request bodies for read-only lookups, so limit the agent to the operations it needs, such as searching collections or running a SPARQL query. You choose the operations it may call, and all exposed operations are reads.
- **Credential handling:** The Auckland Museum API is public, so there is no credential to store. Jentic still routes the call through your own Jentic One instance at execution time so museum lookups compose with credentialed APIs in the same workflow.
- **Discovery method:** Agents search Jentic by intent such as 'search Auckland Museum collections', and Jentic returns the matching operation with its input schema so the agent picks /search, /id, /id/media, or /sparql without browsing the reference docs.

## Related APIs

- **Harvard Art Museums API** — Another open museum collections API with a similar object/media retrieval pattern.
- **Art Institute of Chicago API** — Open collections API covering the Art Institute of Chicago's holdings.
- **Dropbox API** — Dropbox stores the high-resolution media downloaded from museum endpoints for downstream use.

## FAQ

### Why is there no official OpenAPI spec for Auckland Museum API?

Auckland Museum publishes API documentation at api.aucklandmuseum.com/apidoc but does not distribute a downloadable OpenAPI file. Jentic generates and maintains this spec so that AI agents and developers can call Auckland Museum API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Auckland Museum API use?

The Auckland Museum API is publicly accessible and does not require an API key for the search, id, media, or sparql endpoints in this spec. When called through Jentic the agent still goes through the standard search/load/execute flow so the call shape is consistent with credentialed APIs in the same workflow.

### Can I search both Collections Online and Cenotaph through the Auckland Museum API?

Yes. The /search/{index}/{operation} endpoint takes the index name as a path parameter, so you can target collectionsonline for collection objects or cenotaph for service-person records. POST supports a richer query body for filtering and faceting.

### What are the rate limits for the Auckland Museum API?

The Auckland Museum API does not publish a documented rate limit in the spec. The service is shared and free, so heavy or scripted use should be paced and ideally cached. SPARQL queries are subject to a server-side query timeout.

### How do I retrieve a museum object's image through Jentic?

Run jentic search 'get media for an Auckland Museum record', load the schema for GET /id/media/{path}, and execute it with the path returned in a prior /id/{identifier} response. With pip install jentic an agent can fetch the image binary in one async call.

### Is the Auckland Museum API free to use?

Yes. The API is offered as a public research resource. Bulk and commercial use should be discussed with Auckland Museum, but standard search and retrieval calls are free and unauthenticated.

### Can I limit what my agent is allowed to do with the Auckland Museum API?

Yes. Because you run Jentic One yourself, your own rules decide which of the Auckland Museum API operations the agent may call, and every exposed operation is read-only. You can restrict it to just the calls the workflow needs, such as searching the collectionsonline or cenotaph index, fetching a full record by identifier, retrieving media, or running a SPARQL query, and withhold the rest. Since the API is public there is no credential to hand over, so scoping comes down to the operations you allow.