Get Help

Where a developer question goes, what to include, and how to report a problem with the docs.

Developer questions go to one place: support.revenexx.com. Wherever these docs say "open a support request" or "quote it in a support ticket", that is the destination — there is no separate developer queue and no email address to remember.

Before you open a request

Two checks that regularly save the round trip:

  • status.revenexx.com — whether the thing that just failed is failing for everyone. An incident on the status page is already being worked; it does not need a support request.
  • The error response itself — gateway errors carry a machine-readable code and a message written to be read. Errors explains the format and what each status means.

What to include

A request that can be answered in one round trip carries:

  • The X-Request-ID of a failing request. Every response includes one — it is what makes "it failed at 14:20" traceable end to end. See Request IDs.
  • The tenant slug you sent in X-Revenexx-Tenant.
  • The endpoint, the method, and the timestamp — in UTC, not "this morning".
  • What you expected and what you got — the actual response status and body, not a paraphrase of them.

A request without these is not rejected. It just starts with the questions above instead of with an answer.

What to expect back

There is no published response-time SLA yet. Requests are answered in the order they arrive, and a complete request — the list above — is what gets a first reply that resolves something rather than asks for the request ID.

Product support or docs feedback

The two channels fix different things, and mixing them up slows both down:

You foundWhere it goes
An API that misbehaves, a blocked request, a question the docs don't answersupport.revenexx.com
A page that is wrong, unclear, or missing somethingThe "Was this page helpful?" control at the bottom of that page
Several things failing at oncestatus.revenexx.com — check before filing anything

The page feedback control opens a prefilled GitHub issue that names the page, and the docs team works from those issues. It is how a docs defect gets fixed — and it is the wrong place for a production problem, because nobody triages an outage from a docs issue.

Was this page helpful?