Operator Support
Operator Support
Open Operator Dashboard → Operator Support (/support-tickets). All active human staff in the authenticated operator can read and participate; no additional trade, wallet, market, or settlement scope is required. Backend API keys cannot access support conversations.
Tickets are private to your operator team and Polynion Support, not private to the employee who submitted them. Other operators cannot read them. These are support conversations, not Polyflight purchase tickets.
Create and find tickets
- Select New ticket.
- Choose Technical, Billing, Operations, or Other.
- Provide a clear subject (maximum 255 characters) and plain-text message (maximum 20,000 characters).
- Select Create support ticket, then Open conversation #… from the success state. The ticket is available to the whole active operator team.
Use list search and Open / Closed / All status filters, then Apply filters. Page size can be 20, 50, or 100. The list shows category, status, last-message time, and update time; Refresh retrieves current state. A loading error is not evidence that no ticket exists.
A failed create/reply request keeps the draft in the current page state. This is not persistent draft storage after navigation or a browser reload. Do not create multiple tickets just because a reply has not yet arrived; follow up on the existing conversation.
Follow the conversation
Open a ticket to read the chronological messages and open/close/reopen events. Polynion replies are labeled Polynion Support; operator messages show their operator-team author. Use Refresh to load new replies.
Send a follow-up while the ticket is open. When Polynion closes a ticket but the issue remains unresolved, select Reopen ticket before replying. Operator staff have no close action. If sending returns TICKET_CLOSED, refresh and reopen; the draft is retained in the page. If TICKET_NOT_FOUND appears, confirm the environment and operator account before escalating through your established contact.
Ticket state is conversation state only. Closing, reopening, or sending a message does not alter an order, wallet operation, payout obligation, market, or settlement. Support access does not grant Polynion Admin access or monetary-action permissions, and no response-time or email-notification guarantee is implied by the UI.
Include useful, minimal evidence
Always include:
- environment and operator name/ID;
- expected versus observed behavior and whether money movement may be affected;
- exact UTC timestamp window, plus the report's operator timezone/date filters when relevant;
- request path, HTTP status, and error/status code when available;
- one concrete affected example and any recent relevant configuration change.
Then add only the references needed for the workflow:
| Workflow | Evidence |
|---|---|
| Launch/user | Exact external user ID and sanitized launch error/correlation reference; no launch token. |
| Trade/redemption | Market ID, order ID, executed trade ID, redemption item ID when present. |
| Wallet / Market PnL | Source kind/ID, operation ID, original idempotency key, direction, amount/currency, remote receipt reference, and authoritative operator-ledger evidence. |
| Settlement | Month, timezone, generated timestamp, accounting version, warning counts, and relevant operation IDs. |
| Webhook | Event ID/type, endpoint ID, delivery ID, last status, sanitized response, and whether replay was already attempted. |
| Market Request (unreleased) | Request ID, exact submitted UTC schedule, status/review reason, and error code. |
Use Cash Flow Triage to collect redacted retained wallet records if you hold its additional read scopes. For an unknown wallet result, investigate the original idempotency key; do not trigger another payment under a new key to produce an example or clear a warning. A failed outcome can leave an unpaid obligation.
Never paste passwords, temporary staff passwords, API bearer tokens, launch tokens, webhook/wallet secrets, signing keys, unrestricted raw logs, or unrelated personal data. Messages are plain text; the UI does not provide attachment upload. Supply sanitized excerpts and evidence references rather than full dumps.
See Support escalation for the wider evidence checklist.
Source API
All routes require a human staff session and use the session's operator:
GET /api/operator/support-tickets
POST /api/operator/support-tickets
GET /api/operator/support-tickets/{id}
POST /api/operator/support-tickets/{id}/messages
POST /api/operator/support-tickets/{id}/reopen
There is no operator selector, ticket deletion, message edit, or operator-side close control in this workflow.
See the Support Tickets API reference for pagination, message limits, response objects, and closed-ticket handling.