Help

Support

Where to write, what to include so the first reply can be the fix, and the handful of things you can sort out yourself before you do.

Last updated

1What each plan includes

  • Free. The documentation, which answers most of what reaches our inbox. Write to us anyway if you hit something that looks like a bug: we want to know.
  • Starter. Email support for the product, your account and your billing.
  • Growth and Business. Priority email support. Your tickets go to the front of the queue, and we will get on a call for anything that is faster to solve live.
  • Enterprise. A named contact, a shared channel if you want one, and a written service level agreement with response targets in your order form.

Outside an Enterprise agreement we do not publish response times, because a number we quote on a marketing page is worth nothing to you when it slips. What we will do is tell you where your ticket stands. Bugs affecting live documentation or a failing production SDK get looked at ahead of everything else, whatever plan you are on.

2What to put in your first message

Support is much faster when the first reply can be the fix. Include as much of this as you have:

  • Your organisation name and the project involved.
  • What you expected, what happened instead, and the steps to reproduce it.
  • When it happened, with a timezone. Our logs are timestamped and a five-minute window is usually enough to find the request.
  • The request id from the error, if the dashboard or the API gave you one, or the full error message.
  • For spec problems: the OpenAPI file, or the part of it involved. Strip any real credentials before you send it.
  • For SDK problems: the language, the SDK version, and the build log if the build failed.
  • For docs site problems: the URL, and whether the site is public, password or SSO.

Do not send us live API keys, passwords or customer data. We will never ask for your password or a two-factor code.

3Things you can fix in a minute

Locked out of your account

Use the password reset link on the sign-in page. If you lost your authenticator, use one of the recovery codes you saved when you turned two-factor on. If you have neither, an owner or admin in your organisation can reset two-factor for you. If you are the only owner, write to support@octri.devfrom the account’s email address.

AI features stopped working

Check your credit balance in billing. When credits run out, documentation generation and Ask-the-docs stop while everything else keeps running. Upgrade, buy a pack, or turn on auto-refill. See the Fair Use Policy.

Custom domain will not verify

Verification reads DNS, so it fails while the record is still propagating or if a proxy is hiding it. Confirm the record exactly matches the one shown in project settings, wait for your provider’s TTL, then re-run the check.

Your spec will not upload or generates the wrong thing

We accept OpenAPI 3.0 and 3.1, Swagger 2.0, Postman collections and AsyncAPI, in JSON or YAML. Everything else is translated to OpenAPI on the way in. The audit shown after upload lists what we could not resolve: missing schemas, unnamed request bodies, and endpoints with no description are the usual causes of thin documentation. Fixing those in the spec fixes the output.

Getting 429 responses

You have hit a rate limit. The response carries a Retry-After header. Back off and retry rather than looping. The limits are listed in the Fair Use Policy.

Invoices and receipts

Paddle is our merchant of record, so receipts come from them. The billing portal in your organisation settings links to your invoice history, and you can change your payment method and cancel from there.

4Outages and incidents

If documentation sites, the dashboard or the API are down for more than a moment, we email account owners with what we know and what we are doing about it.

Before you write in, it is worth checking whether the failure is on our side or in a service you connected. A registry rejecting a publish, GitHub being unavailable, or a DNS change that has not propagated all look like Octri problems from the dashboard. Send us the error either way and we will tell you which it is.

5Security reports

Do not send vulnerabilities to the support inbox, and do not disclose them publicly before we have had a chance to fix them. Email founders@octri.dev, and read the disclosure policy first: it sets out what is in scope, what to include, and the protections you get for reporting in good faith.

6Feature requests and feedback

Tell us what you are trying to do, not only what you want us to build. The problem behind a request usually shapes a better answer than the feature described.

Email is the fastest route for these, and GitHub is the right place for anything wrong in a generated SDK, with the language and the offending output. Enterprise customers can raise them with their named contact.