Action Board API

Export accessible active Action Board tasks into reporting or task-integration systems. The API returns saved task information, including completed tasks that remain on the active board. It does not create, update, archive or delete tasks.

Create with POST https://app.wheremore.com/api/v2/exports/action-board . Retrieve with GET https://app.wheremore.com/api/v2/exports/{export_id} . This guide describes data contract 2026-09-19 . See API Access and API Keys for credentials and shared export behaviour.

Select tasks

Copy the public workspace ID from API Access → Your Workspaces and Markets. By default the export selects accessible tasks across projects in that workspace. Optionally narrow it by project, status, priority, tag or update time.

Use numeric project/tag IDs from the corresponding Wheremore configuration or your workspace administrator. This API does not provide public project/tag listing endpoints. Only permitted tags are returned with a task.

Request fields

Unknown fields are rejected. Do not send status: "all" , priority: "all" , date-range fields or archive/draft flags. Omit optional IDs rather than passing zero.

Create and retrieve a page

Replace the example IDs. Set WHEREMORE_API_KEY  securely before running the command.

curl --fail-with-body -X POST \
  "https://app.wheremore.com/api/v2/exports/action-board" \
  -H "X-API-Key: ${WHEREMORE_API_KEY}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: board-export-20260919-page1" \
  -d '{
    "workspace_id": "ws_your_workspace_id",
    "project_id": 12,
    "status": "todo",
    "priority": "near-term",
    "limit": 100,
    "data_contract": "2026-09-19"
  }'

Save export.id  from the POST response. Creation returns metadata only and is free; 201 means ready, while 202 means pending. Retrieve the page with:

curl --fail-with-body \
  "https://app.wheremore.com/api/v2/exports/exp_0123456789abcdef0123456789abcdef" \
  -H "X-API-Key: ${WHEREMORE_API_KEY}"

A pending GET returns 202 for free; a ready GET returns 200 with the saved data . Reuse the same idempotency key only to retry that exact POST. Each new page or later synchronization needs a new key.

Response fields

The data object contains data_contract , workspace_id , effective filters , tasks , total_returned  and pagination.next_cursor . total_returned  is this page's count, not a full-board total.

This is an illustrative data object, without the shared response envelope:

{
  "data_contract": "2026-09-19",
  "workspace_id": "ws_your_workspace_id",
  "filters": {
    "project_id": 12,
    "status": "todo",
    "priority": "near-term",
    "tag_id": null,
    "updated_after": null,
    "limit": 100
  },
  "tasks": [
    {
      "id": 501,
      "type": "manual",
      "title": "Review the signup page",
      "description": "Check the current instructions.",
      "current_state": null,
      "recommended_action": null,
      "status": "todo",
      "priority": "near-term",
      "position": 0,
      "due_date": null,
      "section": null,
      "page_url": "https://example.com/signup",
      "project": {"id": 12, "name": "Website improvements"},
      "keyword": null,
      "assignee": null,
      "tags": [],
      "origin": {"type": "user_created", "source": null},
      "created_at": "2026-09-18T10:00:00Z",
      "updated_at": "2026-09-18T10:00:00Z"
    }
  ],
  "total_returned": 1,
  "pagination": {"next_cursor": null}
}

Saved text is not new analysis generated by the API. A recommendation is a proposed action; done  does not prove implementation, successful measurement or a causal improvement. Escape task text before displaying it.

What is excluded

The endpoint selects active todo , doing  and done  tasks and excludes archived tasks. It does not return archive history, structured evidence payloads, implementation/outcome/measurement records, draft/outline content or internal user IDs.

The obsolete has_draft  field is removed from new exports. Content Bank owns outlines and drafts; absence of a board field says nothing about whether related content exists there. Saved task text can still mention measurements or evidence as part of its instructions.

Pagination

Pages are ordered by ascending task ID. If data.pagination.next_cursor  is non-null:

1. Keep the same workspace and filters.
2. Create a new export adding the returned cursor .
3. Use a new idempotency key for that page, and retrieve its export ID.
4. Continue until next_cursor  is null.

Treat cursors as opaque. They are continuation markers, not credentials or a frozen multi-page dataset. Each page is saved separately; edits, additions, permission changes or archiving between requests can change later selections. Repeated GETs of a saved page remain identical.

Incremental synchronization

updated_after  is a strict greater-than filter, normalized to UTC seconds. It is not a deletion or archive feed.

For a periodic integration, keep a successful synchronization watermark and use a small overlap when choosing the next updated_after , so same-second updates and timing boundaries are not easily missed. Record the run's start time, retrieve all pages, and upsert by task ID. Advance the watermark only after every page succeeds; retry failed pages with their existing idempotency keys. The overlap can cause repeated tasks, so process updates idempotently.

Periodically reconcile with a complete accessible-board export if your application must identify missing active tasks. Disappearance alone does not prove deletion: a task might be archived, moved or outside current permissions. Concurrent changes mean neither paginated method is a transactionally complete board snapshot.

Charges, retention and permissions

Each non-empty page costs 0.5 credits on its first successful GET, whether it contains one task or 100. Empty pages are free. A smaller limit  can increase the number of paid pages; use up to 100 when response size allows. Repeated GETs of the same paid export are free and return identical data.

Exports expire seven days after creation. The saved-payload limit is 8 MiB; reduce the page size or narrow filters if it is exceeded.

Every retrieval rechecks workspace access and projects/tags represented in the saved payload. Revocation can block retrieval even if that export was previously charged. The endpoint does not redact and rebuild a paid snapshot after permissions change.

Troubleshooting

• No tasks: remove optional filters, check the workspace/projects and update cutoff, and remember that archived tasks are excluded. An empty successful export is free.
• 400: verify exact status/priority values, positive IDs, cursor and timezone-bearing timestamp. Omit unsupported fields.
• 404 for a project or tag: confirm it is accessible and belongs to the selected workspace.
• 403 export_access_revoked : current workspace/project/tag permissions no longer permit the saved snapshot.
• 413: reduce limit  or narrow filters, then create a new export.
• A later GET still shows the old task: expected; create a new export for updated board data.
• More charges than expected: count distinct non-empty page exports, not GET retries or individual tasks.

Use API Access and API Keys for authentication, credit failures, callbacks and retry handling. Use the Action Board and Content Bank guides for managing tasks and saved content in Wheremore.