uw — the drafting page and the scoreboard

One read for the page and for a client: the HTML at /uw/p and this answer are built from the same state, so the two cannot disagree about a number. The drafted body is included, because the client's job is to show it. A key reads exactly what the owner's page reads: the answer's `scope` names `reads: "publisher"` and the account whose shelf answered.

Parameters

Request body

None: this operation takes its arguments in the path and the query.

Responses

Example

The scoreboard, the published snapshot's job list, and one job's two panes and history., with a token from the door.

curl -X GET 'https://zpe.vc/uw/_/api/v1/state?job=string' \
  -H 'Authorization: Bearer $ZPE_TOKEN'

{
  "ok": false,
  "schema": "string",
  "published_at": "2026-10-31T09:00:00Z",
  "snapshot_id": 0,
  "window": {},
  "scoreboard": {},
  "corpus": {},
  "jobs": [
    {}
  ],
  "job": null,
  "agent": null,
  "owner": null,
  "history": [
    {}
  ],
  "against_agent": null,
  "scope": {
    "account_id": null,
    "organization_id": null,
    "organization_name": null,
    "role": "string",
    "via": "session",
    "reads": "organisation"
  }
}

The example is generated from the schema in the contract: the shape is the document's, the values are placeholders.

The only write on this surface. It appends a row and never updates one: a version that can be edited is a version that can be made to agree with whatever happened afterwards. The page's own button posts the same fields as a form and is answered with a 303 back to the pane; a client posting JSON is answered 201 with the row it wrote.

Parameters

Request body application/json · required

Responses

Example

Append his version of one job's letter, once per idempotency key., with a token from the door.

curl -X POST 'https://zpe.vc/uw/_/api/v1/save' \
  -H 'Authorization: Bearer $ZPE_TOKEN' \
  -H 'content-type: application/json' \
  -d '{
  "job_ref": "string",
  "body": "string",
  "note": "string",
  "idempotency_key": "string"
}'

{
  "id": "string",
  "version": null,
  "words": 0,
  "at": "2026-10-31T09:00:00Z",
  "against_agent": null
}

The example is generated from the schema in the contract: the shape is the document's, the values are placeholders.

The session's own shelf: the organisation the door named and the role it gave decide which rows answer, so a second organisation sees none of the first's. A client reading this sees exactly the versions the page would draw. A KEY reads the publisher's shelf, which is the owner's: the same rows his page draws. `make pull` uses the token-only pull at `/_/publish/drafts`, which is scoped to the deployment's own publisher.

Parameters

Request body

None: this operation takes its arguments in the path and the query.

Responses

Example

The drafts this session may read, oldest first., with a token from the door.

curl -X GET 'https://zpe.vc/uw/_/api/v1/drafts?job=string&since=0' \
  -H 'Authorization: Bearer $ZPE_TOKEN'

{
  "ok": false,
  "drafts": [
    {
      "id": 0,
      "job_ref": "string",
      "body": "string",
      "words": 0,
      "note": null,
      "account_id": "string",
      "organization_id": null,
      "created_at": "2026-10-31T09:00:00Z"
    }
  ]
}

The example is generated from the schema in the contract: the shape is the document's, the values are placeholders.

THE RECORD, READ FORWARD. Every state change writes one row to this account's outbox in the same transaction as the change it describes, and this read walks those rows by the event's own id: a keyset, never an offset. `since` names a row rather than a position, so an event written between two pages is in the page it belongs in instead of shifting one out of it, and a reader that follows `next_cursor` sees every event once and none twice. Ordering is by id, which is monotonic, so two events written inside the same second — or the same minute — keep the order they were written in. `next_cursor` is null when this page is the last one the record holds; pass it back as `since` to continue. A `since` that is not an id this account holds is REFUSED, because a cursor silently read as "the beginning" makes a consumer re-read the record and never learn that it had. The record is the account's own: a session reads what it wrote, and a key reads the publisher's shelf. An event carries ids, refs and the numbers that moved, never a letter's body.

Parameters

Request body

None: this operation takes its arguments in the path and the query.

Responses

Example

This account's record after one event's id, oldest first, one page at a time., with a token from the door.

curl -X GET 'https://zpe.vc/uw/_/api/v1/events?limit=50&since=0' \
  -H 'Authorization: Bearer $ZPE_TOKEN'

{
  "ok": false,
  "events": [
    {
      "id": 0,
      "kind": "proposal.changed",
      "subject_ref": "string",
      "at": "2026-10-31T09:00:00Z",
      "payload": null
    }
  ],
  "next_cursor": null
}

The example is generated from the schema in the contract: the shape is the document's, the values are placeholders.

The row the page writes is the row the page polls. `state` is `pending`, `claimed`, `done` or `refused`, and it is written only by the runner: a client that reads `done` is reading what the machine reported, never a guess made here. A refused row carries the sentence that refused it (`result.reason`) and no preview. A KEY reads the publisher's rows, which is how the fleet puts the exact letter and Upwork's preview in front of the owner before anything is sent.

Parameters

Request body

None: this operation takes its arguments in the path and the query.

Responses

Example

One send request's state, for the page and for a client polling it., with a token from the door.

curl -X GET 'https://zpe.vc/uw/_/api/v1/send?id=0&job=string' \
  -H 'Authorization: Bearer $ZPE_TOKEN'

{
  "ok": false,
  "request": {
    "id": 0,
    "kind": "prepare",
    "state": "pending",
    "job_ref": "string",
    "requested_by": "string",
    "at": "2026-10-31T09:00:00Z",
    "claimed_at": null,
    "run_by": null,
    "rate": null,
    "body": null,
    "terms": null,
    "preview": null,
    "result": null,
    "prepare_id": null,
    "wait_seconds": 0
  }
}

The example is generated from the schema in the contract: the shape is the document's, the values are placeholders.

THE WORKER CANNOT SEND, AND THAT IS THE DESIGN. The Upwork credential lives on the machine that owns the ledger, so this route records an INTENTION. A `prepare` asks the machine for Upwork's preview — the exact text, the Connects, and any screening questions — and a `confirm` names the prepare row whose preview the person saw. A runner on the machine claims the oldest pending row, calls Upwork, and writes `done` or `refused` back; the state is asynchronous by construction and is answered within about a minute (`wait_seconds` names the wait). Nothing here submits anything. A confirm carries no letter: the text a person authorised is the preview's, and a body posted with a confirm is refused.

Parameters

No parameters.

Request body application/json · required

Responses

Example

Queue a send request: a prepare (Upwork's preview) or a confirm (the submit)., with a token from the door.

curl -X POST 'https://zpe.vc/uw/_/api/v1/send' \
  -H 'Authorization: Bearer $ZPE_TOKEN' \
  -H 'content-type: application/json' \
  -d '{
  "kind": "prepare",
  "job_ref": "string",
  "rate": 0,
  "body": "string",
  "answers": [
    {}
  ],
  "estimated_duration": "string",
  "payment_mode": "string",
  "milestones": [
    {}
  ],
  "prepare_id": 0,
  "room_ref": "string"
}'

{
  "ok": false,
  "id": 0,
  "kind": "prepare",
  "state": "pending",
  "job_ref": "string",
  "wait_seconds": 0
}

The example is generated from the schema in the contract: the shape is the document's, the values are placeholders.