Feedback

Report the outcome of a prior call: accepts, rejects, thumbs, test results.

POST /api/v1/feedback records how an earlier call turned out (an edit accepted or rejected, a thumbs rating, or a generated test's result), attached to that call by its request_id. Here is a working request:

curl https://api.cruxy.ai/api/v1/feedback \
  -H "Authorization: Bearer $CRUXY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "request_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "type": "thumbs",
    "consent": true,
    "payload": { "value": "up" }
  }'

const res = await fetch('https://api.cruxy.ai/api/v1/feedback', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${process.env.CRUXY_API_KEY}`,
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    request_id: 'a1b2c3d4-e5f6-7890-abcd-ef1234567890',
    type: 'thumbs',
    consent: true,
    payload: { value: 'up' },
  }),
})
 
const { stored } = await res.json() // 202 Accepted; see below

Joining to a prior call

request_id ties the feedback to the call it is about. It is the same UUID the gateway returns in the cruxy.request_id field of a chat, embeddings, rerank, or moderations response; see the cruxy block. Log that id when you make a call, then send it back here when you learn the outcome.

Event types

type must be one of:

Each type fixes the shape of payload, and the gateway validates it, rejecting unknown keys, wrong types, missing required fields, and bad enum values with a 400. edit_accepted and edit_rejected share one shape; thumbs and test_result each have their own. The API Reference carries the exact fields for each; the request above sends a thumbs payload.

Request fields

What gets stored

Feedback is privacy-gated, and the gate is strict. Two things decide whether an event is kept:

• consent: the per-event boolean you send.
• The account's opt-out: a setting outside this request.

The outcomes are:

• Not consented, or the account has opted out: the event is dropped entirely. No row is written and the payload is never stored. The response has stored: false.
• Consented, and not opted out: a row is written, but its payload is redacted. The event is recorded; the payload you sent is not kept verbatim.

The payload you send is never persisted as-is. A dropped event keeps nothing; a stored event keeps everything but the payload. Do not rely on reading the raw payload back later.

The response

The endpoint always returns 202 Accepted, for a stored event and for a dropped one alike. A 202 means the event was accepted for processing, not that it was stored, so read stored to tell the two apart.

{
  "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "stored": true
}

Errors

Feedback returns 400 for a malformed request and 401 for a bad key. A privacy drop is not an error; it still returns 202 with stored: false. See Errors.

Next steps

• Chat: where request_id comes from.
• Errors: the error shape.