---
title: "Bulk-reply to tickets"
url: https://docs.gleap.ai/en/reference/rest-api/bulk-reply-tickets
method: POST
path: "/tickets/bulk/reply"
api: "API Reference"
tag: "Ticket"
operationId: "BulkReplyTickets"
updatedAt: "2026-11-01T18:40:15.677Z"
language: en
---

# Bulk-reply to tickets

`POST https://api.gleap.io/v3/tickets/bulk/reply`

Send the same customer-visible reply to every ticket in the selection. Unlike bulk updates there is NO fast path — every reply runs the full createComment pipeline (channel/email delivery, notifications, SLA clearing, workflows, integrations). Selections up to 30 send inline; larger ones (up to 500) fan out as per-ticket scheduled replies firing ~60s later, delivered by the Bull worker with the reconcile-sweep backstop and cancellable per ticket until they fire.

## Authorization

- `Authorization` (header, required): `Bearer <token>`

## Headers

- `project` (string, required)

## Request body (`application/json`, required)

- `selection` (object, required)
  - `ids` (string[]): Explicit ticket ids (checkbox selection).
  - `query` (object): "All matching" — the same raw query-param shape the lane's GET /tickets uses.
    - `sort` (string)
    - `filter` (string)
    - `status` (string, required)
    - `type` (string, required)
  - `limit` (number<double>): Select-N: only the first N tickets in the query's sort order. Query mode only.
- `comment` (any, required): TipTap JSON document — same shape as a single reply's `comment`.
- `batchId` (string): Client-generated idempotency key. Retries with the same batchId never double-send: every created comment is deduped per ticket via `data.clientMutationId = bulkreply_<batchId>_<ticketId>`.

## Example request

```bash
curl --request POST \
  --url https://api.gleap.io/v3/tickets/bulk/reply \
  --header 'Authorization: Bearer <token>' \
  --header 'project: <project>' \
  --header 'Content-Type: application/json' \
  --data '{
  "selection": {},
  "comment": null
}'
```

## Responses

### 200 (`application/json`)

Ok