Connect DevRev to AI Agents: Orchestrate Tickets and SLA Workflows

If your team uses ChatGPT for ad-hoc queries, check out our guide on connecting DevRev to ChatGPT. Alternatively, if your engineers rely on Anthropic's models, read our guide on connecting DevRev to Claude. However, if you are building autonomous AI agents to programmatically orchestrate engineering tickets, SLAs, and part assignments without human intervention, you need structured tool calling. This guide will show you how to securely bind DevRev's API to agents using Truto.

Building an agentic workflow on top of DevRev requires exposing the underlying API as a deterministic set of tools. Truto simplifies this via the /tools endpoint, which maps DevRev API resources into a REST-based CRUD schema that frameworks like LangChain or Vercel AI SDK can natively consume.

The Engineering Reality of the DevRev API

Building agents against DevRev is not a standard "read ticket, update ticket" exercise. DevRev's ontology is highly relational and specific to product development workflows. You have to navigate several unique API realities.

First, there is a strict separation between Works (tickets, issues, tasks) and Parts (features, microservices, components). You cannot just create an issue in a vacuum - it must be associated with an applies_to_part identifier. When an agent creates a ticket, it must first query the parts registry to resolve the correct ID.

Second, DevRev tracks activity via Timeline Entries rather than simple comment arrays. A timeline entry is polymorphic; it might contain plain text, but it could also contain a snap_kit_body or snap_widget_body for rich UI rendering, alongside linked artifacts. Agents must specify body_type when posting.

Third, handling SLA Trackers is complex. SLAs in DevRev are evaluated against specific stages and schedules. Fetching an SLA tracker returns nested data regarding metric_target_summaries - including breached times, remaining times, and out-of-schedule flags. Parsing this requires explicit instructions for your LLM.

Finally, let's talk about rate limits. Truto does not retry, throttle, or apply backoff on rate limit errors. This is an intentional design choice. When the DevRev upstream API returns an HTTP 429 (Too Many Requests), Truto passes that 429 directly to your agent. However, Truto normalizes the varied upstream rate limit information into standardized IETF headers: ratelimit-limit, ratelimit-remaining, and ratelimit-reset. Your agent's execution loop is entirely responsible for reading these headers and executing its own backoff strategy.

DevRev Tool Inventory for AI Agents

Truto abstracts DevRev's endpoints into Proxy APIs. You can retrieve these dynamically using the /integrated-account/<id>/tools endpoint. Below is a breakdown of the tools available.

Hero Tools

These are the core tools your AI agent will rely on for 90% of ticket and SLA orchestration.

1. list_all_dev_rev_works

Queries work items (issues, tickets) across the DevRev organization.

• Contextual Usage Notes: You can filter by applies_to_part, stage, priority, or owned_by. Agents should use this to build queues or find specific issues before applying updates.
• Example Prompt: > "Find all high-priority tickets assigned to the backend service part that are currently in the 'triage' stage."

2. create_a_dev_rev_work

Creates a new work item (issue or ticket) in DevRev.

• Contextual Usage Notes: Requires type, applies_to_part, owned_by, and title. Your agent must typically call list_all_dev_rev_parts first to find the correct applies_to_part ID.
• Example Prompt: > "Create a new bug ticket for the payment gateway part. Assign it to user ID 402 and title it 'Stripe webhook failure'."

3. update_a_dev_rev_work_by_id

Updates an existing work item.

• Contextual Usage Notes: Use this for state transitions (e.g., updating stage from 'in_progress' to 'resolved') or adjusting priority.
• Example Prompt: > "Update ticket TKT-1024 to critical priority and move its stage to 'escalated'."

4. list_all_dev_rev_timeline_entries

Retrieves the timeline (comments, state changes, artifact attachments) for a specific object.

• Contextual Usage Notes: Requires the object parameter (the ID of the work item). Essential for agents trying to catch up on the context of an issue before responding.
• Example Prompt: > "Get all the timeline comments for issue ISS-992 so I can summarize the engineering discussion."

5. create_a_dev_rev_timeline_entry

Posts a new entry or comment onto a work item's timeline.

• Contextual Usage Notes: The agent must define type as 'timeline_comment' and provide the target object ID. Use this for automated status updates or support responses.
• Example Prompt: > "Add a comment to ticket TKT-441 saying that the automated database migration script has completed successfully."

6. list_all_dev_rev_service_level_agreement

