Most actions against the backend require you to be logged in as a user
with the appropriate permissions. By sending a request like:
POST /users/admin/login?password=login
your authentication request will be validated, and a session token
will be returned in the JSON response for your request. To remain
authenticated, provide this token with subsequent requests in the
X-ArchivesSpace-Session header. For example:
Since not all backend/API end points require authentication, it is best to restrict access to port 8089 to only IP addresses you trust. Your firewall should be used to specify a range of IP addresses that are allowed to call your ArchivesSpace API endpoint. This is commonly called whitelisting or allowlisting.
The ArchivesSpace API provides CRUD-style interactions for a number of
different “top-level” record types. Working with records follows a
fairly standard pattern:
# Get a paginated list of accessions from repository '123'
GET /repositories/123/accessions?page=1
# Create a new accession, returning the ID of the new record
POST /repositories/123/accessions
{... a JSON document satisfying JSONModel(:accession) here ...}
# Get a single accession (returned as a JSONModel(:accession) instance) using the ID returned by the previous request
GET /repositories/123/accessions/456
# Update an existing accession
POST /repositories/123/accessions/456
{... a JSON document satisfying JSONModel(:accession) here ...}
The :resolve parameter is a way to tell ArchivesSpace to attach the full object to these refs; it is passed in as an
array of keys to “prefetch” in the returned JSON. The object is included in the ref under a _resolved key.
For example, to find an archival object by a ref_id and return the found archival object, you can attach
resolve[]: "archival_objects" within your request.
Endpoints that represent groups of objects, rather than single objects, tend to be paginated. Paginated endpoints are called out in the documentation as special, with some version of the following content appearing:
This endpoint is paginated. :page, :id_set, or :all_ids is required
Integer page – The page set to be returned
Integer page_size – The size of the set to be returned ( Optional. default set in AppConfig )
Comma separated list id_set – A list of ids to request resolved objects ( Must be smaller than default page_size )
Boolean all_ids – Return a list of all object ids
These endpoints support some or all of the following:
paged access to objects (via :page)
listing all matching ids (via :all_ids)
fetching specific known objects via their database ids (via :id_set)
When working with search results using page and page_size parameters, many results can be returned and managing those
results can be difficult. See the Python example below for demonstrating how to take a large result set and iterating
through it to search for archival objects from a paginated result.
A number of routes in the ArchivesSpace API are designed to search for content across all or part of the records in the
application. These routes make use of Solr, a component bundled with ArchivesSpace and used to provide full text search
over records.
The search routes present in the application as of this time are:
Search this archive
Search across repositories
Search this repository
Search across subjects
Search for top containers
Search across location profiles
Search routes take quite a few different parameters, most of which correspond directly to Solr query parameters. The
most important parameter to understand is q, which is the query sent to Solr. This query is made in Lucene query
syntax. The relevant docs are in the Solr Ref Guide’s The Standard Query Parser webpage.
To limit a search to records of a particular type or set of types, you can use the ‘type’ parameter. This is only
relevant for search endpoints that aren’t limited to specific types. Note that type is expected to be a list of types,
even if there is only one type you care about.
ArchivesSpace represents records as JSONModel Objects - this is what you get from and send to the system.
SOLR takes these records, and stores “documents” BASED ON these JSONModel objects in a searchable index.
Search routes query these documents, NOT the records themselves as stored in the database and represented by JSONModel.
JSONModel objects and SOLR documents are similar in some ways:
Both SOLR documents and JSONModel Objects are expressed in JSON
In general, documents will always contain some subset of the JSONModel object they represent
But they also differ in quite a few important ways:
SOLR documents don’t necessarily have all fields from a JSONModel object
SOLR documents do not automatically contain nested JSONModel Objects
SOLR documents can have fields defined that are arbitrary “search representations” of fields in associated records,
or combinations of fields in a record
SOLR documents don’t have a jsonmodel_type field - the jsonmodel_type of the record is stored as primary_type in SOLR
How do I get the actual JSONModel from a search document?
In ArchivesSpace, SOLR documents all have a field json, which contains the JSONModel Object the document represents as
a string. You can use a JSON library to parse this string from the field, for example the json library in Python.
For updating existing records, it’s recommended to first do a GET request for the record you want to update. This
ensures that the data you are updating is the most accurate and reduces the chance of inadvertently removing data that
was there previously but may be lost if the data is not included in the subsequent update. After getting the original
record data, you can update it as needed and then do a POST request with the updated data. Make sure that the updated
data is JSON formatted and is passed either through the -d or --data parameter or json parameter if using
ArchivesSnake.
When creating new records, it’s recommended to do a GET request on the type of record you are wanting to create. This
example record is useful for seeing what fields are included for that specific record. Not all fields are required, for
example, the created and modified fields are not necessary when creating a new record, since those fields are
handled automatically. Others, such as title and jsonmodel_type are required.
After examining an existing record for reference, craft your JSON-formatted data and make a POST request. Make sure
that the new record is passed either through the -d or --data parameter or json parameter if using ArchivesSnake.
Delete requests using the API permanently deletes any record, just like within the staff interface. Be careful! Make
sure you want to delete the entire record before doing so. If you want to delete parts of a record, for example some
notes or other fields, see [Updating existing records](####Updating existing records).
To delete a record, retrieve the record’s ArchivesSpace generated ID and use the DELETE command for SHELL or
client.deleteif using the ArchivesSnake Python library.