API keys
Scoped, project-bound credentials for machines.
View as MarkdownOne key, one project, explicit scopes
A key cannot reach across projects. Grant only the scopes the integration uses: db.query.read, db.query.write, blob.read, blob.write, app.read, function.read and the rest.
Limit a key to specific databases
A key with db.query.read or db.query.write reaches every database of its project by default, including databases created later. To keep a key away from the others, name the databases it may use when you create it. The Data API answers 403 for any other database of the project. The databases must belong to the key's project, at most 50 can be listed, and the limit is fixed at creation: revoke the key and create a new one to change it. Storage scopes stay project wide. The key list in the dashboard and veltic apikeys list show which databases each key is limited to.
veltic databases list <projectId>
veltic apikeys create <projectId> jobSignals --scopes db.query.read,db.query.write --databases <databaseId>One key per integration
Separate keys mean you can revoke one without breaking the others, and the audit log attributes each change to the system that made it.
Where a key must never go
A key in a browser bundle is a published secret. Browser clients get short-lived tickets instead. In CI, keep the key in the secret store and never pass it as a public build argument.
Billing gates writes
An inactive managed subscription blocks platform mutations, including through API keys and the CLI. Sign-in and read access remain available so you can resolve the billing problem.