Skip to main content
AI agents can set up infrastructure, deploy services, and manage the full lifecycle through the Locus API. This guide covers the recommended workflow, communication best practices, token management, and timing expectations.

Getting started

1

Load the SKILL.md

The Build with Locus SKILL.md is the canonical API reference for agents. Load it to learn all available endpoints, authentication, and request/response formats.
2

Authenticate

Exchange your claw_ API key for a JWT token. Use this token as a Bearer header on all subsequent requests. Tokens expire in 30 days — refresh as needed with POST /v1/auth/refresh.
3

Deploy

Create a project, environment, and service, then trigger a deployment. The full setup-to-deploy flow takes about a minute of API calls, plus 3-7 minutes of build time.

Agent communication guidelines

Never go silent for more than 30 seconds during multi-step workflows. The human should always know what you’re doing, what you’re waiting on, and how long it will take.

Core principles

  1. Announce before you act. Tell the human what you’re about to do before making an API call.
  2. Set time expectations. If an operation takes more than a few seconds, say how long.
  3. Report outcomes. After each step, confirm success and share IDs/URLs the human might need.
  4. Bridge the gaps. The setup steps (project, environment, service creation) each take under 1 second, but the human sees silence — narrate the flow.
  5. Never block in long-running shell loops. Do not use while true loops to poll deployment status — they block tool output and make you go silent. Instead, poll once per tool call, report the status, then poll again in the next call.

Communication during setup

When walking through the core workflow (auth → project → environment → service → deploy), weave the steps naturally into your response:

Token management for agents

Get a fresh token at the start of every debugging session. Stale or expired tokens are the #1 cause of 401 Unauthorized errors. Verify your token works before debugging anything else:
If /whoami returns 401, your token is bad. Get a fresh one and retry.

Persisting tokens across tool calls

Shell variables are lost between tool calls. Three strategies:
  1. Chain commands in a single shell invocation using &&
  2. Save to file: echo $TOKEN > /tmp/locus-token.txt and read it back: TOKEN=$(cat /tmp/locus-token.txt)
  3. Re-exchange at the start of each tool call (fast, under 100ms)

401 error patterns

Deployment workflow

1

Trigger and inform

Trigger the deployment, then immediately tell the human what’s happening:
  • Deployment ID for reference
  • Current status (queued)
  • Expected wait time (3-7 minutes for GitHub/git push, 1-2 minutes for images)
  • That you’ll update them when it’s done
2

Monitor silently

Poll deployment status every 60 seconds. Do not send updates on every poll — the human doesn’t need to know it’s still building.
3

Report completion

When the deployment reaches healthy or failed, notify the human with the result, service URL (on success), or logs and next steps (on failure).

Operation timing reference

Best practices

Capabilities

Common scenarios

  1. Create a project and environment
  2. Create a service with the appropriate source (GitHub, image, or git push)
  3. Set environment variables if needed
  4. Trigger a deployment
  5. Poll until healthy, then report the service URL to the human
  1. Provision a Postgres addon in the service’s environment
  2. Wait for addon status to reach available (30-60 seconds)
  3. Add the addon template to the service’s variables: "DATABASE_URL": "${{db.DATABASE_URL}}"
  4. Trigger a new deployment on the service
  5. Verify the deployment reaches healthy
  1. Push new code via git push locus main (or update the image URI)
  2. If using git push, deployments trigger automatically for all services in the project
  3. If using image source, trigger a new deployment manually
  4. Poll until healthy and report to the human
  1. Fetch deployment details — lastLogs[] contains the last 20 log lines
  2. Common failures: health check timeout (missing /health endpoint), port mismatch (must be 8080), missing dependencies, build errors
  3. Fix the issue (update code, variables, or service config)
  4. Trigger a new deployment
  5. Report the failure reason and fix to the human

Response format

Most CRUD endpoints return the entity directly (not wrapped in a data envelope). Lists use plural keys: {projects: [...]}, {services: [...]}, etc. Aggregate endpoints return named objects:
  • POST /v1/projects/from-repo returns { project, environment, services, deployments, ... }
  • GET /v1/variables/service/:id/resolved returns { variables: { ... } }
HTTP status codes: 200 (ok), 201 (created), 204 (deleted), 400 (bad request), 401 (bad/expired token), 402 (insufficient credits), 404 (not found), 500 (server error).

Companion guides

These guides cover features beyond the core deploy path. Load them on-demand when needed.

Policy guardrails

Agent actions are subject to the spending controls configured in the Locus dashboard. Allowances, per-transaction budgets, and approval thresholds apply to any API calls that cost credits. See the Platform Walkthrough for details on configuring agent controls.