This page can't list "the" Runtime API endpoints, because there are none fixed in code - every route is configured per-Project via the Admin API. To see exactly what methods and paths are available (and which data type and, for a nested path, which relationship each one resolves against), call the Admin API's GET /projects/{projectId}/routes for the Project you're integrating with.
Returns every record of the configured type in this API key's dataset. For a nested route (e.g. /team/{id}/players), the parent is resolved first via the relationship's target field - 404 if it doesn't exist - then only children whose relationship source field references that parent are returned (an empty array, not 404, if the parent exists but has none). If this key has no dataset instance yet, one is created now from the Project's current master template, before the request is processed.
Resolves one record using the route's configured lookupField - the identifier, a slug, a UUID, or any other configured unique field. 404 if no matching record exists in this key's dataset.
Creates a record in this key's dataset. Validated against the type's schema, identifier/uniqueness rules, and relationship constraints. If the identifier field isn't supplied and is a plain numeric field, the service assigns the next value automatically. For a nested route, the relationship field is populated automatically from the resolved parent - 404 if the parent doesn't exist. 403 for a read-only key, 422 for a schema violation, 409 for a uniqueness conflict.
Replaces the complete record. Must satisfy the full schema; the identifier cannot be changed. 404 rather than creating the record if it doesn't already exist.
Applies only the supplied properties onto the current record, then validates the complete resulting object the same way PUT does. Returns the full updated record, not just the submitted fields.
Removes one record from this key's dataset. Never cascades to related records - a nested type's rows referencing the deleted parent are left as-is, so mock behaviour stays predictable. 403 for a read-only key, 404 if the record doesn't exist.
Discards every mutation made through this key and restores a clean copy of the Project's current master template - authenticated by X-API-Key alone, so resetting mock data never requires user-level login. Identical in effect to the Admin API's per-key reset endpoint - both call the same underlying implementation and produce the same audit trail. 409 if the Project has never generated a template.
Each API key gets its own isolated, mutable dataset - changes made through one key are never visible through another, and are never applied to the Project's master template. A dataset with no activity for about two hours is automatically cleared; the next request against that key silently creates a fresh copy of the current template. The key itself never expires - only its dataset does.
Every authenticated Runtime API request - including POST /_mock/reset, and one that ends in a 404 because no route matches - increments a daily counter for that API key: request_count always, plus read_count for a GET or write_count for anything else. This is purely for later reporting (per-key/per-Project/per-Space daily activity) - it never affects request behavior, and a usage-tracking failure never fails the actual request it's counting.