Skip to content

REST API

Audit the registry against storage

GET/v1alpha1/admin/registry/auditregistry.audit

Reads the registry and remote storage, comparing the two without changing either.

Unregistered generations in storage indicate interrupted rollouts, or deleted indexes and generations whose storage waits for the sweep that removes it; those carry removedAt. Registered generations missing from storage have no data available to pull.

Served by whichever node receives the request and never forwarded. Answers only in object storage mode.

Responses

200
Comparison of the shared registry with remote storage.
RegistryAuditResponse

The registry compared with what remote storage holds. Reported by the engine and never accepted as input. See Audit.

registryRegistry
The state of the registry object: present, absent (no registry object), or corrupt (contents cannot be parsed).
Values
"present", "absent", "corrupt"
indexesAuditedIndex[]
Every index named by the registry or found in storage, ordered by name.
Example
{
"name": "products",
"registered": true,
"live": "2",
"generations": [
{
"name": "1",
"registered": true,
"stored": "synced"
},
{
"name": "2",
"registered": true,
"stored": "synced"
}
]
}
6 properties
namestring
Name of the index.
Example
"products"
registeredboolean
A boolean indicating whether the registry has an entry for the index.
livestring
The generation the index answers for. Omitted when unregistered or when no generation is live.
Example
"2"
proposedLivestring
The generation that a repair with promoteNewest would make live. Omitted when none would be promoted, which includes a deleted index.
Example
"1"
removedAtstring
When the index was deleted, as an ISO 8601 timestamp. Present while the storage of the deleted index waits for the sweep that removes it; a repair registers such an index only when asked to restore it. Omitted otherwise.
Example
"2026-09-03T10:15:00Z"
generationsAuditedGeneration[]
A list of generations found for the index, ordered by name.
Example
{
"name": "1",
"registered": true,
"stored": "synced"
}
4 properties
namestring
The name of the generation.
Example
"1"
registeredboolean
A boolean indicating whether the registry names the generation.
storedStored
What storage holds under it. synced: storage holds a manifest; nodes can pull and serve this generation. incomplete: storage holds a prefix without a manifest (such as an unfinished push or what an interrupted removal left of a deleted generation). missing: the generation is registered, but nothing exists in storage.
Values
"synced", "incomplete", "missing"
removedAtstring
When the generation was deleted on its own, as an ISO 8601 timestamp. Present while its storage waits for the sweep that removes it. A generation of a deleted index carries the index's removedAt instead. Omitted otherwise.
Example
"2026-09-03T10:15:00Z"
unusablestring[]
Storage prefixes whose names no index or generation may carry (as index or index/generation). A repair never registers these prefixes.
401
The request carries no credential this node accepts. Absent, malformed, unknown and lapsed keys are all answered alike, so a refusal cannot be used to find out which keys exist. The response carries WWW-Authenticate: Bearer.
ErrorResponse

The body of every failed request. Error codes use colon-separated namespaces such as index:field:name_invalid, are stable across API versions, and are never renamed or reused, so clients match on code rather than on message. See Errors.

codestring
Identifies the failure type. For validation failures, this is validation and the individual problems are listed in errors. For all other failures, this matches the code of the single entry in errors.
Example
"validation"
messagestring
Human-readable message for log output. Match on code rather than on message. When a validation failure contains one problem, this is that problem's message. When it contains several, it reads Request contains N errors.
Example
"Request contains 2 errors"
All problems found in the request. A validation failure reports every field with a problem, so a caller can fix them in one pass rather than one request at a time.
Example
{
"code": "index:field:primary_key:multiple_unsupported",
"message": "Field `id` is marked as a primary key and multiple, primary keys can not have multiple values",
"path": "id"
}
4 properties
codestring
The error code identifying this specific problem.
Example
"index:field:primary_key:multiple_unsupported"
messagestring
Human-readable description of this problem.
Example
"Field `id` is marked as a primary key and multiple, primary keys can not have multiple values"
pathstring
Location of the offending value in the request, such as fields.title or documents[1].nonexistent. Names join with ., one element of a list reads [n] counted from zero, and a key of a free-form map such as metadata goes in brackets and double quotes when it holds a dot or a bracket, as metadata["build.sha"]. A field inside an object field carries its own dotted path, so a path here reaches a field the same way a query does. Omitted when the problem applies to the request as a whole. See API conventions.
Example
"id"
argumentsmap of string
The values the message was rendered with, so a client can render a message of its own from the code.
1 property
<key>string
Error codes
auth:unauthenticated
The request carries no credential this node accepts.
403
The API key does not have the registry.audit permission.
ErrorResponse

