Support & SLA

Support runs on tickets — in the dashboard (Support in the sidebar) or over the same management API the dashboard uses. Every plan includes support; the plan sets how fast we commit to answering.

Response-time SLA

Plan	First response	Resolution target
free	48 h	—
standard	24 h	5 days
premium	8 h	3 days
enterprise	2 h	1 day

Targets are calendar time (no business-hours pause) and attach to the ticket at creation from your plan at that moment. While a ticket waits on you (status pending_customer), the clock pauses — deadlines shift by exactly the paused interval when you reply.

Response SLA ≠ uptime SLA

These are support response commitments. We don't currently publish an uptime percentage; platform behavior under node failure is documented in Platform limits → failover.

Ticket lifecycle

open → in_progress → resolved → closed
         ↕
  pending_customer   (waiting on your reply — SLA clock paused)

• Replying to a resolved ticket reopens it automatically.
• closed tickets can be explicitly reopened within 14 days of resolution; after that, open a new ticket and reference the old one.
• resolved tickets auto-close after 7 idle days.
• After resolution you can rate the ticket (1–5 + comment) within 14 days — ratings reach the operators directly.

Categories & priorities

Category	Use for
technical_rpc	RPC errors, latency, unexpected responses (attach X-Correlation-ID!)
node_issue	a specific chain looks unhealthy (stale height, sync issues)
billing	invoices, credits, plan changes
limit_increase	rate-limit / quota raises (or use the limit-request API)
account_security	suspicious activity, lockouts, MFA resets
feature_request	chains or capabilities you're missing
other	everything else

Priorities: low, normal (default), high, urgent — urgent pages the operators immediately; use it for production-down situations.

What to include (faster answers)

• The X-Correlation-ID response header of a failing request — it pins your request in our logs across every layer (errors).
• Chain, endpoint path, method, timestamp (with timezone), and whether it reproduces.
• Attachments: up to 5 per ticket, 10 MiB each — png, jpg, log, txt, json, pdf.

API

Everything below is also two clicks in the dashboard.

# create a ticket
curl -X POST https://api.au.ro/api/v1/support/tickets \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{
    "subject": "eth_getLogs intermittently times out",
    "body": "Correlation IDs: 9629544d-…, seen since 14:00Z, ~1 in 20 requests.",
    "category": "technical_rpc",
    "priority": "high",
    "chain": "eth"
  }'
# → 201 with {"id": "...", "number": 42, "status": "open", ...}

# list my tickets / read one (comments included)
curl https://api.au.ro/api/v1/support/tickets -H "Authorization: Bearer $TOKEN"
curl https://api.au.ro/api/v1/support/tickets/$TICKET_ID -H "Authorization: Bearer $TOKEN"

# reply
curl -X POST https://api.au.ro/api/v1/support/tickets/$TICKET_ID/comments \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"body":"Still reproducing as of 18:30Z, new correlation id attached."}'

# reopen a resolved/closed ticket (≤14 days; restarts the SLA clock)
curl -X POST https://api.au.ro/api/v1/support/tickets/$TICKET_ID/reopen \
  -H "Authorization: Bearer $TOKEN"

# rate a resolved ticket
curl -X POST https://api.au.ro/api/v1/support/tickets/$TICKET_ID/csat \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"score":5,"comment":"fixed in one round-trip"}'

Validation to know about: subject ≤ 200 chars, body ≤ 20,000 chars; optional chain narrows technical_rpc/node_issue context. Attachments use a presign flow (POST …/attachments → HTTP PUT to the returned URL → POST …/attachments/{id}/complete) — the dashboard handles it for you.

Fair-use caps

• ≤ 10 new tickets per account per day.
• Free plan: ≤ 5 tickets open at once — resolve or close before opening more.

Security issues

Suspected account compromise or a vulnerability report: open an account_security ticket with priority urgent. Never put private keys or full API keys in a ticket — a key prefix is enough for us to identify it (key handling).