API reference · Dashboard

Bulk update conversations

Resolve, reopen or delete a batch of conversations.

posthttps://api.integrable.cloud/api/bots/{bot_id}/conversations/bulk

Authentication: Bearer token
Retries: Idempotency-Key
Body: application/json
Version: 2026-09-03

Every item reports its own outcome. A bulk endpoint that returns 200 OK after partially failing is worse than one that does not exist, because the operator believes it worked and finds out from a customer.

The batch is capped rather than queued. At 200 items this comfortably fits inside a request; the point at which it would not is the point at which the right answer is a job, not a longer timeout.

Path parameters

bot_idstringrequired

Headers

Idempotency-Keystring
A unique key of your choosing, so this request can be retried safely. The first request with a given key executes; every replay returns that first response unchanged, with Idempotent-Replay: true set.
Generate one key per action, not per session - reusing a key with a different body is refused with 422 rather than silently replaying the wrong answer. Keys are remembered for 24 hours. A request that failed releases its key, so a retry after fixing the payload runs normally.
Up to 255 characters

Request body

application/json · required

BulkConversationUpdate

actionstringrequired
One of: resolve, reopen, delete
idsarray of stringrequired
1–200 items

Responses

200OKapplication/json
BulkResponse
- failedintegerrequired
- resultsarray of BulkOutcomerequired
  3 fields · BulkOutcome
  idstringrequired
  okbooleanrequired
  errorstring | null
- succeededintegerrequired
5 response headers
RateLimit-Limit
Requests permitted in the current window.
RateLimit-Remaining
Requests left in the current window. Back off before it reaches 0.
RateLimit-Reset
Seconds until the current window resets.
X-API-Version
The dated version of the API contract that served this response, e.g. 2026-09-03. Pin against it; it changes only when a response shape changes incompatibly.
X-Request-ID
Quote this in a support request to identify the call.
422Validation error
The shared error envelope, served as application/problem+json with error.code set to validation_error. Its details name each field that failed and why.

Example request

curl

curl -X POST "https://api.integrable.cloud/api/bots/$BOT_ID/conversations/bulk" \
  -H "Authorization: Bearer $INTEGRABLE_API_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "action": "resolve",
    "ids": [
      "string"
    ]
  }'

Set INTEGRABLE_API_KEY and the path variables first. The same call from the TypeScript or Python SDK takes the same fields.

Example response

200 OK · application/json

{
  "failed": 0,
  "results": [
    {
      "error": "string",
      "id": "01a0652b-3713-7ea1-a6c9-2e895389ec34",
      "ok": true
    }
  ],
  "succeeded": 0
}

Generated from the schema above — the shape is exact, the values are placeholders.

Errors

Failures use one envelope on every endpoint, described in Retries, versioning and limits. The codes you are most likely to meet here:

validation_error · 422 — The payload was well-formed JSON but failed schema validation.
unauthenticated · 401 — The request carried no API key, or one the API could not verify.
forbidden · 403 — The key is valid, but it is not allowed to do this — either the scope is missing or the resource belongs to another workspace.
idempotency_key_reused · 422 — This `Idempotency-Key` was used before, for a request with a different body.
rate_limited · 429 — Too many requests in the current window. The limit is per workspace, and some endpoints add a per-bot limit on top.

More Dashboard endpoints

Something here wrong or missing? Tell us — the documentation and the API are maintained by the same person, so a correction is a fix rather than a ticket.