Tickets and Support

Open /tickets after signing in to communicate with administrators. Tickets are best for payment verification, log diagnosis, and account-specific context. Check the docs and Troubleshooting first for common setup questions.

Creating a ticket

Provide a title, category, priority, and first message. Categories cover account, payment, API, model, billing, and other issues. Priorities are low, normal, high, and urgent.

A useful ticket includes:

• Failure time and timezone.
• Endpoint, model, and group name.
• Sanitized API Key name, never the full Key.
• HTTP status, error message, and request_id.
• Order number, payment method, and transaction time for payment issues.
• Expected versus actual behavior and minimal reproducible steps.

Tickets currently support text messages only. A screenshot can be placed in trusted storage and shared through a controlled link after removing sensitive information. Never expose object-storage credentials.

Statuses

Status	Meaning
waiting_admin	Waiting for administrator action; a new ticket or user reply normally enters this state
waiting_user	An administrator replied and needs user input or confirmation
closed	Closed and unavailable for direct replies

Reopen a closed ticket when the same issue remains. Continue the original ticket instead of splitting one incident across several threads.

Replies and unread state

Open a ticket to read messages, reply, and mark it read. Unread indicators and counts compare message IDs rather than device time. An administrator reply becomes unread for the user, while a user's own message does not count as unread for that user.

Search and filters

Filter by keyword, status, category, and priority. If search returns nothing, reset other filters before deciding that the ticket is missing.

Privacy and security

• Never submit a full API Key, login password, payment private key, webhook secret, or identity document.
• For a Key issue, provide its name, a few trailing characters, and visible Key ID when available.
• Remove Authorization, Cookie, and personal data from logs.
• Users can access only their own tickets; administrators use a protected management route.

When to use urgent priority

Urgent is for an active broad outage, a security incident, or a charged payment whose benefit remains unavailable. One-model rate limiting, invalid parameters, and general configuration questions normally are not urgent.