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.

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",
    "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. `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 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.

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
}'

{
  "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.