04 · feedback Report feedback
POST https://api.nonecap.com /v1/feedback
Report the tokens your target rejected, so we can see how they actually
performed and catch regressions early. Reporting accepted ones as well is
optional. This is the batch endpoint: buffer your verdicts and flush up to
500 at once. There's no extra charge and no new key
or scope, since it's gated on the same solve scope
that created the solves, so your existing API key works unchanged. You can
only report your own solves.
Body parameters
feedback array required
1-500 feedback items. An empty, missing, non-array, or over-cap value is a
422 validation_error on feedback.
The batch is not all-or-nothing: each item is validated and upserted
independently, so one bad solve_id never discards
the good rows.
Feedback item
solve_id string required
The solve_... id returned by Create a solve.
Must belong to you and be a solved solve. Keep this
id next to the token you submit downstream, since it's the only thing you
need to retain to report the outcome later.
outcome string · enum required
The downstream verdict. Only accepted and
rejected count toward the acceptance rate;
unknown (verdict undetermined),
unused (token never submitted or expired), and
error (a failure that wasn't the token's fault, such
as a network problem, a 5xx or maintenance) are recorded but excluded from
the quality denominator.
acceptedrejectedunknownunusederror
reason string optional
Freeform downstream reason or code: whatever your target returned when
it refused the token, for example invalid-response.
Truncated to 512 characters. This is the field worth populating, because
it's the only part of the rejection we cannot see from our side.
context string optional
Optional free text: anything about the attempt you think would help us
diagnose it. There is no schema, so a status code, the response body your
target returned, which proxy pool you were on or what your retry did are
all fine. A human reads it when you raise a ticket; nothing parses it.
Truncated to 2000 characters.
reported_at string · ISO 8601 optional
Client's instant of the downstream verdict. Advisory only: the server
always stamps its own created_at and
updated_at.
Rules
- You can report your own solves only. A foreign or unknown id resolves to a per-item
not_eligible. - Only a solve that reached
solved is reportable; anything else is not_eligible. - The first report must land within 30 days of the solve. A late first report is
expired_window, but corrections to an already-reported solve are not age-gated. - Reports are idempotent and last-write-wins. Reporting the same
solve_id again overwrites the mutable fields (status: updated); re-sending an identical value does nothing (status: unchanged). The first reported outcome stays immutable server-side and report_count bumps only on a real change, so verdict flips stay auditable.
Two response shapes
This batch endpoint returns the batch envelope,
{ object: "feedback_batch", recorded, updated, unchanged, failed, results },
where each results entry has a
status of recorded,
updated, unchanged or
error, and a failed item nests a bare
{ code, message, param } without the
error wrapper. The single-item alias below returns
the feedback resource directly, or the standard
{ error: { code, message, param } } envelope on
failure. Handle both.
Responses
feedback_batch: Returned once the request is structurally valid, even if some items failed. Inspect the per-item status.
invalid_request: Body is not a JSON object.
validation_error: feedback is missing, empty, not an array, or over 500 items (param feedback).
Per-item error.code values inside a
200 batch are
validation_error (bad field),
not_eligible (unknown / foreign / not-solved id), or
expired_window (first report past the 30-day window).