Allwallex API · v1

A conversation you can follow.

Open a support ticket, follow replies and keep a clear record of its resolution. Support belongs to the signed-in account. Merchant API keys cannot read or write conversations.

Testnet environment. Transactions use test assets and do not settle real payments.

01Open one ticket per issue

Choose a topic, describe the issue and optionally select a workspace you can currently access. Include a public transaction or order reference when useful. Never include passwords, private keys, recovery codes or API secrets. High priority requests triage; it does not promise a response time.

02Follow the conversation

Read ticket details, messages and status history through your authenticated app session. The requester retains their own conversation after leaving a related workspace. Other workspace members cannot read it. Workspace context is a name snapshot, not permission to inspect financial records.

03Resolve and reopen clearly

Active statuses are open, in_progress and waiting_for_user. Resolve or close a completed conversation. Explicitly reopen a resolved or closed ticket before replying, within thirty days. You can keep ten active tickets, create twenty-five per UTC day and send thirty messages per ticket per hour, including its initial message.

04Recover interrupted requests

Every write requires an Idempotency-Key. Save the original key and exact body before submission. Retry those values after a timeout or lost response; a replay confirms the original result and does not reapply its effects. Refresh the current ticket afterwards because later replies or status changes may already exist.

05Keep operational context private

Current authorized operators with recent admin passkey verification can reply publicly, add internal notes, assign a qualified operator and update status with an audit reason. Finance sees wallet, deposit, withdrawal and merchant topics. Security sees account, security and integration topics. Owner, operations and support see all topics. Internal notes and assignment metadata never enter the customer projection.

06Receive private notifications

Ticket creation produces an in-app notification. Public operator replies and operator status changes also queue essential email, when delivery is configured. Fixed email text does not contain the ticket subject or message. Internal notes do not notify customers. Support cannot authorize payments, refunds, signing or credential recovery. Add up to five available, scanned original uploads as attachmentIds on a reply. Attachment grants follow the original message visibility; internal-note files remain operator-only. See Files & exports for the binary upload workflow.

// Authenticated app-session endpoints. All POSTs require Idempotency-Key.
POST /v1/account/support
{
  "subject": "Question about a deposit",
  "category": "deposit",
  "priority": "normal",
  "message": "Please help me understand the current status."
}
GET /v1/account/support?status=active&limit=20
GET /v1/account/support/{id}
GET /v1/account/support/{id}/messages
GET /v1/account/support/{id}/history
POST /v1/account/support/{id}/messages
{ "message": "Additional information about the issue." }
POST /v1/account/support/{id}/status
{ "expectedStatus": "open", "status": "resolved" }

// Operator session, current category authorization and recent admin MFA:
GET /v1/admin/support?assigned=mine&status=active
GET /v1/admin/support/operators?category=deposit
GET /v1/admin/support/{id}
GET /v1/admin/support/{id}/messages
GET /v1/admin/support/{id}/history
POST /v1/admin/support/{id}/messages
{ "visibility": "public", "message": "We are reviewing the issue.", "nextStatus": "waiting_for_user" }
POST /v1/admin/support/{id}/assignment
{ "expectedVersion": 1, "assigneeId": null, "priority": "normal", "reason": "Returning this ticket to the shared queue." }
POST /v1/admin/support/{id}/status
{ "expectedVersion": 2, "status": "in_progress", "reason": "Investigation is underway with the operations team." }

Open your workspace