Bulk-import comments across many threads (async)

Bulk-import comments across many threads of one fund — the asynchronous, batched form of ImportComments.

Note: This API requires additional fund configuration to be enabled. Please contact us if you would like to try it out.

The request carries up to 100 items, each addressed by a threadId (resolve order-level general threads first with CreateOrGetCommentThread, or discover existing threads with ListCommentThreads). Every thread must belong to the fund in the URL — an item whose threadId is outside the fund fails as a per-item 404. Items targeting the same thread are combined and imported together, in payload order. Per-item fields are identical to ImportComments (body with mention tokens, onBehalfOf, externalRef); notifyMode (default none; see ImportComments) applies to the whole job.

Per-item limits. Each item carries 1–100 comments (the same cap ImportComments applies per request), so one bulk job lands at most 100 items × 100 comments. The per-thread ceiling still holds: at most 200 stored comments per thread across all imports, and each comment at most 10,000 characters. Items may target different anchors (order general threads, form-question threads, …) — a single job can fan comments across many threads at once, and every item is reported in the status response.

The endpoint validates only the payload shape and returns requestId immediately. Everything per item — thread existence, permissions, mention resolution, limits — is evaluated inside the job, so one bad item never rejects the whole job. Threads are applied one at a time, each thread succeeding or failing independently. Items that target the same thread are imported together and share one outcome.

Poll GET requests/{requestId}/status for progress. The job reports InProcessing with per-item statuses (Pending / Completed / Failed) while running, and Completed when every item has finished — including jobs where some items failed (each failed item carries its own error). An item's comments are not applied atomically, so a Failed item may have landed some of its comments before failing. Comment ids are system-generated and import is not idempotent: blindly re-sending a failed item re-imports (duplicates) the comments that had already landed. Treat the commentIds in the status response as the authoritative record of what landed (completed items list their commentIds in append order), and read the thread back before retrying a partial apply.

Recent Requests
Log in to see full request history
TimeStatusUser Agent
Retrieving recent requests…
LoadingLoading…
Path Params
string
required

The Anduin ID of the Fund object, or your custom ID

Body Params
items
array of objects
required
length between 1 and 100
items*
string
enum
Allowed:
Responses

Language
Credentials
Header
URL
LoadingLoading…
Response
Click Try It! to start a request and see the response here! Or choose an example:
application/json