Skip to main content

Tickets and comments

Use ticket methods for integration questions, payment investigations, disputes, and other support conversations. Tickets are merchant-scoped and return only merchant-visible fields, comments, and attachments.
Prerequisites: use tickets.create to create a ticket, tickets.read to read it, tickets.update to edit/reopen it, and tickets.comment to write comments.

Methods

All methods are sent to POST /public/api/multihub/v1. Do not include service_id.

Categories and priorities

Allowed categories are payment_issue, integration, limits, account, bug, question, dispute, refund_request, and other. payment_issue, dispute, and refund_request require a merchant-owned payment reference. payment_issue also requires at least one previously verified attachment. A payment can have only one non-deleted ticket; a duplicate returns the existing ticket’s public identifier and status. You can set low, medium, or high; the default is medium. Responses can also contain operator-assigned urgent priority.
ticket.create with category refund_request opens a support conversation. It never moves money. Use refund.request for a monetary refund.

Create a ticket

The merchant c_id is the idempotency key for creation. For a payment investigation, upload and finalize evidence first, then reference the ready attachment IDs.
A ticket projection contains no staff identities or internal workflow fields:
Ticket statuses are open, in_progress, waiting_customer, on_hold, resolved, closed, and canceled.

Read and list tickets

Read one ticket with exactly one public identifier:
ticket.list accepts statuses, categories, priorities, one payment reference, created_from, created_to, limit, and cursor. Dates are ISO 8601 timestamps. Results are ordered newest first and return items plus next_cursor; there is no total.
Use ticket.summary with optional created_from and created_to to receive by_status counts.

Edit and reopen

Description edits and merchant-authored comment edits use a stable top-level operation_id. They are allowed for one hour after the original item was created. Support-authored content cannot be edited through the public API.
Only resolved or closed tickets can be reopened:

Comments

Create a comment with an operation key. Optional attachment IDs must have purpose ticket_comment and status ready.
List comments with ticket.comments.list; only merchant-visible comments are returned. Each comment has its own UUID identifiers.h_id, an author value of merchant or support, timestamps, and safe attachment projections.

Error handling

Best practices

  • Use one stable c_id per support case, not a title or customer-provided string that can collide.
  • Store only the public projection; do not depend on staff assignment, tags, or internal lifecycle details.
  • Refresh the ticket after webhook notifications because event payloads intentionally omit comment bodies and staff data.
  • Treat a 404 as tenant-safe: it never reveals whether another merchant owns that identifier.