Availsync

Docs

Availsync API docs

Availsync is the pre-flight coordination layer your agents check before they claim a repo, edit a project, start a release, run an automation, or book a downstream slot.

Every integrated agent checks in before it acts.

Core model

The pieces agents work with

Workspace

The admin account for your team. Humans log in with email and password, manage agents, billing, rules, and logs.

Agent

A runtime identity for a coding agent, MCP client, scheduling tool, cron job, or server automation.

Agent API key

A one-time secret used by agents only. It is scoped to one agent and should live in MCP, server, or automation env vars.

Work claim

A lease on a protected repo or project. It stops another agent from working on the same resource at the same time.

Enforce vs observe

Enforce stops conflicting runs. Observe lets the run continue, creates no lease, and records what Availsync would have blocked.

Availability hold

A secondary scheduling primitive for reserving a time window before an agent books a meeting, release, focus block, or other scheduled action.

Activity vs Audit

Activity shows runtime traffic. Audit shows governance events: holds, conflicts, work claims, releases, and actors.

Runtime flows

What agents should do before they act

Coding agents on the same repo

Use @availsync/node or work/run/start before an automation begins. Enforce mode returns skip_run when blocked; observe mode proceeds and records what would have happened.

1Install SDK
2Start run
3Extend lease when claimed
4Finish run when claimed

Dashboard setup validation

Run the dashboard setup test first to confirm the backend flow works, then connect the real Node SDK, public MCP package, or REST client.

1Run setup test
2Copy config
3Connect client
4Verify Activity

Scheduling agents before booking

Secondary flow: ask for availability, preview the conflict, then create a hold only when the slot is safe.

1Check availability
2Preview conflict
3Create hold
4Release hold

Resource scope

Choose safety or parallelism intentionally

Availsync blocks simultaneous work on the same resource. Different resources can run in parallel, so choose resource keys based on how much safety the agent needs.

Repo-level guardrail

repo:owner/name

Safest default. Only one active agent can work in the repo at a time, so shared files and context cannot change underneath another guarded run.

Use for new agents, scheduled automations, deploy work, migrations, and any repo where agents may touch shared files.

Project-level guardrail

project:homepage

Advanced mode. Different projects can run in parallel, but Availsync only blocks conflicts on the same project key.

Use only when work streams are truly independent. If homepage depends on product-catalog, protect them with the same repo-level resource.

Availsync does not yet infer dependencies between different resources. For example, it will not automatically know that project:homepage depends on project:product-catalog. Use repo-level scope when that dependency matters during the same run.

API map

Main endpoint groups

Workspace auth

Used by humans in the dashboard. Sessions are stored in secure httpOnly cookies.

POST /v1/auth/signupPOST /v1/auth/loginPOST /v1/auth/logoutGET /v1/session

Work coordination

The default runtime path for coding agents and automations that need repo or project guardrails. Use the SDK or MCP package first; use REST directly when you need lower-level control.

@availsync/node@availsync/mcpPOST /v1/work/run/startPOST /v1/work/run/extendPOST /v1/work/run/finish

Scheduling coordination

Used by agents that also need to check time windows and reserve slots before booking downstream systems.

GET /v1/availabilityPOST /v1/conflicts/checkPOST /v1/holdsDELETE /v1/holds/:hold_id

Activity and diagnostics

Used to confirm real traffic, debug setup, and inspect system health without exposing secrets.

GET /v1/activityPOST /v1/activity/usageGET /health

Plan limits

How usage limits are counted

A protected resource is each unique (resource_type, resource_key) saved in the workspace. Releasing a claim does not remove the resource.
An active work claim is a claim with status='active' and expires_at still in the future.
On Free, you can create up to 3 agents, and up to 3 work claims can be active at the same time.

Recommended path

Pick the shortest path for how your agents run

Using Codex, Cursor, or Windsurf locally? Run npx @availsync/setup.

Using Claude Code too? The setup CLI prints the native claude mcp add command, or you can run it directly.

Using Claude Code only? Use claude mcp add for the fastest setup.

Embedding Availsync in an automation or CI job? Use @availsync/node.

Dashboard users authenticate with email and password. Agent API keys are not dashboard logins.
Raw API keys are shown once after create or rotation, then never returned again.
Agent API keys are one-time secrets. Store them only in your agent, MCP, or server environment.
Agent keys are scoped to one agent by default and cannot manage workspace agents.
Blocked automations should skip with a clear reason, not wait or retry forever.
Observe-only agents do not create active leases, so they measure risk but do not protect the repo yet.