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 arepayment_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.
Create a ticket
The merchantc_id is the idempotency key for creation. For a payment investigation, upload and finalize evidence first, then reference the ready attachment IDs.
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.
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-leveloperation_id. They are allowed for one hour after the original item was created. Support-authored content cannot be edited through the public API.
resolved or closed tickets can be reopened:
Comments
Create a comment with an operation key. Optional attachment IDs must have purposeticket_comment and status ready.
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_idper 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
404as tenant-safe: it never reveals whether another merchant owns that identifier.
