Support

Support runs through the API, the same way everything else in Docsary does. You file a report with your organization key, we get it, and you can list your own reports at any time to see where each one stands.

There is no ticket portal and no support inbox to write into. That is a deliberate choice while access is limited, and it is stated plainly here rather than implied: what follows is the whole support channel today.

Report a bug

curl -s -X POST "$DOCSARY_API/v1/reports" \
  -H "authorization: Bearer $DOCSARY_KEY" \
  -H "content-type: application/json" \
  -d '{
    "kind": "bug",
    "title": "Search returns nothing for hyphenated terms",
    "body": "Searching for drop-in on our site returns zero results, but drop in finds the same page. Two versions, both affected. Started some time last week.",
    "page_url": "https://docs.acme.com/guide/search",
    "contact": "docs@acme.com"
  }'

{
  "id": "rep_9f2c4a1b7e6d8035c1a4b9e2f7d60a83",
  "kind": "bug",
  "title": "Search returns nothing for hyphenated terms",
  "status": "open",
  "created_at": 1756300000000,
  "email": { "status": "sent" }
}

Keep the id. It is how you refer to the report later, and how we refer to it back to you.

Request a feature

Same call, kind set to feature:

curl -s -X POST "$DOCSARY_API/v1/reports" \
  -H "authorization: Bearer $DOCSARY_KEY" \
  -H "content-type: application/json" \
  -d '{
    "kind": "feature",
    "title": "Mark a version deprecated without deleting it",
    "body": "We keep three released versions live for customers on older hardware. We would like a banner on the two older ones saying they are superseded, without unpublishing them or hand-editing every page.",
    "contact": "docs@acme.com",
    "meta": { "versions_live": 3 }
  }'

The most useful feature requests describe the situation you are in rather than the change you have in mind. What you are trying to publish, what you do today instead, and what makes it awkward — that tells us more than a proposed setting name.

What is required

Any valid organization key can file, including a read-only one. Telling us something is broken is not a change to your content, so a key you gave to CI purely to inspect things can still report what it found.

For a bug, the three things that shorten the round trip most: the URL, what you expected, and what happened instead. If it only happens on one version or one page, say which.

What happens next

1. We store it. The report is written down against your organization before anything else happens, and answered with its id. That record is what we work from.
2. We get an email. A notification goes out with your report in it. If you supplied a contact, replying to that notification goes straight to you.
3. You can check on it. Your reports are listable by your key for as long as they exist.

The response carries an email block saying whether the notification went out — sent, skipped, or failed. It is there for honesty rather than for action: a notification that did not go out does not lose the report, because the report was stored first. If you ever see skipped or failed, the report is still filed and still in your list.

Check on your reports

curl -s -H "authorization: Bearer $DOCSARY_KEY" \
  "$DOCSARY_API/v1/reports"

{
  "reports": [
    {
      "id": "rep_9f2c4a1b7e6d8035c1a4b9e2f7d60a83",
      "kind": "bug",
      "title": "Search returns nothing for hyphenated terms",
      "status": "open",
      "created_at": 1756300000000
    }
  ],
  "next_offset": null
}

Newest first, and only your organization's own reports. Filter with ?status=open, ?status=triaged, or ?status=closed.

Status is ours to set — there is no call for you to change it. A closed report that turns out not to be fixed is best raised as a new report quoting the old id.

Limits

An organization may file 20 reports an hour. Past that the call returns 429 and says so; nothing is stored and your earlier reports are untouched. If you have a genuine batch to file, ask us instead of looping.

The full request and response shapes, every validation rule, and every error are in the Reports API reference.

What this is not

• Not a status page. If a site of yours is not serving, file a bug with the hostname in it.
• Not an SLA. Reports are read and triaged; no response time is promised, and we would rather say that than imply one.
• Not private to the page it is about. A report is attributed to your organization and read by us. Do not put credentials or customer data in one.

For anything about your organization itself — a new key, a plan change, a limit lifted — see Access.