Laver
Sign in Start free

Agents and the API

Let an agent
run your board.

Most tools treat automation as a rules engine bolted to the side: if this, then that, running as nobody in particular with permissions somebody set up once. Laver 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

14-day trial · £2.49 per seat per month · 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

  • Deltas against the server's clock

    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.

    Driving a board by API

HONEST FIT

What this is not.

This is an API an agent can drive safely. It is not an automation product.

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 than maintain a listener.

Not what this is

  • No rules builder. There is no "when X then Y" in the interface. You write the agent.
  • No outbound webhooks, no marketplace, no integrations.
  • 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.

Start your free trial

Keep reading