HTTP API

Each inndx service exposes an HTTP API. The authoritative, always-current reference is served by the running application itself; this page summarizes how the endpoints are grouped per service so you know where to look.

The live API reference

Every running service serves an interactive API reference at /.well-known/docs and the raw OpenAPI schema at /.well-known/openapi.json. Because these are generated from the running code, they are the source of truth for exact request and response shapes, including every field and status code. Use this page to understand how endpoints are grouped, and the live reference for the precise details of any endpoint.

All endpoints are served under the /v1 path prefix on the service's configured host and port (the default port is 8022).

Multi-tenancy

The API supports multiple tenants, where each tenant's jobs, runs, and recorded data are kept separate. A request selects its tenant with the X-Tenant-Id header:

curl 'http://localhost:8022/v1/jobs' \
  -H 'X-Tenant-Id: acme'

When the header is omitted, the request uses the deployment's default tenant (configured by meta.default_tenant_id, which defaults to default). Multi-tenancy is available only if your license permits it; without that entitlement, requests operate within the single default tenant.

Orchestrator API

The orchestrator owns crawl configuration and state.

• Jobs (/v1/jobs): create, read, update, and delete crawl jobs.
• Runs (/v1/runs, /v1/jobs/{id}/runs): create and inspect runs, and control a run's lifecycle with pause, resume, and stop.
• Triggers (/v1/triggers, /v1/jobs/{id}/triggers): manage job triggers, enable and disable them, and list their executions.
• Crawl graph (/v1/hosts, /v1/links, /v1/runs/{id}/links, /v1/runs/{id}/edges): read the hosts and URLs the crawl has seen, the link edges between them, and the labels attached to hosts and URLs.
• Artifacts (/v1/artifacts): read stored artifacts and their content.

Fetcher API

The fetcher retrieves content.

• Fetch (/v1/fetch, /v1/fetch/batch): fetch one URL or a batch on demand, useful for testing a client against a URL.
• Browser session (/v1/sessions/ws): a WebSocket endpoint for browser-based sessions.

Parser API

The parser turns content into results and manages extraction configuration.

• Data schemas (/v1/schemas): manage data schemas and validate records against them.
• Data maps (/v1/data_maps, /v1/hosts/{hostHash}/data_maps): manage stored per-host data maps and apply a map to supplied content.
• URL patterns (/v1/patterns, /v1/hosts/{hostHash}/patterns): manage host URL patterns and test a URL against them.
• Parse (/v1/parse, /v1/parse/batch): run a pipeline against supplied content to test extraction.

Analytics API

The analytics service exposes recorded run and configuration history.

• Audit logs (/v1/audit_logs): query the history of configuration changes.
• Crawl logs (/v1/runs/{id}/logs): query each URL's passage through the pipeline for a run.
• Metrics and latency (/v1/runs/{id}/metrics, /v1/runs/{id}/latency): query aggregated counts and step latency series for a run.

Authentication and access

The services do not provide built-in authentication. In a deployment, place the API behind your own network controls, such as a private network and an authenticating gateway, and expose only what each consumer needs. The supported approach for exposing and securing the API in a production deployment is covered in your enterprise onboarding materials.