WaymarqWaymarq
Sign up

Developers

REST API

A versioned JSON API at /api/v1, covering everything the web app itself is built on: projects, phases, tasks and subtasks, checklists and test plans, comments, time logs, file uploads, living documentation, clients, opportunities and quotes, work orders, statements, and read-only account-wide reports.

Authentication

A bearer token, created under Organisation settings → API. A token acts as the user who created it, with exactly the same permissions and policies as the web app — the same organisation scoping, and the same read-only restriction if that user has the viewer role. Tokens are shown once at creation and can be revoked at any time.

Two rules worth knowing before you start

Status changes go through their own endpoint. The general PATCH /tasks/{task} rejects a status field with a 422 — use PATCH /tasks/{task}/status instead, which writes the audit row the activity tab and project history both depend on. The same pattern applies to opportunities (PATCH /opportunities/{id}/stage) and work orders (PATCH /work-orders/{id}/status).

A redundant dependency is dropped, not kept. If you send depends_on_task_ids and one of them is already implied by another (A depends on B, B already depends on C — naming C on A too is redundant), it's silently pruned to keep the graph minimal. The response reports exactly what was dropped and why in pruned_dependencies, so a shorter list than you sent doesn't read as a bug.

Suggested flows

The reference docs list every endpoint; this is the shape of how they actually get used together. Each of these is a real sequence, not a hypothetical one.

Bootstrap a new project from a spec

The most common one — an AI agent turning a brief into a real, structured project.

  1. 1POST /projects — create the project.
  2. 2POST /projects/{project}/phases — one call per phase, in order.
  3. 3POST /phases/{phase}/tasks — one call per task, each with markdown_spec (a full sub-spec, not a one-liner), estimated_minutes, and depends_on_task_ids for its immediate prerequisite.
  4. 4POST /tasks/{task}/checklists — attach a test_plan checklist so the task carries concrete, checkable verification steps.
  5. 5POST /projects/{project}/schedule — turn every task's estimate and dependency order into real start/due dates in one call.

Everything created this way is an ordinary project the moment it exists — it shows up on the board, the Gantt chart, and the reports exactly like one built by hand. There is no separate "imported" state.

Keep a project current as work happens

An agent (or a script) that is doing the work, not just planning it.

  1. 1PATCH /tasks/{task}/status — the only way to change status; it writes the audit row that powers the activity tab, so a raw PATCH /tasks/{task} with a status field is refused with a 422 on purpose.
  2. 2POST /tasks/{task}/comments — leave a note on the task explaining a decision.
  3. 3POST /tasks/{task}/time-logs — log time in free text like "1h 30m".
  4. 4PATCH /checklists/{checklist}/items/{item} — tick off a checklist or test-plan step as it's verified.

A human opening the project later sees a real history — who moved what, when, and what they said about it — not just a final state with no trail.

Automate the sales-to-cash side

A script or agent handling the commercial side, not just the delivery side.

  1. 1POST /clients then POST /clients/{client}/opportunities — log the enquiry against the client.
  2. 2POST /opportunities/{opportunity}/quotes — build a line-item quote, then POST /quotes/{quote}/send to mint the client-facing accept link.
  3. 3When the client accepts it (no API call needed — they do this on their own no-login page), the opportunity is won and the project is created automatically.
  4. 4POST /projects/{project}/work-orders — record anything the client asks for outside the original scope, with what it was agreed to cost.
  5. 5GET /projects/{project}/unbilled then POST /projects/{project}/statements — gather finished work, billable time and expenses into a statement and issue it.

This is the arc a generic task API doesn’t have an opinion on at all — Waymarq’s is built around a studio or agency actually getting paid, not just tracking tasks.

Turn a support request into tracked work

A webhook or a scheduled job watching for new client-reported issues.

  1. 1GET /support/tickets?status=new — poll for anything a client has reported through their intake link (or subscribe to the support_ticket.received webhook event instead of polling).
  2. 2POST /support/tickets/{ticket}/accept — turns it into a real task on the client's support project, attributed to them automatically.

A ticket only becomes visible work once someone accepts it — nothing a client reports lands on your board unreviewed.

Pull reporting into your own dashboard

Anything that wants Waymarq’s numbers without a person opening the app.

  1. 1GET /reports/workload — open tasks per person, for a capacity check.
  2. 2GET /reports/time-log — logged time, split by billable, internal and non-billable.
  3. 3GET /reports/pipeline — win rate, deals by stage, and what's expected to close and when.

Combine this with a webhook (e.g. post a weekly digest to Slack) and you have a status update nobody had to write by hand.

Read the full reference

Every endpoint, every field, every validation rule.

For AI agents/api-docsFor humans/api/documentation