API Keys
API keys provide long-lived, programmatic access to the IntuitivePM REST API. Unlike JWT tokens — which are obtained by logging in with email and password and expire after 24 hours — API keys persist until you explicitly revoke them. This makes them the right choice for scripts, CI/CD pipelines, automation workflows, and any integration that runs without a human logging in.
API Keys vs. JWT Tokens
| API Key | JWT Token | |
|---|---|---|
| How to obtain | Settings → API Keys → Generate | POST /api/login with credentials |
| Expiry | Never (until revoked) | 24 hours |
| Best for | Automation, integrations, scripts | Interactive sessions, short-lived access |
| Scope | Tied to generating user’s permissions | Tied to authenticated user’s permissions |
| Revocable | Yes, from Settings | No (wait for expiry or rotate password) |
For interactive use cases where a user is actively working in a session, JWT tokens are the appropriate choice. For everything else — automation, webhooks, integrations — use an API key. See API Authentication for the full authentication overview.
Generating an API Key
- Log in to IntuitivePM at intuitivepm.net.
- Navigate to Settings > API Keys.
- Click Generate New Key.
- Enter a descriptive name for the key (for example,
staging-ci-pipelineorslack-bot-integration). Names help you identify which key belongs to which system when you have multiple keys. - Click Generate.
- Copy the key immediately from the confirmation dialog.
Important: The full key value is only displayed once, at the moment of creation. IntuitivePM stores a hashed version of the key and cannot show you the original again. If you lose the key, you must revoke it and generate a new one.
Key Format
All IntuitivePM API keys follow the prefix convention:
ipm_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
The ipm_live_ prefix identifies the key as a production credential for the IntuitivePM API. This prefix makes it easy to identify IntuitivePM credentials in code reviews, secret scanners, and .env audits.
Using an API Key
Include your API key in the Authorization header with the Bearer prefix, exactly as you would use a JWT token.
curl
curl -H "Authorization: Bearer ipm_live_YOUR_KEY" \
https://api.intuitivepm.net/api/projects
TypeScript / JavaScript
const res = await fetch('https://api.intuitivepm.net/api/projects', {
headers: { 'Authorization': `Bearer ${process.env.IPM_API_KEY}` }
});
const projects = await res.json();
Python
import os
import requests
headers = {"Authorization": f"Bearer {os.environ['IPM_API_KEY']}"}
response = requests.get("https://api.intuitivepm.net/api/projects", headers=headers)
print(response.json())
Tip: Always read API keys from environment variables rather than hardcoding them in source code. This prevents accidental exposure in version control and makes key rotation straightforward — update the environment variable without touching any code.
Scopes and Permissions
API keys do not have independent permission scopes. They inherit the full set of permissions belonging to the user who generated the key. This means:
- A key generated by a Viewer-role user can read project data but cannot create or modify tasks, projects, or members.
- A key generated by an Admin or Owner can perform any operation that user is permitted to do in the UI.
- If the generating user’s role is changed or their account is deactivated, the key’s effective permissions change or stop working accordingly.
When designing integrations, generate API keys from accounts with the minimum permissions required for the integration’s needs. Avoid using Owner-level accounts to generate keys for read-only integrations.
Usage Tracking
Every request made with an API key is logged. To view usage for your keys:
- Navigate to Settings > API Keys.
- Each key row shows a Request Count indicating how many API calls have been made with that key.
- Click on a key row to expand its details, including recent request timestamps and endpoint breakdown.
Usage data helps you identify keys that are no longer active (zero requests over an extended period) and are safe to revoke, as well as keys generating unexpectedly high traffic that may indicate a misconfiguration or unauthorized use.
Rotating Keys
Key rotation is the practice of replacing an existing key with a new one on a regular schedule, or immediately after a suspected compromise. Rotating a key with zero downtime requires a brief overlap period:
- Generate a new key following the steps above. Give it a name that indicates it is a replacement (for example,
slack-bot-integration-2026-03). - Update your integration to use the new key value. Deploy the update to your environment.
- Verify that the integration is working correctly with the new key by checking the usage counter on the new key and confirming the old key’s counter has stopped incrementing.
- Revoke the old key: In Settings > API Keys, click the trash icon next to the old key and confirm the deletion.
By keeping both keys active briefly, you ensure no requests fail during the transition. The total overlap window is typically the time it takes to deploy your updated environment variable — often a few minutes for most pipelines.
Rate Limits
API keys share the same rate limits as the IntuitivePM REST API:
| Method | Limit |
|---|---|
| API Key | 1,000 requests per hour |
When you exceed the rate limit, the API returns 429 Too Many Requests with a Retry-After header specifying how many seconds to wait before retrying. Your client should handle 429 responses by pausing for the indicated duration before retrying.
For full rate limit details across all authentication methods, see the API Endpoints reference.
Security Best Practices
Never commit keys to source control
API keys embedded in source code are a common cause of credential leaks. Use environment variables, a secrets manager (HashiCorp Vault, AWS Secrets Manager, Doppler), or your CI/CD platform’s built-in secrets store.
# .env.example — commit this (with placeholder, not real value)
IPM_API_KEY=ipm_live_YOUR_KEY_HERE
# .env — add to .gitignore, never commit
IPM_API_KEY=ipm_live_abc123...
Use .gitignore for .env files
# .gitignore
.env
.env.local
.env.*.local
One key per integration
Generate a separate key for each system or integration. This limits blast radius — if one key is compromised, you can revoke only that key without disrupting other systems.
Rotate keys regularly
Even if a key has not been compromised, rotating keys on a regular schedule (every 90 days is a common baseline) limits the window of exposure if a leak goes undetected.
Monitor usage for anomalies
Check the request count and timestamp data for your keys periodically. A sudden spike in requests from a key assigned to a low-frequency integration is worth investigating.
Next Steps
With an API key in hand, explore the full API Endpoints reference to see what operations are available, including projects, tasks, sprints, epics, virtual colleagues, and webhooks. For authentication fundamentals and JWT token usage, see API Authentication.