API resources, IDs, pagination, and errors

The v1 API supports the resources below. Manage other Sydnee features in the app.

Which resources are available?

• Accounts: create, list, read, and archive client accounts.
• Account users: list account members, add a portal user, and remove account access.
• Task boards: list, create, archive, restore, and set a default board.
• Task Board status updates: read update history, publish a status update, read its comments, and add a comment.
• Sections and tags: manage board sections, board-local tags, and their order.
• Tasks: list, create, read, move, update, archive, and manage supported subtasks, tags, reminders, assignees, collaborators, comments, attachments, and activity. The API can also prepare and confirm a task attachment upload. It can delete task attachments created through the public API.
• Task templates: list templates and add one to an account or one account task board.
• Request templates: list templates and send one to a portal user.
• Requests: read the current status and fields for one Request. Each field includes its latest saved answer. Sensitive answers stay hidden. File answers link to file details and downloads.
• Files: list folders and files. Read file details, versions, and comments. Get download URLs. Upload account files and add new file versions.

Public file writes cover account file and new-version uploads. File rename, file delete, and file comments remain in the app. Learn how to upload files and task attachments.

The live API reference owns the deployed route and field list.

Read comment reactions

File, Task, and status-update comment reads include a reactions array. Status updates also include it. Task activity also includes this array on comment items. Each entry shows the emoji, when it was added, and who added it:

{
  "emojiKey": "1f44d-fe0f",
  "emoji": "👍️",
  "createdAt": "2026-10-01T18:00:00.000Z",
  "actor": { "id": 2903, "kind": "portalUser", "name": "Jordan Client" }
}

actor.id is the account user ID from GET /v1/accounts/{accountId}/users. actor.kind is teamUser or portalUser. The list has every reaction that can be shown for each comment. It is empty when none exist. It sorts by emojiKey, added time, then actor ID. Task and status reactions show people who still have the required access. A file reaction can keep its actor's name after their access changes. Missing or out-of-account actors are excluded.

Existing comment IDs, authors, and content keep their current formats. Read the live API reference before using a field in your app. These reads do not add API actions for adding or removing reactions.

The reaction webhook uses the same terms: reaction_emoji_key matches emojiKey, reaction_emoji matches emoji, and actor_type and actor_id match the actor kind and account user ID.

Read and post Task Board status updates

These routes use this prefix:

/v1/accounts/{accountId}/task-boards/{boardId}

The account must be active and enabled for reads and writes. The board needs to be active for writes. The board's Overview also needs to be enabled. Reads can return history from an archived board or a board with Overview off. Deleted boards and internal Project boards are unavailable.

Publish with a status and optional HTML text:

{
  "status": "ON_TRACK",
  "update": { "format": "html", "html": "<p>Review is complete.</p>" },
  "comingNext": { "format": "html", "html": "<p>We will send the final files.</p>" }
}

Allowed statuses are ON_TRACK, AT_RISK, OFF_TRACK, ON_HOLD, COMPLETE, and DROPPED. AT_RISK, OFF_TRACK, and ON_HOLD need an explanation in update. Other statuses can omit it. The API cleans the HTML before saving it. An explanation needs readable text after that step.

Post a comment with readable HTML text:

{
  "content": { "format": "html", "html": "<p>Ready for the next step.</p>" }
}

Both POST routes return 201. Posting an update returns { statusUpdate } and adds to history. It changes the board's current status and sends no publish alerts. Posting a comment returns { comment }. It follows the discussion's normal alert rules. Each POST creates new content. A retry after a successful request can create another update or comment.

API authors appear as System. The author object is { id: null, kind: "system", name: "System" }. Human authors use an account user ID, teamUser or portalUser, and a name. A removed human author can be null. The owner grants access for the API call. They are not returned as its author.

Update and comment results include the full reaction list. They also include an href for the exact API read. Text is returned as { html, plainText }. Dates use ISO format. Update results also count the comments still present. Lists return newest first and use the cursor rules below. Editing and deleting these resources through the API are outside this release.

The live API reference shows which methods are deployed. Status publishing and comments are available through these methods without a separate rollout switch.

Which ID should I send?

Use the ID returned by the endpoint that listed or created the resource. Do not build an ID from a name, slug, URL, or database guess.

An account user's ID is not the same as the person's portal-user ID or email. A file's current ID can also differ from an older version ID. Follow the exact schema for the route you call.

Use GET /v1/accounts/{accountId}/requests/{requestId} to read a current Request. The response doesn't include answer history or updatedAt. An answer’s createdAt is when Sydnee saved that answer. The response includes all active fields. It can include a hidden field with a saved answer because this endpoint doesn't run conditional logic.

How does pagination work?

Cursor pagination is used by supported list routes, including accounts, task activity, task comments, file lists, file comments, status updates, and status-update comments.

1. Send the first request with an optional limit. Supported paged routes return 50 items by default and allow 1 to 200.
2. Read nextCursor from the response.
3. Send that exact value as the next request's cursor.
4. Stop when nextCursor is empty or missing.

Some responses also return a Link header with rel="next". A cursor is opaque. Do not decode, edit, or reuse it with another route or filter.

Not every list route uses a cursor. Check the endpoint in the live reference.

What are the rate limits?

Current /v1 limits are shared by the workspace:

• 300 GET requests per minute;
• 100 write requests per minute.

Each API key can prepare 20 uploads per minute.

A limited request returns 429. Follow Retry-After. The response can also include X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset.

What does an API error mean?

Errors use this basic shape:

{
  "error": {
    "code": "400",
    "message": "Validation failed",
    "issues": []
  }
}

• code is a string.
• message explains the main problem.
• issues can point to invalid fields.
• details can hold a safe conflict code or current value.
• id can appear as a support or error-trace value.

Common status codes are:

Next step

• API quickstart and authentication
• Open the generated API reference
• Upload files, versions, and task attachments
• Type and verify outbound webhook events
• Fix API and Zapier problems