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.
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.
Scheduling agents before booking
Secondary flow: ask for availability, preview the conflict, then create a hold only when the slot is safe.
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/nameSafest 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:homepageAdvanced 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.
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/sessionWork 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/finishScheduling 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_idActivity and diagnostics
Used to confirm real traffic, debug setup, and inspect system health without exposing secrets.
GET /v1/activityPOST /v1/activity/usageGET /healthPlan limits
How usage limits are counted
(resource_type, resource_key) saved in the workspace. Releasing a claim does not remove the resource.status='active' and expires_at still in the future.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.

