PRACTICAL FIELD GUIDE
An API key belongs to a different project
A machine key is bound to its project, so using it with another project's URL should fail even when the tables share names. Verify the identity pair before creating new credentials.
MCPBackend editorial team · · Examples are illustrative
Put it into practice
- Compare the project ID in the request URL with the key's management record.
- Check deployment environment variables for a mixed preview and production configuration.
- Correct the intended pairing and verify a harmless read or scoped test operation.
What this looks like
ILLUSTRATIVE EXAMPLE
A production base URL is combined with a staging key after a partial environment update. The resulting project_mismatch protects the boundary.
A boundary to keep clear
Do not broaden permissions to fix a project mismatch. Table scope and project identity are different checks.
MCPBackend context
MCPBackend row policies apply to anonymous callers and end-user tokens. Machine API keys bypass those row policies and are instead constrained by their own table permissions. Owner mode is based on the calling user's identity; it is not an organization-membership or arbitrary custom-policy engine.
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.