Dobby
Back to Academy
DeveloperBeginner

Dobby REST API: 500+ Endpoints Quickstart Guide

Get started with the Dobby REST API. Create tasks, manage agents, query costs, and automate your agent fleet programmatically.

10 min read Gil KalMar 26, 2026

What you will learn

  • Authenticate with the Dobby API using API keys or Gateway keys
  • Create and manage tasks programmatically
  • Query agent costs and activity via the analytics API
  • Integrate Dobby into your existing CI/CD and automation pipelines

Two Ways to Authenticate

Dobby supports two authentication methods. API keys (sk_live_*) are for server-to-server integrations — they have full access to the tenant API. Gateway keys (gk_user_*, gk_svc_*, gk_tmp_*) are for LLM and MCP requests — they go through the policy engine.

  • API keys (sk_live_*) — full tenant API access, scoped by permission, IP-whitelisted
  • Gateway user keys (gk_user_*) — 100 RPM, for individual developers
  • Gateway service keys (gk_svc_*) — 500 RPM, for production agents
  • Gateway temporary keys (gk_tmp_*) — 50 RPM, auto-expire, for testing

Creating a Task

python
import requests

API_URL = "https://dobby-ai.com/api/v1"
API_KEY = "sk_live_your_api_key"

# Create a task
response = requests.post(
    f"{API_URL}/tenants/{TENANT_ID}/tasks",
    headers={"Authorization": f"Bearer {API_KEY}"},
    json={
        "title": "Review security configuration",
        "description": "Audit IAM roles and network policies",
        "priority": "high",
        "assigned_agent": "dobby-security-worker-agent"
    }
)

task = response.json()
print(f"Task created: {task['id']}")

Querying Agent Costs

python
# Get cost breakdown per agent (last 30 days)
response = requests.get(
    f"{API_URL}/tenants/{TENANT_ID}/analytics/agent-costs",
    headers={"Authorization": f"Bearer {API_KEY}"},
    params={"period": "30d"}
)

costs = response.json()
for agent in costs["cost_by_agent"]:
    print(f"{agent['agent_name']}: ${agent['total_cost']:.2f}")
    print(f"  Tokens: {agent['total_tokens']:,}")
    print(f"  Requests: {agent['total_requests']}")

The Dobby API has 500+ endpoints organized by domain: tasks, agents, approvals, gateway, analytics, schedules, policies, and more. Full OpenAPI documentation is available at /developers.

Key API Domains

  • Tasks — CRUD operations, status updates, assignment, timeline events
  • Agents — list, configure, enable/disable, fleet status, per-agent metrics
  • Approvals — list pending, approve, reject, request changes, approval history
  • Gateway — API key management, usage stats, kill-switch, policies
  • Analytics — cost by agent/provider/user, daily trends, forecast, FinOps
  • Schedules — create recurring/one-time agent runs, pause, resume
  • Webhooks — GitHub/GitLab PR, CI, push events

CI/CD Integration Example

A common pattern is triggering Dobby tasks from CI/CD pipelines. When a PR is opened, create a security review task. When CI passes, trigger a deployment task with an approval gate. When a deploy completes, update the task status.

yaml
# GitHub Actions: trigger Dobby task on PR open
# .github/workflows/security-review.yml
name: Security Review
on:
  pull_request:
    types: [opened]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - name: Create Dobby security review task
        run: |
          curl -X POST "$DOBBY_API/tenants/$TENANT/tasks" \
            -H "Authorization: Bearer $DOBBY_API_KEY" \
            -H "Content-Type: application/json" \
            -d '{
              "title": "Security review: PR #${{ github.event.number }}",
              "priority": "high",
              "assigned_agent": "dobby-security-worker-agent",
              "metadata": {"pr_url": "${{ github.event.pull_request.html_url }}"}
            }'
Without Dobby

Security reviews are manual — developers remember (or forget) to request them. No tracking of which PRs were reviewed.

With Dobby

Every PR automatically triggers a security review task. The agent reviews it, requests approval if issues are found. Full audit trail of every review.

Rate limits are enforced per key type: user keys at 100 RPM, service keys at 500 RPM. Use a service key for CI/CD integrations to avoid throttling during deploy spikes.

Ready to try this yourself?

Start free — no credit card required.

Start Free