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.
Triage before you report#
Three questions decide where a problem belongs, and answering them takes less time than writing the report.
- Is it an answer? A 404 on a reference you invented, a 422 on a
limitof 50, a 403 from anOriginyour client added — these are the surface working. Designing a resilient client sorts every failure into transient and final. - Is it a capability question? If the complaint is that something does not work, check the status manifest before reporting a fault:
foundationandnot_yetare documented states, not defects, and several of them surprise people. - 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
idrather 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#
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.