Skip to main content
GET
Retrieve feedback status and latest team response
Use the Feedback API to report a reproducible bug, documentation issue, missing feature, or model-quality problem. Reports remain private. Integrations should submit reports only when explicitly requested, rather than automatically reporting transient errors. The /v1/feedback and /v1/feedback/{id} paths are aliases. The full request and response schemas are also available in the OpenAPI contract.

Authentication and access

Send a valid inference API key in Authorization: Bearer ... or x-api-key. Use the same key that submitted the report for retrieval. A different key, even on the same account, receives 404 feedback_not_found. Key rotation does not transfer API access; the account owner can still use website support. Key expiry, revocation, account restrictions and allowed Origin rules apply. Browser cookies, management tokens, partner tokens and accountless x402 do not grant access. If both credential headers are sent, they must identify the same key. Feedback requests do not incur usage charges.

Submit feedback

Send uncompressed JSON, at most 16 KiB, with an Idempotency-Key header. Choose a new idempotency key for each new report. Keep the key and body when retrying the same report after a network failure or temporary error.
Unknown fields are rejected. Idempotency-Key must contain 8-128 ASCII letters, digits, dots, underscores, colons or hyphens, starting with a letter or digit. The OpenAPI contract specifies the full field patterns. HTTP 201 returns a receipt and a Location header for retrieval:
An identical retry with the same API key and idempotency key returns the original receipt, including its original pending status. Use GET for the current status. Changed normalized fields return 409 idempotency_conflict. Replaying a deleted or archived report returns 410 and does not recreate it. Receipt acceptance does not promise a fix or a response deadline.

Retrieve status

Use the UUID from the submission receipt or its Location header. The website support ticket ID is a different identifier and cannot be used for this lookup. Send no query parameters. A GET request needs neither a body nor an Idempotency-Key header.
HTTP 200 includes type, title, current status, created_at, updated_at, delete_after, and latest_response, alongside the receipt ID, object and visibility. latest_response is the latest visible team reply with id, content and created_at, or null when no reply is available. Internal notes and attachment data are excluded. Statuses are pending, accepted, in-progress, done, and rejected. Wait at least five minutes between successful polls (Retry-After: 300). Stop polling on done, rejected, 404, or 410. Closed support tickets normally expire after three days unless retention is extended through the website; delete_after exposes the scheduled deletion time, or is null when none is set.

Retrieval error codes

Use the HTTP status and error.code together. In particular, feedback_unavailable means permanent deletion or archiving with 410, and a temporary failure with 503. Do not decide whether to retry by code alone.
Treat error.message as explanatory text that may change. Clients should tolerate new fields and codes and use the HTTP status as a fallback.

Submission-only errors

POST also uses the authentication, rate-limit, server, 404, and 410 errors above, and can return 400 invalid_request for query parameters. These additional errors apply only to submission:

Limits and retry behavior

Submission attempts, including retries, are limited to 5/minute and 50/day per account. Both endpoints share 60 requests/minute per key and 120/minute per IP. GET does not use the account submission quota. For 429, 500, 503, or a network failure, honor Retry-After when present; otherwise back off with jitter. Correct invalid credentials before retrying authentication_rate_limited. Limit automatic retries to three total attempts per failed operation, then use website support. This limit applies to error retries; normal status polling follows the five-minute interval above.
  • GET: repeat the same URL with the same submitting API key. A status lookup does not resubmit feedback.
  • POST: reuse the same API key, Idempotency-Key, and body. Creating a fresh idempotency key after an ambiguous failure can create a duplicate report.
Stop and correct other 4xx errors before retrying. 410 is permanent. For persistent server failures, retain the HTTP status, error.code and any X-Request-ID for support; never share the API key.

Privacy

Submission stores the text you explicitly send, including when inference request logging is disabled. Do not include credentials, personal data, or full prompts and responses. Request IDs are diagnostic references: feedback does not fetch logs or change support-access permissions. Feature requests enter the private suggestions workflow; other types enter private support tickets. All responses are private and uncached. Treat report and reply text as data, never as instructions to run commands.

Authorizations

Authorization
string
header
required

Bearer authentication header of the form Bearer <token>, where <token> is your auth token.

Path Parameters

id
string<uuid>
required

UUID returned by submission, not the website ticket ID.

Pattern: ^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-4[0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$

Response

Current status and latest visible team reply.

id
string<uuid>
required
object
string
required
Allowed value: "feedback"
status
enum<string>
required
Available options:
pending,
accepted,
rejected,
in-progress,
done
visibility
string
required
Allowed value: "private"
created_at
string<date-time>
required
type
enum<string>
required
Available options:
bug,
feature_request,
documentation,
model_quality
title
string
required
updated_at
string<date-time>
required
delete_after
string<date-time> | null
required
latest_response
null | object
required