The body of every failed request. Error codes use colon-separated namespaces such as index:field:name_invalid, are stable across API versions, and are never renamed or reused, so clients match on code rather than on message. See Errors.

codestring
Identifies the failure type. For validation failures, this is validation and the individual problems are listed in errors. For all other failures, this matches the code of the single entry in errors.
Example
"validation"
messagestring
Human-readable message for log output. Match on code rather than on message. When a validation failure contains one problem, this is that problem's message. When it contains several, it reads Request contains N errors.
Example
"Request contains 2 errors"
All problems found in the request. A validation failure reports every field with a problem, so a caller can fix them in one pass rather than one request at a time.
Example
{
"code": "index:field:primary_key:multiple_unsupported",
"message": "Field `id` is marked as a primary key and multiple, primary keys can not have multiple values",
"path": "id"
}
4 properties
codestring
The error code identifying this specific problem.
Example
"index:field:primary_key:multiple_unsupported"
messagestring
Human-readable description of this problem.
Example
"Field `id` is marked as a primary key and multiple, primary keys can not have multiple values"
pathstring
Location of the offending value in the request, such as fields.title or documents[1].nonexistent. Names join with ., one element of a list reads [n] counted from zero, and a key of a free-form map such as metadata goes in brackets and double quotes when it holds a dot or a bracket, as metadata["build.sha"]. A field inside an object field carries its own dotted path, so a path here reaches a field the same way a query does. Omitted when the problem applies to the request as a whole. See API conventions.
Example
"id"
argumentsmap of string
The values the message was rendered with, so a client can render a message of its own from the code.
1 property
<key>string
Error codes
auth:forbidden
The key is accepted but does not hold the `registry.audit` permission.
409
The endpoint was called on a node configured with local storage rather than shared storage.
ErrorResponse

The body of every failed request. Error codes use colon-separated namespaces such as index:field:name_invalid, are stable across API versions, and are never renamed or reused, so clients match on code rather than on message. See Errors.

codestring
Identifies the failure type. For validation failures, this is validation and the individual problems are listed in errors. For all other failures, this matches the code of the single entry in errors.
Example
"validation"
messagestring
Human-readable message for log output. Match on code rather than on message. When a validation failure contains one problem, this is that problem's message. When it contains several, it reads Request contains N errors.
Example
"Request contains 2 errors"
All problems found in the request. A validation failure reports every field with a problem, so a caller can fix them in one pass rather than one request at a time.
Example
{
"code": "index:field:primary_key:multiple_unsupported",
"message": "Field `id` is marked as a primary key and multiple, primary keys can not have multiple values",
"path": "id"
}
4 properties
codestring
The error code identifying this specific problem.
Example
"index:field:primary_key:multiple_unsupported"
messagestring
Human-readable description of this problem.
Example
"Field `id` is marked as a primary key and multiple, primary keys can not have multiple values"
pathstring
Location of the offending value in the request, such as fields.title or documents[1].nonexistent. Names join with ., one element of a list reads [n] counted from zero, and a key of a free-form map such as metadata goes in brackets and double quotes when it holds a dot or a bracket, as metadata["build.sha"]. A field inside an object field carries its own dotted path, so a path here reaches a field the same way a query does. Omitted when the problem applies to the request as a whole. See API conventions.
Example
"id"
argumentsmap of string
The values the message was rendered with, so a client can render a message of its own from the code.
1 property
<key>string
Error codes
index:registry:audit_unavailable
The node stores indexes on local disk, where there is no shared registry to audit.

Authorization

Permission
registry.audit
Checked on
The deployment, not one index
Roles
admin

An API key sent as a bearer token, such as Authorization: Bearer exok_4ff6b760264c1918_ePQcdT1O9HSATZoXfDbT8hhHGsP9VpZH. A key carries grants that pair permissions with index patterns; the permission each endpoint needs is named beside it. Nodes running with EXOFIND_AUTH_MODE=none accept requests without a credential, and a node with EXOFIND_AUTH_ANONYMOUS_KEY set serves requests that carry none with the permissions of that key.

Exofind is built by Level Four AB and is available under the Apache License 2.0.