REST API

Journey exposes a REST API for resource access alongside its GraphQL endpoint. URLs follow a versioned structure under /api/v1, and all requests and responses use JSON over HTTPS. The REST surface is intentionally narrow — single-resource lookups, mutations, and proxy passthroughs — while list-style queries live on the GraphQL schema. See graphql.

Endpoint reference: the complete, generated list of REST endpoints lives in rest_reference.md.

URL structure

Every REST URL is composed of the host, the global prefix /api, the version segment v1/, and a resource path. For example:

https://journey-server-prod.us-east-1.core.inseng.io/api/v1/programs

The global /api prefix and the v1/ version segment are applied consistently across all REST endpoints.

Verbs

Journey follows standard REST verb conventions:

• GET — read a resource

• POST — create a resource or invoke a non-idempotent action

• PUT — replace a resource

• PATCH — partially update a resource

• DELETE — remove a resource

Content types

Requests with a body must send Content-Type: application/json. Responses are always application/json. Form-encoded bodies are not accepted. File uploads (e.g. user imports) use multipart/form-data on the specific endpoints that document it.

Interactive reference

A running server exposes an interactive API reference at /api and the OpenAPI JSON document at /api/openapi/json — e.g. https://journey-server-prod.us-east-1.core.inseng.io/api and https://journey-server-prod.us-east-1.core.inseng.io/api/openapi/json.

Idempotency

GET, PUT, and DELETE are idempotent by HTTP convention. Journey does not honor an Idempotency-Key request header; clients that need at-most-once semantics on POST should rely on resource-specific idempotency (e.g. the enrollment endpoints return the existing record when called twice with the same inputs).

See also authentication, errors, pagination, permissions, object_ids.