PRACTICAL FIELD GUIDE
A record returns 404: missing or not owned?
A 404 can represent a missing record or a record outside the end user's owner scope. This avoids revealing another user's row through the existence of an error distinction.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Confirm the table, primary key and project in the request.
- Check the intended caller and inspect the record through an authorized administrative path when appropriate.
- Test a known owned record and a known non-owned record to validate the policy behavior.
What this looks like
ILLUSTRATIVE EXAMPLE
A second test user requests the first user's task ID and receives 404. The row exists, but it is not visible to that user.
A boundary to keep clear
Do not widen read access just to make a troubleshooting request return the row.
MCPBackend context
Use get_project_api or the dashboard's generated OpenAPI contract for your project's exact data-plane routes. Machine keys and end-user tokens have different access models. Treat error status and JSON code together, keep credentials out of URLs, and test against disposable records before changing real data.
Take the next step
Inspect the current project contract, try the change with disposable data, and verify the result through the same credentials your app will use. Record the expected response and one denied-access case before release.
Sources and further reading
These references explain the underlying protocols and design principles. For supported MCPBackend operations and exact request shapes, inspect your project’s generated API contract.