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 the payload shape and the caller's access to the fund, then returns requestId immediately.

An unauthorized caller or a structurally invalid payload is therefore rejected synchronously, before any job is created — no item is applied. Checks run in this order, and only the first failure is reported:

• 400 VALIDATION_FAILED — the request breaks a documented schema bound: items outside 1–100 entries, an item's comments outside 1–100, or a comment body over its maximum length. Schema validation sees the whole payload at once and runs before anything else — a request that is both out-of-bounds and unauthorized gets this 400, not the 403.
• 403 PERMISSION_DENIED — the service account is not a fund manager on the fund in the URL. Fund permission is identical for every item, so it is a precondition of the request rather than a per-item outcome. A fund id that does not exist — typed or custom — gets the same 403; the response never reveals whether the fund is real.
• 400 INVALID_THREAD_ID — some item's threadId is not a well-formed thread id. A malformed id can never start parsing on a retry, so the message names the first offending index (items[3]); fix every malformed id before resubmitting.

Everything that genuinely varies per item — thread existence, the fund↔thread binding, per-order and per-visibility-tier permission, thread status, mention resolution, comment limits — is still evaluated inside the job, so one bad item never rejects the whole job. In particular a well-formed threadId that is unknown, deleted, or rooted in another fund is a per-item 404, not a request-level error. 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.

Resolved threads. An item targeting a thread whose status is resolved writes nothing and comes back Failed, with an error message telling you to reopen the thread — the same rule ImportComments applies, and for the same reason (the app hides the reply box on a resolved thread). Thread status varies from item to item, so this is never a request-level reject: a batch mixing open and resolved threads still returns 200 + requestId, the open items complete, and only the resolved ones are reported Failed. There is no public endpoint to reopen a thread — reopen it in the app and resubmit just those items.

Note that a failed item carries only status and a human-readable error. Bulk items have no machine-readable error code and no per-item HTTP status: the 409 and the THREAD_RESOLVED code documented on ImportComments belong to that synchronous endpoint only. To branch on the condition programmatically, read status from ListCommentThreads before submitting, or retry the item through ImportComments and inspect its 409.

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.