# Getting help as a developer

Triage first: most developer problems on these surfaces are answers rather than faults. If it is genuinely a fault, a report is answerable when it carries the exact request, the verbatim error, the corpus build you saw, and whether it reproduces. The published contact is the operator, JBRH Digital Solutions, through the website's own enquiry route.

- **Status:** Reference
- **Audience:** developer
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/developers/developer-support/

## Triage before you report

Three questions decide where a problem belongs, and answering them takes less time than writing the report.

1. **Is it an answer?** A 404 on a reference you invented, a 422 on a `limit` of 50, a 403 from an `Origin` your client added — these are the surface working. [Designing a resilient client](/developers/errors-and-retries/) sorts every failure into transient and final.
2. **Is it a capability question?** If the complaint is that something does not work, check the status manifest before reporting a fault: `foundation` and `not_yet` are documented states, not defects, and several of them surprise people.
3. **Is the page wrong?** A documentation defect — a stale fact, a field that no longer exists, a status word that does not match behaviour — is the most valuable report of the three, and it needs the page `id` rather than the title.

## What a report needs

| Include | Because |
|---|---|
| The exact request — method, full path, query string | A described request is a paraphrase; a pasted one can be re-run |
| The HTTP status and `error.code` | The code is the switchable fact; the message is prose that may be reworded |
| The JSON-RPC `id`, `method` and error `code`, for MCP | It locates the call precisely, including the header-agreement checks |
| The page `id` such as `D0039`, for a content problem | Titles change and URLs move; the id does not |
| `generated` and `version` from the status manifest | It identifies the corpus build you were reading, which may not be the current one |
| Timestamps in UTC, with the zone stated | Half of all 'it stopped working at 3pm' reports lose an hour here |
| Whether it reproduces, and how often | 'Every time' and 'once, yesterday' lead to entirely different investigations |
| What you expected, separately from what happened | The gap between them is often the whole answer |

One more line is worth writing and is usually missing: what you already ruled out. It stops a reply that asks you to check the thing you checked first.

## What must never be in it

> **Careful** No credential, ever. Not an integration key, not a webhook signing secret, not a session cookie, not a bearer header with its value intact. A key pasted into a report is a key that must now be rotated, which turns one problem into two.

No customer data either. If the problem involves a real message, describe its shape rather than its content: the channel, the length, the fact that it had an attachment. If an example is genuinely needed, construct a fictional one — `someone@example.net`, `+91 90000 00000`, "Acme Traders" — and say that it is fictional.

A safe minimal reproduction looks like a command line with the credential replaced by a placeholder and any identifier that belongs to a real person replaced by an invented one. If redacting it makes the problem unreproducible, that itself is information worth stating.

## Where reports go

The machine artefacts name the contact rather than an address: the AsyncAPI document's `contact` block gives *JBRH Digital Solutions* and a documentation URL. This corpus does not publish a developer support mailbox, and inventing one here would be worse than saying so.

**From the website** — The site's own enquiry route reaches the operator. Enquiries arriving that way are handled on the operator's side of the platform.
**From inside a workspace** — The Connect Assistant is available in-app to a workspace member, and a question about behaviour is often answered there faster than by a report — it reads the same documentation these routes serve.
**From an integration you were given a key for** — Use whatever channel that arrangement established. An integration key implies a relationship with the operator; this page cannot document the particulars of yours.

For a documentation defect there is a useful last step before reporting: re-fetch the page and compare `updated` with the date you read it. The corpus is rebuilt on deploy, and a fact you are about to report may already have been re-verified.

## Questions

### Is there a status page for the public API?

None is documented in this corpus. `GET /api/public/docs/status` answers whether the documentation surface is responding and which build it is serving, which covers the question a client usually has.

### How do I report that a capability's status looks wrong?

Name the capability key as it appears in `capabilities`, quote its `status` and `evidence` verbatim, and describe the behaviour you observed. Those three together are checkable; 'the docs are out of date' is not.

### Should I report a rate limit as a fault?

Only if you were well under 240 requests a minute from one address and still received 429. Otherwise it is the limiter doing its job, and the fix is backoff on your side.

## Related

- [Designing a resilient client](https://connectbyjbrh.com/developers/errors-and-retries/)
- [The product status manifest](https://connectbyjbrh.com/developers/status-manifest/)
- [Stable identifiers](https://connectbyjbrh.com/developers/entity-ids/)
- [Integration keys](https://connectbyjbrh.com/developers/integration-keys/)
- [Troubleshooting](https://connectbyjbrh.com/docs/troubleshooting/)

## What this page is based on

- `webapp/developers/asyncapi.yaml` — the published `contact` block
- `backend/app/public_developer_api.py` — error envelope and status route
- `docs-source/facts.py` — CAPABILITY_STATUS['assistant'], ['website_enquiries']