Laver
Sign in Start free

Agents and the API

Let an agent
run your board.

Most tools stop at a rules engine bolted to the side: if this, then that, running as nobody in particular with permissions somebody set up once. Laver has those rules too, per board and built in the interface — and past where they end, it treats an agent as a colleague: it has an access level, it belongs to a person, and it can be switched off with them.

Create your workspace API quickstart

Free for one workspace, 3 boards and 100 MB · £2.99 incl. VAT per seat per month beyond that · viewers are free

WHY THIS IS USUALLY AWKWARD

The bot with
nobody's permissions.

The problems are not about the API surface. They are about identity and about two writers touching one record.

  • A second permission model

    The integration has its own scopes, its own tokens and its own idea of who can see what — maintained separately from the membership list, and quietly diverging from it.

  • Last write wins

    A person drags a card while a script updates it. One of the two changes silently disappears, and nothing anywhere records that it happened.

  • Polling that misses things

    "What changed since I last looked?" answered against the client's own clock, which is wrong by enough to drop the write that landed mid-query.

WHAT LAVER DOES

One permission model.
Version on every write.

Anyone can issue a key for themselves — no admin, no ticket, no approval queue.

  • A key is a person

    A workspace-scoped API key acts as the user who created it and inherits their board access. There is no second permission model, so there is nothing to keep in step — and deactivating that member disables their keys with them.

    A key is confined to the one workspace it was made for. A request against another gets a 403, even one its owner belongs to.

    API keys

  • Concurrency you can rely on

    Every write carries the version it expects. A mismatch is a 409 whose body carries the current version, so a retry never needs a board fetch — and a person and an agent cannot silently overwrite each other.

    curl -X PATCH https://api.laver.app/tasks/7f2a… \
  -H "Authorization: Bearer $LAVER_API_KEY" \
  -d '{"version": 4, "status": "In progress"}'
    Concurrency and polling

  • Poll for changes, or be told

    Every board read returns server_time. Hand it back as updated_since and you get what changed, without trusting your own clock — the cursor is read before the rows it describes, so a write landing mid-query is re-delivered next poll rather than missed.

    Or register an HTTPS endpoint and Laver posts to it when a ticket, comment or wiki page changes. Payloads are signed, a delivery that fails is retried five times over a widening gap, and every attempt is kept in a log you can read.

    Outbound webhooks

BEFORE YOU WRITE ONE

Not everything
needs an agent.

Two of these need no code at all. Reach for a key once you are past the end of both.

  • Rules, built on the board

    Each board carries its own automation rules: a trigger, optional conditions, and actions that move, assign, label, prioritise, date, comment on, archive or link a ticket. A rule can fire on an event, on a schedule, when a due date arrives, when a ticket has sat in one column too long, or from a button on the ticket itself.

    Every run is recorded with what it changed. 2 rules per board on the free plan.

    Automations

  • An assistant, with no client to write

    @laver/mcp is an MCP server. One config block and an API key give Claude Desktop, Claude Code, Cursor or any other MCP client tools for reading and driving boards, tickets and the wiki — the same key, the same board access, the same version on every write.

    MCP server

  • A key, for everything else

    Rules are a closed vocabulary on one board, and an MCP client acts when somebody asks it to. Work that needs its own judgement, its own schedule or its own code is what the rest of this page is about.

THE WORKING LOOP

One board,
two kinds of colleague.

The three mechanisms above are one loop in practice. A person opens the access, an agent works inside it, and the board is the single place either of them looks.

How an agent works a Laver board, in four steps.

  1. A person opens the access

    An API key is created by someone and acts as them. It inherits the boards they can already see — there is no second permission model to keep in step, and nothing to grant twice.

  2. The agent claims and writes

    It reads a ticket, gets a version, and sends that version back with the write. No guessing about whether it is safe to act: the board answers that.

  3. A clash is an answer, not a silence

    If somebody moved the ticket first, the write is refused with a 409 and the current version. The agent re-reads and decides — instead of quietly overwriting a person's work and nobody finding out until standup.

  4. The person keeps the controls

    Every move the agent makes lands in the same history as everyone else's, on the board you were already looking at. Revoke the key, or remove the person, and the agent stops with them.

HONEST FIT

What this is not.

Rules for the ordinary cases, and an API an agent can drive safely past them. It is not an integration platform.

A good fit when

  • You are writing the agent, and you want it to be a member of the team rather than a webhook.
  • Agents and people work the same board and you need writes to be safe.
  • You would rather poll a documented endpoint, or receive a signed webhook, than wire up an integration platform.

Not what this is

  • No scripting inside a rule. The builder offers the triggers, conditions and actions Laver defines, on one board at a time, with a ceiling on how many actions one rule may carry. Past that list, you write the agent.
  • No marketplace and no prebuilt integrations. Webhooks post to an endpoint you write and host.
  • A key cannot mint another key — /profile and /admin take session tokens only.
  • A ticket moved to another board leaves no trace in a delta, so re-read the board occasionally.

READY WHEN YOU ARE

Give automation a seat
at the table.

Issue yourself a key in a minute and point something at a board. This site's own tickets are worked that way.

Create your workspace

Keep reading