Automate

Three tools keep work going without you starting each run:

• Schedules start a run at set times.
• Backlog holds tasks Syndai finds for you to start.
• Webhooks tell your server when a run changes.

Every path below starts with https://api.syndai.ai/api/v1/external/coding.

Schedules

A schedule runs a saved prompt on one project at set times. Each fire is a normal run, so it costs credits. Your key needs coding:schedules:manage.

curl -s -X POST https://api.syndai.ai/api/v1/external/coding/schedules \
  -H "Authorization: Bearer $SYNDAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "client_request_id": "weekly-deps-001",
    "coding_repository_id": "<REPO_ID>",
    "prompt": "Update dependencies and fix anything the upgrade breaks.",
    "trigger": {"kind": "cron", "expr": "0 9 * * 1", "timezone": "Europe/London"},
    "occurrence_budget_usd": 10
  }'

• trigger is a 5-part cron with a time zone, at most every 15 minutes. A run starts within 5 minutes of its slot.
• client_request_id makes the create safe to retry. A repeat answers 409 with Location set to the first schedule.
• occurrence_budget_usd caps what each fire may spend.
• from_coding_run_id repeats a run that went well. Leave out prompt and coding_repository_id with it.
• skip_if_no_new_commits is true unless you say so. A slot rests while the default branch has not moved.
• Scheduled runs never ask questions and never wait for a spec review.

Spend needs a person's yes

A fire spends nothing until schedule_paid_on is true. Only an owner or admin, or a key one of them made, may turn it on. It also needs occurrence_budget_usd. A fire without that yes does not run.

When the workspace is out of credits, or over its monthly limit, a fire is skipped. Its summary says why, and the next slot tries again.

Supervised or on its own

policy_config.autonomy on the schedule says how far each fire goes:

autonomy	each fire
auto	opens a pull request. The next slot rests while it is open.
gated	waits up to 24 hours for approval before a pull request exists
merge	lands when every gate is green
push	moves the default branch with no pull request (API only)

A schedule may merge only while the key or person who saved its policy still may. Revoke that key, or drop that person to member, and each fire opens a pull request instead.

Manage it

call	does
GET /schedules/{id}	the schedule and its recent fires, each with the run it started
PATCH /schedules/{id}	changes the prompt, trigger, policy or budget
POST /schedules/{id}/pause	stops the fires until you resume
POST /schedules/{id}/resume	starts again from now. Missed slots do not run.
POST /schedules/{id}/run-now	fires once now, even while paused
DELETE /schedules/{id}	deletes it

Each call is on the Schedules reference page.

Backlog

Syndai files tasks it finds as offers. They come from a finished run's next steps, scans for bugs, search moves and more. An offer never runs on its own.

GET /backlog lists the top offers. Each one has a source, which is an open string. Viewing and dismissing are free.

To start one, send its id as backlog_task_id when you create a run:

curl -s -X POST https://api.syndai.ai/api/v1/external/coding/runs \
  -H "Authorization: Bearer $SYNDAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "prompt": "Fix the broken link in the footer",
    "coding_repository_id": "<REPO_ID>",
    "backlog_task_id": "<OFFER_ID>",
    "external_request_id": "offer-footer-link-001"
  }'

To drop it for good, call POST /backlog/{id}/dismiss, with an optional reason.

The roadmap

A person can also put an offer on the project's roadmap. These calls need a signed-in person. An API key gets 403.

call	does
POST /backlog/{id}/accept	adds it to the roadmap with the text you saw
PATCH /backlog/{id}	adds it with your own title or prompt
POST /backlog/{id}/top	adds it at the top

The roadmap is worked from the top only when the workspace has turned on runs on its own. Otherwise it waits for you.

Groups

One chat message can ask for 2 to 5 separate changes. Syndai files them as one group, and a part may build on an earlier part.

• GET /backlog/groups lists them, with each part's status.
• POST /backlog/groups/{id}/start starts every part that is ready. Later parts start as the ones they build on land. Each part is a paid run. It is a person's tap: the project agent gets 403 HUMAN_APPROVAL_REQUIRED.
• POST /backlog/groups/{id}/dismiss skips the group, or one part. Running parts keep going.

Each call is on the Backlog reference page.

Webhooks

A webhook sends a signed POST to your server when a run changes. Use it in place of polling. Add an endpoint with POST /webhooks, pick the events you want, and check every signature.

Webhooks has the full guide: the events, the body, signatures, retries and redelivery.