List interface types
const url = 'https://api.aerandil.com/v1/interface-types';const options = {method: 'GET', headers: {Authorization: 'Bearer <token>'}};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url https://api.aerandil.com/v1/interface-types \ --header 'Authorization: Bearer <token>'Schema-discovery surface for the registry’s interfaces — the structural contracts object types implement, each with the properties every implementer must expose and the implementers themselves. An implementer whose local property is named differently carries an explicit interface→local mapping; identity mappings are omitted rather than repeated. Sorted by api_name ascending. Returns next_page_token: null in v1 — ontology size stays under the pagination threshold.
Authorizations
Section titled “Authorizations”Responses
Section titled “Responses”Sorted summary list of every registered interface type.
object
object
object
Interface→local property renames. Absent when every name matches: identity entries are omitted, not echoed back.
object
Properties every implementer must expose. An enum requirement matches structurally — the vocabulary itself stays per-implementer.
object
object
object
object
object
object
object
object
object
object
object
object
object
object
Allowed string values for the enum.
object
object
object
object
Api_name of the referenced object type.
Opaque cursor for the next page (AIP-158). Reserved for future growth; v1 returns null because the registry size is bounded.
Example
{ "data": [ { "required_properties": [ { "data_type": { "kind": "bool" } } ] } ]}The bearer authenticated but does not hold the scope this operation requires.
Structured error wrapper. Every non-2xx response from any Aerandil endpoint serialises to this shape; the HTTP status carries the failure class (4xx/5xx), the body adds a stable code for programmatic dispatch plus a human-readable message.
object
object
Stable, programmatic error code (e.g. unauthorized, forbidden, not_found, invalid_body, invalid_url, precondition_failed, no_secondary_key). Clients dispatch on code, not on the message (which may be localised or contextualised in future versions).
Request-id correlation handle echoed on the request-id response header — support teams correlate without scraping logs.
Human-readable explanation of the failure.
Per-error structured detail. The shape varies by code (e.g. forbidden_action carries {"action": "..."}; precondition_failed carries {"current_version": N}).
Examplegenerated
{ "error": { "code": "example", "instance_id": "example", "message": "example", "parameters": "example" }}