Permissions
Apply least privilege to people, integrations, and server-side API keys.
On this page
Human access and machine access
A team role controls actions performed by a signed-in person. A Carden API key controls actions performed by a backend service. Neither replaces the other. A key also belongs to a merchant and environment; possessing a scope never grants access to a different organization's objects.
Role names summarize a set of permissions. Review the current permission list in Team or Settings rather than assuming a title alone grants key creation, member management, integration writes, or access to logs.
API key scopes
| Scope | Use | Recommended recipient |
|---|---|---|
enrichment:write | Prepare Stripe payment enrichment. | Payment preparation service. |
payments:write | Submit actual payment attempts and outcome reports. | Payment backend or report-delivery worker. |
integrations:read | Read integration information such as available sync status operations. | An integration monitoring service. |
integrations:write | Perform supported integration setup or sync operations. | An authorized integration management service. |
Request only the scopes a service needs. Stripe keys support enrichment:write and payments:write; QuickBooks keys support integrations:read and integrations:write. Use a separate provider-specific key for an integration manager and a minimally scoped key for a report-delivery worker.
Choose a role by responsibility
- Owners: keep merchant accountability and access-management responsibility with a small number of people.
- Integration maintainers: grant only the configuration and troubleshooting permissions they need.
- Finance reviewers: give visibility into relevant reports and evidence without unnecessary credential-management rights.
- Read-only reviewers: use read access where no changes are required.
These are responsibility examples, not promises that every workspace exposes a separately named role for each. Use the actual roles and permission controls available in your deployment.
Handle a denied operation
- Confirm the active merchant and environment.
- For a browser action, inspect membership and role; for an API request, inspect the key's status and scopes.
- Check whether workspace settings restrict the requested capability.
- Ask an owner for the minimum additional access needed, or create a properly scoped replacement key.
- Retest with a harmless operation and retain the request ID if the denial persists.
Treat authentication and authorization failures as configuration or access issues, not transient delivery failures. Repeatedly retrying a forbidden report with the same key will not grant permission.