Project scoping

Every automation API key belongs to exactly one project. The API enforces that binding in addition to checking scopes.

Create and list operations

Send project_id in the JSON body when creating a resource or calling a /list endpoint.

{  "project_id": "65f0c7a9a7d6b4e2c1234567",  "sort": "created-desc",  "pagination": { "limit": 25 },  "filters": {}}

The ID must match the project bound to the API key. A mismatch returns 403 Forbidden.

Project-wide actions such as POST /v1/checks/summary and POST /v1/schedules/summary also require project_id in the body. They do not identify a single resource in the URL.

Item operations

Do not send project context when the URL already identifies a resource:

curl --request GET \  --url "https://api.restoretrust.example/v1/schedules/65f0c9bca7d6b4e2c7654321" \  --header "X-API-Key: rtk_REPLACE_WITH_YOUR_KEY"

For GET, PATCH, POST actions, and DELETE routes below a resource ID, the API loads the resource and derives its owning project.

Cross-project behavior

To avoid revealing whether another customer's resource exists, an item that is outside the key's project returns 404 Not Found, just like an unknown ID. Use a different API key for each project.

Projects themselves are managed with an interactive console session, not a project API key. See Projects.