You can generate API keys from your account settings. The response includes the raw key exactly once; we never store it in plaintext. What we persist is a hashed version of the key, which is enough to look it up on future requests without ever exposing the secret if our systems were ever compromised.
Keys are a securely generated, high-entropy string, so they can't be guessed or brute-forced. Each key also carries a role and an optional expiry date, which you choose when you create it. For the exact request format when integrating against the API, see the Crowdee API documentation.
A key can be restricted to one or more specific organizations. When a key is org-scoped, it only works for requests to those organizations. An unscoped key can be used across all organizations you belong to.
A key's effective permissions are always capped by two things: the role you assigned to the key, and your own actual membership role in the organization it's being used against. In practice, this means a key can never grant more access than you personally have. If you hold a standard role in an organization and issue a key with a higher role by mistake, requests made with that key in that organization are still limited to what your standard role allows. This is a deliberate design choice: keys are meant to be credentials, not a way to escalate your own access.
Every request is checked against the resolved role before anything else happens, so permissions are always enforced consistently no matter which key or session is used.
Many Crowdee users — especially people managing work across several client accounts — belong to more than one organization. Crowdee keeps track of which organization is "active" for a given request: for an org-scoped API key, that's simply the organization the key is scoped to; for a regular logged-in session, it's whichever organization you've currently selected.
Switching organizations does not require logging out and back in. You simply select a different organization, and your permissions and visible data are refreshed for that context immediately.
This active organization is what keeps your data separated: a project that lives in one organization is never visible from a request tied to a different organization, no matter which key or session is used, and your effective permissions are always calculated fresh for the organization you're currently working in.
From an integration perspective, this isolation is mostly invisible — in a good way. A client application that uses a key scoped to a single organization, and consistently uses that context on every request, will never accidentally touch another customer's data. Key-level scoping adds an extra layer of protection on top of the strict data isolation Crowdee already enforces between organizations at the database level.
For more advanced use cases — for example, automation scripts that need to work across several client organizations — the recommended pattern is to issue a separate key per organization and select the right one for each request. This keeps things unambiguous and keeps your audit trail clean, since every API key's activity is clearly tied to a single organization.
Keys are never stored in plaintext, so even in the unlikely event of a data breach, there are no usable credentials to expose — only hashes that can't be turned back into working keys.
Expiry dates are enforced on every request: once a key expires, it stops working immediately, even though we keep a record of it for audit purposes rather than deleting it outright. Organization scoping is enforced the same way — a key simply doesn't work for an organization it wasn't issued for, regardless of anything else about the key. Taken together — no plaintext storage, role limits, organization scoping, and expiry — a leaked key has a tightly bounded impact, both in how long it stays valid and in what it can actually access.
Share this article:
