Skip to main content

DevRev

DevRev is an AI-native platform that unifies what most teams split across Jira, Zendesk, and a CRM: product engineering (issues, parts, sprints), customer support (tickets, conversations), and revenue (accounts, opportunities). The Webrix connector exposes DevRev's REST API so an MCP host can read and write work items, accounts, customer contacts, parts, and timeline activity from one integration.

The connector targets the production DevRev API at https://api.devrev.ai and uses a Personal Access Token (PAT) for authentication. Every tool runs with the same privileges as the dev user who created the PAT.

Authentication Types​

DevRev's public REST API supports a single authentication method:

  • Personal Access Token (PAT) — A dev-user-scoped bearer token issued from the DevRev app. Sent as Authorization: Bearer <PAT> on every request.
    • Pros: Quick setup; works for any DevRev plan; the PAT inherits the user's exact privileges so you don't have to manage scopes separately.
    • Cons: Tied to a single dev user; cannot be renewed (you have to mint a new one and update the integration); shows that user as the actor on every write. Best practice is to issue the PAT from a service-style user.
    • Best for: Backend automations, MCP integrations, internal tooling, and CI snippets.

DevRev does not expose a public OAuth flow for third-party apps. The Authentication and OAuth flows referenced in DevRev's snap-in framework are for installable apps inside DevRev itself, not for external API clients — those should use a PAT.

Setting up Personal Access Token​

1. Pick the right user​

The PAT inherits the privileges of the dev user who creates it. For an MCP integration that other people will rely on, prefer one of:

  • A dedicated integration user in DevRev (recommended for production).
  • A long-tenured admin's account (acceptable for a single-team setup).

Avoid issuing the token from a personal account that may be deactivated when someone leaves the company — the integration will silently break.

2. Generate the PAT in DevRev​

  1. Sign in to the DevRev app and switch to the dev org you want to integrate.
  2. Click your avatar (top-left) and confirm the right org is selected.
  3. Go to Settings → Account → Personal Access Token.
  4. Click New token.
  5. Enter a descriptive name (e.g. Webrix MCP). DevRev cannot show the value again after this screen, so the name is the only way to find it later.
  6. Choose a validity duration that matches your rotation cadence. PATs can't be renewed — when a token expires you must mint a new one and update the integration.
  7. Click Create and immediately copy the token to a password manager.
Treat the PAT like a password

A DevRev PAT can read and write everything the issuing user can — accounts, tickets, customer PII, opportunities. Never commit it to source control or paste it into chats. If it leaks, revoke it from Settings → Account → Personal Access Token and issue a new one.

3. Configure in Webrix​

  1. In Webrix, go to Integrations → New → Built-in.
  2. Select DevRev and click Use.
  3. Under Authentication Type, choose API Key.
  4. Paste your Personal Access Token into the credential field.
  5. Click Save Changes, then Test Connection. Webrix will call dev-users.self to verify the token.

4. Verify the integration​

Run the Get Self tool with no arguments. A successful 200 response with your DevRev profile confirms the token is valid and the connector is wired correctly.

Available Tools​

The DevRev connector ships 24 tools across seven categories.

Works (6 tools)​

Work items are DevRev's umbrella concept for issues, tickets, tasks, and opportunities.

  • List Works — Paginated list of work items, filterable by type, state, stage, owner, part, and tags.
  • Get Work — Single work item by ID or display ID (ISS-69, TKT-42).
  • Create Work — Create a new issue, ticket, task, or opportunity.
  • Update Work — Change title, body, owners, priority, applied part, target close date.
  • Delete Work — Permanently delete a work item (destructive).
  • Count Works — Counts matching the same filters as List Works — handy for dashboards.

Accounts (4 tools)​

Accounts represent your customer organizations.

  • List Accounts — Filter by display name, domains, tier, external refs, owner.
  • Get Account — Full account profile by ID.
  • Create Account — Provision a new customer account; DevRev auto-creates a default Rev org.
  • Update Account — Update name, description, domains, tier, owners, external refs.

Rev Orgs (2 tools)​

A Rev org is the customer-side workspace nested under an account.

  • List Rev Orgs — Filter by account or display name.
  • Get Rev Org — Single Rev org by ID, or the default Rev org for an account.

Rev Users (3 tools)​

Rev users are customer-side identities (contacts and leads).

  • List Rev Users — Filter by email, Rev org, external refs, phone numbers, verified state.
  • Get Rev User — Single Rev user by ID.
  • Create Rev User — Create a customer contact tied to a Rev org or account.

Dev Users (2 tools)​

Dev users are your internal team in DevRev.

  • Get Self — The authenticated user's profile (the PAT owner).
  • List Dev Users — Find teammates by email, state, or timezone; returns IDs needed for owned_by.

Parts (2 tools)​

Parts are DevRev's product/service taxonomy (product → capability → feature → runnable, plus enhancements).

  • List Parts — Filter by type, name, owners.
  • Get Part — Single part by ID.

Tags (1 tool)​

  • List Tags — Tags defined in the dev org; returns IDs to use on Create Work and Update Account.

Timeline & Articles (4 tools)​

  • List Timeline Entries — Comments and system events on any DevRev object.
  • Create Timeline Comment — Post a comment on a work item, account, or other object, with internal / external / private / public visibility.
  • List Articles — Knowledge-base articles, filterable by part, status, author, tags.
  • Get Article — Single article by ID, including title, status, applied parts, vote counts.

Pagination​

Most list endpoints return a next_cursor (and sometimes prev_cursor). Pass next_cursor back as the cursor argument on the next call. The default page size is 50; bump limit for fewer round-trips on large result sets.

Common Use Cases​

File a bug from a support conversation​

Create Account (display_name="Acme Inc", domains=["acme.com"]) →
  Create Rev User (email="[email protected]", account=<account.id>) →
  Create Work (type="ticket", title="Login failure", applies_to_part=<PROD-id>, owned_by=[<self.id>]) →
  Create Timeline Comment (object=<TKT-id>, body="Repro steps: ...", visibility="internal")

Daily triage queue​

Get Self →
  List Works (type=["issue"], state=["open"], owned_by=[<self.id>]) →
  Count Works (type=["issue"], state=["open"], owned_by=[<self.id>])

Customer-360 export​

List Accounts (paginate via cursor) →
  For each account: List Rev Users (rev_org=<default_rev_org.id>) →
                    List Works (type=["ticket"], created_by_account_via filter)

Troubleshooting​

invalid token on every request​

Cause: The PAT is malformed, expired, or was revoked.

Solution:

  1. Decode the token at jwt.io to confirm it's a valid JWT and not yet expired.
  2. If expired or revoked, mint a new PAT in DevRev (Settings → Account → Personal Access Token) and update the integration.
  3. Confirm there's no whitespace in the pasted value.

403 forbidden on a specific endpoint​

Cause: The dev user that owns the PAT doesn't have permission for that resource.

Solution:

  1. Confirm the user is a member of the dev org you're targeting.
  2. For destructive operations, check that the user has admin or the appropriate role on the target object.
  3. If you're hitting a sandbox vs. production mismatch, re-issue the PAT from the correct dev org and update the integration.

dev_org_deactivated​

Cause: The dev org the PAT belongs to has been deactivated, typically due to billing issues.

Solution: Reactivate the dev org in DevRev billing, then issue a fresh PAT.

429 too many requests​

Cause: DevRev's per-user or per-org rate limit has tripped. The response includes a retry_after field (seconds).

Solution: Back off using retry_after and retry with exponential backoff. For long syncs, prefer Count Works plus narrow filters over walking the entire List Works cursor.

applies_to_part is required when creating an issue or ticket​

Cause: Issues and tickets must be filed against a specific part.

Solution: Call List Parts first to find the right part ID (often a product or feature), then pass it as applies_to_part on Create Work.

PAT silently stopped working after a teammate left​

Cause: The PAT was tied to that user; deactivating the user invalidates their tokens.

Solution: Re-issue the PAT from a service-style user that won't be deactivated, and update the integration. This is the recommended setup for any production integration.

Additional Resources​