The Crowdee API supports a few different ways to authenticate, and which one you reach for depends on what you're building.
If you're writing a script, a CI pipeline, or a backend integration, an API key is the right tool: it's a long-lived credential you generate once, attach to your requests, and revoke whenever you like. If you're building something that sits behind a user's browser session — for example a service that already participates in our normal sign-in flow — a session or token-based approach tied to that login is usually the better fit, since it inherits the user's identity and permissions automatically rather than requiring a separately managed secret.
For most developers integrating with Crowdee for the first time, the API key path is the simplest starting point. It requires no login flow, no session handling, and no token refresh logic — you generate it once and use it until you decide to rotate or revoke it.
A handful of read-only endpoints (like our API documentation and root discovery routes) are publicly accessible without any authentication at all. Everything else requires one of the methods above.
API keys are issued through the platform UI. Sign in, navigate to Settings → API Keys, and click the create button. Give the key a descriptive name — something like ci-pipeline or local-dev — and choose the role it should carry. The effective permissions the key grants are always capped by your own membership role in the active organization, so a key can never let you do more than you're already allowed to do yourself.
Once you confirm, the platform displays the full key value exactly once. Copy it to a secure location immediately — we don't store the raw value, so if you lose it you'll need to revoke it and issue a new one.
Keys can optionally be scoped to specific organizations. If you're building an integration that should only ever touch one organization's data, setting that scope at creation time is a useful safeguard — requests made with the key will be rejected outside of that scope.
An API key is a credential, so treat it like one:
If a key is ever exposed — pushed to a public repo, logged somewhere it shouldn't be, and so on — revoke it immediately from Settings → API Keys and issue a replacement.
Requests are rate-limited to keep the platform stable and fair for every user and integration. Anonymous requests without an API key are held to a noticeably tighter limit than authenticated ones, which is one more good reason to authenticate even for simple, low-stakes integrations.
If you hit a rate limit, the API will let you know clearly; the standard approach is to back off and retry after a short delay rather than retrying immediately in a loop. For bulk operations — processing large numbers of files or polling for results — we recommend batching requests and spacing them out rather than sending them as fast as possible.
If your integration has sustained throughput needs beyond the default limits, get in touch with us — production workloads with a clear justification can be accommodated.
With authentication working, the natural next step is to explore what the API can actually do for your use case — from running verification pipelines to managing projects and datasets. Rather than duplicate that reference material here, head to docs.crowdee.ai for the full, always up-to-date integration guide, including exact endpoints, request and response formats, and worked examples for each authentication method.
Share this article:
