API reference
Availsync v1 API reference.
Use the Node SDK or MCP package for most pilots. Use the REST API directly when you need to integrate another runtime, language, or workflow engine.
For coding agents and automations, use /v1/work/run/start, /extend, and /finish first. The lower-level /v1/work/check and/v1/work/claim endpoints are for custom raw claim clients.
Work claims protect repos, projects, and file working sets. Holds protect availability or booking windows. Coding agents should normally use agent_type: genericand rely on explicit numeric priority for arbitration.
Work claims are immediate-start guardrails. start_at may only be a few minutes in the future to absorb clock skew. Use holds/availability for future booking windows.
Authentication
Agent calls use Authorization: Bearer API_KEY. Workspace dashboard calls use the login session cookie. Raw API keys are shown once at create or rotation time, then never returned again.
Authorization: Bearer AVAILSYNC_API_KEY Content-Type: application/json Idempotency-Key: optional-stable-key
Automation guardrail
Agent API key or workspace sessionPOST /v1/work/run/startStart a guarded run. Returns proceed or skip_run. In observe mode it proceeds and may include shadow_decision.
POST /v1/work/run/working-setDeclare the files an active run is currently touching. Returns updated, partial_proceed, or HTTP 409 with blocked.
POST /v1/work/run/extendExtend an active claim lease while the agent is still working. For heartbeat-enabled claims, this also records a claim heartbeat.
POST /v1/work/run/heartbeatRecord that an active claim is still owned by the agent. SDK and MCP use this for lost-claim recovery; heartbeats are non-billable telemetry.
POST /v1/work/run/finishRelease a run claim. Safe to call more than once.
Lower-level work coordination
Agent API key or workspace sessionPOST /v1/work/checkPreview whether a repo or project resource is available. Does not mutate claims.
POST /v1/work/claimLegacy low-level claim endpoint. New automations should use /v1/work/run/start. Supports Idempotency-Key and returns deprecation headers.
POST /v1/work/claims/:claim_id/extendExtend a specific claim.
DELETE /v1/work/claims/:claim_idRelease a specific claim.
GET /v1/work/claims/:claim_idFetch one claim by exact id inside the current workspace. Agent keys may use this to poll a blocking claim they were shown.
GET /v1/work/events?limit=50&offset=0Read the normalized coordination timeline across claim events, file working-set events, and work API activity. Filter by resource_type/resource_key, resource_id, claim_id, agent_id, or event_type.
GET /v1/work/claims/:claim_id/eventsThin event timeline alias for one claim. Use it when an agent or dashboard needs the history behind one run.
GET /v1/work/claims?limit=100&offset=0List current and recent claims with pagination. Agent keys only list their own claims. Active claims include current working_set file claims.
GET /v1/work/resources/:resource_id/eventsThin event timeline alias for one protected resource.
GET /v1/work/resources?limit=100&offset=0List protected resources with active claim counts and pagination. Limit is capped to avoid unbounded responses.
Activity and value
Workspace session unless notedGET /v1/activityList runtime traffic metadata. Workspace users can filter by agent, status, type, and date.
POST /v1/activity/usageAgent-key endpoint for reporting optional token usage or external run metadata.
GET /v1/value/healthDashboard value summary and agent health for the current workspace.
Billing and setup
Workspace sessionGET /v1/billing/statusCurrent plan, limits, usage, and upgrade hints.
POST /v1/orgs/:org_id/agents/:agent_id/test-connectionRead-only setup readiness check for one agent.
POST /v1/orgs/:org_id/agents/:agent_id/setup-testDashboard-run validation flow. Does not require the raw API key.
MCP
Agent API keyPOST /v1/mcp/heartbeatMCP clients use this to report online status. Heartbeats are logged for visibility but do not consume monthly coordination API-call quota. SDK and REST traffic use last_seen_at instead.
Common response actions
proceedThe agent can run. A claim may exist in enforce mode; observe mode can proceed without a claim.
partial_proceedA working-set update claimed some requested files but blocked others that another active run is editing or deleting.
blockedHTTP 409 from working-set. No requested edit/delete paths were claimable because another active run owns them.
skip_runAnother active claim has priority. Scheduled jobs should exit cleanly with the reason.
already_finishedFinish or heartbeat was called for a claim that is already terminal. Treat as success for cleanup.
lostA heartbeat-enabled claim stopped reporting heartbeats and Availsync marked it terminal so the resource can be claimed again.
plan_limit_reachedHTTP 402. The workspace hit a plan limit such as agents, protected resources, active claims, or monthly coordination API calls. MCP and claim heartbeats are excluded from this monthly quota.
Failure policy
The API returns structured errors with error, optional message, and request_id. The SDK throws for network and API failures so your automation can choose fail-closed in enforce mode or fail-open in observe mode. The Node SDK uses a 30 second default timeout and also accepts request-level AbortSignal values when a caller needs stricter cancellation.
Launch-critical examples
Start a guarded run
POST /v1/work/run/start
{
"agent_id": "AGENT_ID",
"resource_type": "repo",
"resource_key": "owner/repo",
"duration_minutes": 45,
"heartbeat_timeout_seconds": 300,
"reason": "scheduled Codex run"
}
200 OK
{
"action": "proceed",
"claim": { "id": "CLAIM_ID", "expires_at": "..." },
"retry_after": null
}Claim heartbeat
POST /v1/work/run/heartbeat
{
"claim_id": "CLAIM_ID",
"client_name": "@availsync/node"
}
200 OK
{
"action": "heartbeat_recorded",
"claim": {
"id": "CLAIM_ID",
"last_heartbeat_at": "2026-05-27T10:00:00.000Z",
"heartbeat_timeout_seconds": 300
}
}Blocked run
200 OK
{
"action": "skip_run",
"reason": "Another active work claim has priority",
"retry_after": "2026-05-22T10:30:00.000Z",
"blocking_claim": { "id": "CLAIM_ID" }
}Work event timeline
GET /v1/work/events?resource_type=repo&resource_key=owner%2Frepo&limit=50
200 OK
{
"events": [
{
"source": "work_file_claim_events",
"event_type": "blocked",
"claim_id": "CLAIM_ID",
"resource_type": "repo",
"resource_key": "owner/repo",
"path": "frontend/app/page.tsx",
"mode": "edit"
}
],
"pagination": {
"limit": 50,
"offset": 0,
"count": 1,
"total": 1,
"has_more": false
}
}Working set blocked
POST /v1/work/run/working-set
{
"claim_id": "CLAIM_ID",
"mode": "edit",
"paths": ["frontend/app/page.tsx"]
}
409 Conflict
{
"action": "blocked",
"blocked_paths": ["frontend/app/page.tsx"]
}
