How to report an API error without sharing secrets

A failed API call is often the clearest fact in a website problem report. The method, path, and status can point a developer to one route faster than a long description. The same network panel that shows those facts can also show tokens, headers, and bodies that must never leave the browser.

This guide shows how to report an API failure with enough detail to investigate and without sharing a secret. It applies whether you paste the facts yourself or send them through a report widget.

Start with the action, then name the failed request

Describe what you selected and what you saw before you open developer tools. Then add one request line.

A useful report has this shape:

1. The page and the visitor action.
2. The visible result or error text.
3. One failed request: method, path without query values, status, and approximate time.

For example:

I selected Save on the profile page. The page showed Something went wrong. The Network tab showed POST /api/profile returning 500 at about 14:12 UTC.

That line is usually enough to start. It does not need a diagnosis, a stack guess, or a copied payload.

Keep only safe request metadata

When you inspect a failed or slow request, copy only these fields:

• The HTTP method, such as GET or POST.
• The path with query values removed.
• The response status when the browser shows one.
• The duration, if it helps explain a timeout.
• The time the request occurred.

Do not copy origins, credentials, headers, query values, URL fragments, request bodies, or response bodies. Those fields often contain session tokens, API keys, personal data, or payment values. A safe report never needs them.

If the path itself includes an identifier you consider private, keep the route shape and omit the sensitive segment. POST /api/orders/{id}/pay is still useful. A full URL with a session token in the query string is not.

Treat Authorization headers and bodies as secrets

The Network panel can look like ordinary debug text. Treat these items as credentials or private records every time:

• Authorization, cookie, and API-key headers.
• Bearer tokens, refresh tokens, and signed URLs.
• Request bodies with passwords, card details, or customer records.
• Response bodies with account data or internal error dumps that embed tokens.

If a screenshot of the Network tab would show any of those values, do not send the image, or crop until only the method, path, and status remain. The same rule applies to a console message that echoes a request payload.

For the broader console habit, read how to read a console error as a non-developer. For the full set of safe browser categories, read what browser evidence helps investigate a website problem.

Prefer a structured report over a raw paste

A raw HAR file, a full response dump, or an unedited Network screenshot is hard to review and easy to overshare. Prefer a short structured note:

• Action and page.
• Expected result and actual result.
• One failed request line.
• One console error type, message, and file line when present.
• Whether the failure happens every time or only once.

That structure matches a useful website problem report and keeps private values out of the thread. See how to write a useful website problem report for the same pattern in ordinary visitor language.

Let a widget collect the same limits automatically

Most visitors will not open developer tools. A report channel can still record the same safe request metadata: method, path without query values, status, duration, and time. It should reject headers, bodies, credentials, query values, and fragments by schema, not by hope.

IssueProbe follows that rule in its widget. Failed or slow requests stay metadata only. Console items stay bounded errors and warnings with token-like and email-like text redacted. Browser state records a name, presence, and size, never a value. A screenshot needs a visible capture, a preview, and explicit consent. The exact field list is on the widget privacy page.

A safe API error report is still only evidence. It can support a conclusion when it matches source, and it can leave the cause unknown when it does not. The example report shows how request metadata sits beside the visitor statement, the citations, the unknown facts, and the human decision.