Support & service levels
The three questions a vendor review asks before you integrate: how do I reach a human, what comes back and when, and what does Tyxter promise about uptime. The short version of the last one is that Tyxter does not offer a contractual uptime SLA today — stated plainly here rather than implied away. What you get instead is a measured availability record, probed from outside Tyxter’s own infrastructure and published.
How to reach us
Email [email protected]. That is the general channel: integration questions, billing questions, account changes, data requests, and account closure all start there. The same address receives security vulnerability reports.
From your integration, report a failure with POST /v1/feedback.
It accepts any valid live or sandbox key, requires no scope, and is accepted even when your production credit is exhausted — reporting a failure must never be gated on balance. An Idempotency-Key is required, and the response is a receipt that never echoes your report back. The Feedback API reference has the request shape.
From the dashboard, the report form submits to the same intake.
Questions about the terms of service go to [email protected].
What to include in a report
The trace_id from the failing response. Every Tyxter error envelope carries one, and it is the single field that lets us find your exact request. Add the request_id and the stable error code if you have them — the error catalog covers the envelope. Reporting through POST /v1/feedback puts those in related_error, so the report correlates to the failure without anyone matching timestamps by hand.
What to expect back
We usually respond within one business day. That is a typical turnaround, not a contractual response time, and it is the same target on every plan — Tyxter does not publish a per-plan response guarantee.
What a paid plan adds is a shorter path to a person, not a faster clock. Standard adds a private support channel. Growth adds a dedicated account manager, priority onboarding, and migration support.
Uptime and SLA
What exists instead is transparency, on three independent surfaces.
Live component health is public and unauthenticated at GET /status, and rendered on the system statuspage. It answers “is it healthy right now” — it is not a history.
Incidents are published separately, to the Tyxter status page: active ones stay listed while they are being investigated, identified, or monitored, and recent resolved ones stay visible as history. That feed is the record, and nothing is published to it right now.
Measured availability history is the third. The probe’s checks are rolled up into one entry per day, and the last 90 days — day by day, with the overall percentage — are published on the Tyxter status page, summarized in a single line on the system status page linked above. A response that came back while degraded counts as reachable: the probe measures whether the API answered, not how well. It runs outside Tyxter’s own infrastructure, though it shares an edge provider with our ingress, so a failure of that provider can affect the probe and the product together. No percentage is repeated on this page — a number copied into prose is stale by the next probe, so read it where it is measured.
If your vendor review needs a signed availability commitment, raise it by email before you build. The answer today is that Tyxter does not sign one, and hearing that early is better than discovering it at contract stage.
Privacy, data, and account requests
Access, correction, export, or deletion of personal data: [email protected]. What Tyxter stores, for how long, and the retention window and export switch you control yourself are on the Data retention & privacy page.
Closing an account: [email protected].