Fetches active SLAs and their policies.

• Contextual Usage Notes: Returns the evaluation periods and rules. Use this in tandem with list_all_dev_rev_sla_trackers to determine if your queues are at risk of breaching.
• Example Prompt: > "Retrieve our active enterprise support SLAs to check the required response times for severity 1 issues."

7. get_single_dev_rev_sla_tracker_by_id

Retrieves detailed tracking data for a specific SLA applied to an object.

• Contextual Usage Notes: Exposes metric_target_summaries, showing exactly when an SLA breached or how much time is remaining.
• Example Prompt: > "Check the SLA tracker ID SLA-TRK-09 to see how much time we have left before we breach the response target."

For the complete tool inventory and full schema details, visit the DevRev integration page.

Workflows in Action

Here is how distinct personas utilize an agentic workflow using the Truto /tools endpoint.

Scenario 1: Support Escalation & SLA Audit (Product Ops)

Product Operations teams need to ensure enterprise customers receive support inside their contracted windows.

"Review the queue for any support tickets in the 'open' stage. Check their SLA trackers. If any ticket has less than 30 minutes remaining on its response target, elevate its priority to high and post a warning on its timeline."

Agent Execution:

1. list_all_dev_rev_works: Filters works by stage=open and type ticket.
2. list_all_dev_rev_sla_trackers: For the returned tickets, the agent retrieves tracker objects, parsing the remaining_time inside the metric_target_summaries object.
3. update_a_dev_rev_work_by_id: For tickets matching the breach condition, the agent patches the priority field.
4. create_a_dev_rev_timeline_entry: The agent posts an automated timeline comment: "Automated escalation: SLA response target breaching in under 30 minutes."

Result: The queue is triaged programmatically. At-risk tickets are bumped up the support view, and an auditable timestamp is logged on the ticket timeline.

Scenario 2: Auto-Triage & Part Assignment (Support Engineer)

Support engineers spend hours moving bug reports into the right developer queues based on the text of a user report.

"Read the latest unassigned bugs. Determine which product component they belong to, assign them to the correct Part, and assign the ticket to the technical lead of that group."

Agent Execution:

1. list_all_dev_rev_works: Fetches issues lacking an applies_to_part or owned_by assignment.
2. list_all_dev_rev_parts: Grabs the list of active product parts (e.g., "Auth API", "Checkout UI").
3. LLM Reasoning Step: The agent reads the body of the work item, matches the context to the "Checkout UI" part ID, and identifies the owned_by user linked to that part.
4. update_a_dev_rev_work_by_id: Updates the issue payload with the derived applies_to_part and owned_by IDs.

Result: An untriaged queue of 50 bug reports is categorized and routed to the correct engineering groups in seconds, enforcing DevRev's relational schema.

Building Multi-Step Workflows

When passing Truto tools into LangChain, CrewAI, or Vercel AI SDK, you leverage Truto's dynamic generation. Using the truto-langchainjs-toolset, you initialize a tool manager that hits the /tools endpoint, fetches the schema descriptions, and registers them locally.

import { ChatOpenAI } from "@langchain/openai";
import { TrutoToolManager } from "truto-langchainjs-toolset";
 
const truto = new TrutoToolManager({
    apiKey: process.env.TRUTO_API_KEY,
});
 
// Fetch DevRev specific tools using the integrated account ID
const devRevTools = await truto.getTools("devrev_account_123");
 
const llm = new ChatOpenAI({ model: "gpt-4o" });
const agent = llm.bindTools(devRevTools);

Because Truto abstracts authentication and pagination at the Proxy API level, the LLM does not have to reason about bearer tokens or cursor generation. It only has to formulate the query object.

Handling Failures and Rate Limits

In a multi-step loop, failures happen. DevRev enforces API quotas. Since Truto acts as a pass-through and explicitly does not retry or absorb rate limit errors, your architecture must catch HTTP 429s.

When a 429 occurs, Truto reads DevRev's custom rate limit response and maps it strictly to the IETF standard headers (ratelimit-limit, ratelimit-remaining, and ratelimit-reset).

If your LangChain agent hits a tool failure, you should configure your execution graph (e.g., LangGraph) to trap the error, inspect the ratelimit-reset timestamp, and pause execution before returning control to the LLM to retry the list_all_dev_rev_works call. Failing to implement this backoff on the caller side will result in a hard failure of your agentic loop.