Authentication
Create an API key in your account settings, then send it on every request. The public API lets your automations read boards and labels and create or move cards.
- Base URL:
https://projavo.com - Prefix: every route lives under
/api/v1 - Format: JSON request and response bodies
Create a key
- Sign in and open Account Settings → API keys.
- Click New key. Give it a name such as
Bug report bot, pick an expiry, select organizations and permissions, then click Create. - Copy the key immediately. It starts with
pm_and is shown only once.
New keys default to read-only. Select an organization before you create the key.
Send the key
Send the key in an Authorization header on every request:
Authorization: Bearer pm_xxxxxxxxxxxxxxxxxxxxxxxx
curl https://projavo.com/api/v1/boards \
-H "Authorization: Bearer $PROJAVO_API_KEY"
const res = await fetch("https://projavo.com/api/v1/boards", {
headers: { Authorization: `Bearer ${process.env.PROJAVO_API_KEY}` },
});
const { boards } = await res.json();
If a Bearer header is inconvenient in your environment, the x-api-key: pm_... header also works.
Never commit an API key to source control, paste it into client-side code, or post it in a chat. Load it from an environment variable or a secret manager. If a key leaks, revoke it in Account Settings → API keys and create a new one.
Scopes and permissions
A key acts as the user who created it. Three settings limit what it can do:
| Setting | What it allows |
|---|---|
| Organizations | Selected organizations, or all organizations you belong to. The all-organizations option also includes organizations you join later. |
| Read | All GET /api/v1 endpoints for boards, cards, and labels. |
| Create | POST /api/v1/cards. |
| Move | PATCH /api/v1/cards/:cardId. |
Read, create, and move are independent. Removing every organization or permission blocks the matching access.
Open Account Settings → API keys → Access to change grants. You can disable or re-enable a key there without changing its secret. Disabling a key blocks all of its requests. Revoking a key permanently deletes it.
Role requirements
The API also re-checks the owner's current membership and role on every request. A key can never reach data or perform an action its owner cannot.
| Owner's role in the organization | Read | Create cards | Move cards |
|---|---|---|---|
| Owner, admin, member | Yes | Yes | Yes |
| Guest | Yes | No | No |
A create or move also needs the matching key permission.
Legacy keys
Keys created before access policies existed keep account-wide read, create, and move access. They appear as Legacy access. You can restrict them with the same Access editor. No URL or header changes are required.
Denied requests
| Situation | Response |
|---|---|
| The key lacks the permission for the action | 403 with insufficient_scope |
| A list endpoint reaches an organization outside the grant | That organization is left out of the results |
| A card or board lookup reaches an inaccessible resource | 404 |
| You create a card in an organization outside the grant | 403 with organization_not_allowed |
Rate limit
Each key can make 60 requests per minute. Requests over that limit return 429. See Errors for the full status-code reference.
Desktop app session reads
The Projavo desktop app uses your signed session cookie instead of an API key for GET /api/v1/boards, GET /api/v1/boards/:boardId, and GET /api/v1/cards. Each read checks the current session, account status, and organization membership. On a verified custom domain, session reads are limited to that domain's organization. The desktop app's user agent labels the device in your session settings but grants no access.
Programmatic integrations should keep using API keys. If a request includes a key header, the key is used and cookies are ignored, even when the key is invalid or disabled. Creating and moving cards through /api/v1 always requires an API key with the matching permission.
Interactive changes from the desktop app go through /api/desktop. That surface reuses the web app's actions under your normal session and role permissions. Writes require JSON and a matching request origin, and this surface never accepts API keys. The desktop app's realtime stream keeps its cookies in the native layer and repeats the session, account, and membership checks. It also receives the same board broadcasts as the web app.