Bug Reports API Report a Fastio platform bug straight to the Fastio team, in one call.

Base URL: https://api.fast.io/current/ Auth: Bearer {jwt_token} Format: JSON

Report a Fastio platform bug straight to the Fastio team from wherever you hit it — no separate support channel, no context lost between the failure and the report. The Fastio team reviews reports. There is no endpoint to list or read a report back after submission.

When to Use It

You (or an agent acting on your behalf) hit unexpected platform behavior — after a reasonable retry, not an ordinary 401/403/429, an expired credential, or exhausted quota — and want to flag it to the Fastio team.
You have a failing request’s x-ve-reqid value, its response body, or a short log excerpt and want to hand it over for investigation.

This is not the right place for “how do I…” questions — use the How-To reference for those. It is also not the right channel to report a problem with this endpoint itself — see Notes below.

Endpoint Summary

Method	Endpoint	Description
POST	/current/bug-reports/	Report a Fastio platform bug

On the dedicated API hosts (api.fast.io, api.fastdev1.com), call https://api.fast.io/current/bug-reports/ with no /api prefix. From any other hostname (for example go.fast.io), include the /api prefix: https://go.fast.io/api/current/bug-reports/. Also reachable at /v1.0/bug-reports/.

Report a Bug

POST /current/bug-reports/

Submit a single bug report. It is stored for the Fastio team to review — this is not a live support channel, and there is no acknowledgement beyond the received status.

Auth: Bearer token required — a signed-in, verified user account. The credential must be write-capable for your account — a user, org, or workspace write grant; a read-only API key or scope, a share-scoped credential, or a resource token is refused. Anonymous calls are refused. No org membership and no plan is required.

Request format: application/x-www-form-urlencoded. Unknown fields are rejected.

Parameters

Parameter	Type	Required	Description
`category`	string	Yes	One of `api`, `mcp`, `docs`, `auth`, `storage`, `ai`, `billing`, `other`.
`title`	string	Yes	1–200 characters, single line.
`description`	string	Yes	Up to 8 KB. Recommended: what you were doing, steps to reproduce, expected result, actual result.
`request_id`	string	No	The `x-ve-reqid` response header value from the failing call (30 alphanumeric characters). Strongly recommended — the single most useful thing for the team to find the failing request. Browser JavaScript cannot read this header (it is not CORS-exposed); server-side clients and agents can.
`endpoint`	string	No	Method and path of the failing call, e.g. `POST /current/workspace/{workspace_id}/storage/root/`. No host, no query string.
`http_status`	integer	No	100–599.
`error_code`	integer	No	The numeric `error.code` from the failing response.
`occurred_at`	string	No	When it happened, `YYYY-MM-DD HH:MM:SS` (optionally with a trailing `UTC`) — must be within the last 30 days and not in the future. Encouraged when known.
`blob`	string	No	Plain-text excerpt up to 32 KB — e.g. the error response body, or a short log excerpt.
`idempotency_key`	string	No	16–64 characters, `[A-Za-z0-9_-]`. Retrying with the same key and identical content returns the original report; the same key with different content is a conflict. Every retry, including an identical replay, still counts toward the rate limit, so back off on `429` instead of retrying immediately.

Request Example

curl -X POST "https://api.fast.io/current/bug-reports/" \
  -H "Authorization: Bearer {jwt_token}" \
  --data-urlencode "category=storage" \
  --data-urlencode "title=Folder rename returns 500 for a name with trailing whitespace" \
  --data-urlencode "description=What I was doing: renaming a folder via the storage update endpoint.
Steps to reproduce: update the node with name set to a value ending in a space.
Expected: either the rename succeeds with the name trimmed, or a 406 explaining why it is rejected.
Actual: HTTP 500." \
  --data-urlencode "request_id={request_id}" \
  --data-urlencode "endpoint=POST /current/workspace/{workspace_id}/storage/{node_id}/update/" \
  --data-urlencode "http_status=500" \
  --data-urlencode "occurred_at=2026-09-30 17:00:00 UTC"

Response (200)

{
  "result": true,
  "report": {
    "id": "{report_id}",
    "status": "received",
    "created": "2026-09-30 17:00:00 UTC"
  }
}

Response Fields

Field	Type	Description
`result`	boolean	`true` on success.
`report.id`	string	The report’s identifier.
`report.status`	string	Always `"received"` on a successful submission — the report was stored for review, not confirmed, triaged, or scheduled.
`report.created`	string	Canonical `Y-m-d H:i:s UTC` timestamp.

Submitted text is never echoed back, and there is no endpoint to list or read reports back — treat submission as one-way.

Error Responses

HTTP Status	Cause
401	Unauthenticated — missing or invalid bearer token.
403	The account is not verified, or the credential is read-only, share-scoped, or a resource token (a write-capable user, org, or workspace credential is required).
406	A required field is missing, a field fails its constraint (length, format, or closed vocabulary), or an unrecognized field was sent.
409	`idempotency_key` was reused with content different from the original report.
413	`description` or `blob` exceeds its maximum size.
429	Rate limited — see Rate Limiting in the overview.
503	Temporarily unavailable — retry.

Errors use the standard envelope: {"result": false, "error": {"code": …, "text": …, "resource": …}}. See Error Codes in the overview for the envelope shape.

Notes

What to report. Unexpected platform behavior, after a reasonable retry — not an ordinary 401/403/429, an expired credential, or exhausted quota. Those are expected responses to handle in your own code, not bugs.
What never to include. Never put passwords, API keys, tokens, cookies, or customer file contents in a report. Send a minimal excerpt (in blob) rather than a whole conversation or log dump.
Don’t report a failure of this endpoint through itself. There is no other channel described here for that failure.
Include request_id and occurred_at whenever you have them. request_id is the single most effective way for the team to locate the failing request; occurred_at narrows the search window.
“How do I…” questions belong to How-To, not bug reports. Use POST /current/how-to/ — see the How-To reference.
The Fastio team reviews reports. There is no automatic acknowledgement beyond status: "received", and no endpoint to list or read a report back after submission.

↑ Back to top