curl --request POST \
--url https://api.moonbounce.ai/v1/feedback \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--data '
{
"about": {
"evaluation_id": "evl_01900000-0000-7000-8000-000000000000"
},
"source": "owner",
"claims": [
{
"kind": "expected_outcome",
"value": "review"
}
],
"reason": "The seller is verified, so this needs a person, not a removal."
}
'{
"environment": "production",
"id": "<string>",
"evaluation_id": "<string>",
"item_id": "<string>",
"claim_count": 2,
"resolved_from_item": true
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}Submit feedback on evaluations or items
Say what the right answer was: the one way a label becomes evidence. Send one submission, or many as submissions (up to 200, each exactly as one call would send it): every submission is checked first, then all are stored in one transaction, or none are (a refusal’s param starts submissions.<i>); the response then lists each one’s result in results. The sources that count toward an evaluation’s consensus, which previews and suggestions learn from, are owner (through this route), reviewers answering through the review routes (the Review app), and imported examples; app_native and app_resolution provide supporting feedback only. Use source: "owner" for your own judgment as the decision’s owner: its expected_outcome or verdict claim decides the consensus; expected_answer claims alone decide nothing. All owner feedback through this route is the decision owner’s single voice, whoever sent it (the latest owner submission with an end-level claim decides, replacing earlier ones); agreement between people is only kept for reviewers on the review routes. Use app_native or app_resolution for your app’s own feedback (a user approved or reverted the outcome, an appeal settled it): they never decide a consensus, but the first feedback on an item’s group, from any source, fixes its split for good, their reasons can reach the suggestion generator, and their input_broken claims set the evaluation aside. See source. Records claims about an evaluation in the key’s environment, or about an item’s latest primary evaluation, at two levels: expected_answer (what one question’s answer should have been) and expected_outcome or verdict (what the decision should have produced, or approve/reject of the outcome it returned), plus input_broken. Claims are checked against that evaluation (400 with param): an expected_answer names a question of its structure (claims.<i>.question), one per question; an expected_outcome is one of the outcomes the result can produce (claims.<i>.value); at most one end-level claim, never verdict and expected_outcome together; a result that is a value (a number) takes no end-level claim; and verdicts only on primary evaluations that decided an outcome (shown, and not abstained). supersedes must name a submission by the same actor on the same evaluation that nothing has superseded yet (409). owner feedback cannot name an actor (403). Owner feedback, and superseding an owner submission, need the decisions:develop scope (403 INSUFFICIENT_SCOPE); integration sources need decisions:feedback. Read a submission back with GET /v1/feedback/{feedback_id}. A replay with the same Idempotency-Key returns the first result with the Idempotent-Replayed header.
curl --request POST \
--url https://api.moonbounce.ai/v1/feedback \
--header 'Authorization: Bearer <token>' \
--header 'Content-Type: application/json' \
--data '
{
"about": {
"evaluation_id": "evl_01900000-0000-7000-8000-000000000000"
},
"source": "owner",
"claims": [
{
"kind": "expected_outcome",
"value": "review"
}
],
"reason": "The seller is verified, so this needs a person, not a removal."
}
'{
"environment": "production",
"id": "<string>",
"evaluation_id": "<string>",
"item_id": "<string>",
"claim_count": 2,
"resolved_from_item": true
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}{
"error": {
"type": "invalid_request",
"message": "<string>",
"reason": "<string>",
"param": "<string>",
"details": {
"issues": [
{
"param": "<string>",
"code": "<string>",
"message": "<string>"
}
]
}
}
}Authorizations
An API key, sent as Authorization: Bearer <key>. Each operation lists the scope its key needs: decisions:evaluate (evaluate and read evaluations), decisions:feedback (your app's feedback) or decisions:develop (everything else, including owner feedback and the review queue). An operation listing no scope takes any scoped key. A key with no scope, or without the operation's, gets 403 INSUFFICIENT_SCOPE.
Headers
Makes a retry safe. For 24 hours, the same key with the same request returns the first stored result (with Idempotent-Replayed: true); the same key with a different request is a 422 IDEMPOTENCY_KEY_REUSED. Keys are scoped to the organization and environment across every operation, so use a fresh key per request. A request that failed before its result was stored runs again when retried with its key.
1 - 255^[\x20-\x7e]+$Body
- Option 1
- Option 2
What the feedback is about. {evaluation_id} is preferred: it names exactly the answer you are judging. {decision_id, item_id} means the item's latest primary evaluation in the key's environment, resolved when the feedback arrives; the response says which one. Verdict claims need evaluation_id.
- Option 1
- Option 2
Show child attributes
Show child attributes
What you are saying about the evaluation, 1 to 65 claims: expected_answer (at most one per question), expected_outcome or verdict (at most one, and not both), and input_broken.
1 - 65 elementsWhat one question's answer should have been. It is stored against the question as it was asked (its hash), so a reworded question does not inherit it. Aggregations and attributes take none: aggregations are computed and attributes are facts you supplied.
- Option 1
- Option 2
- Option 3
- Option 4
Show child attributes
Show child attributes
Who is speaking. Three sources count toward an evaluation's consensus answer, which is what previews and suggestions learn from (on primary and example evaluations whose content is stored): owner through this route, reviewers answering through the review routes (the Review app), and imported examples. The owner outranks reviewers, and reviewers outrank imported examples. app_native and app_resolution provide supporting feedback only. owner: the decision owner's judgment. An expected_outcome or verdict claim decides the consensus; expected_answer claims refine a case that has a consensus and on their own decide nothing. owner folds every person into one: all owner feedback through this route is the decision owner's single voice, whoever sent it, and the latest owner submission with an end-level claim decides, replacing earlier ones. Agreement between people is only kept for reviewers on the review routes, who each get one vote. Use owner for corrections you stand behind. app_native: your app's own feedback about the outcome it acted on, for example a user approved or reverted it. app_resolution: how your own process finally settled the case, for example an appeal. The two weak sources never decide a consensus, but they are not inert. The first feedback a group of near-identical items gets in an environment, from any source other than an import, puts the group in training (an imported example's group is in the example split instead). A native or resolution submission's reason is shown to the suggestion generator alongside a case that other feedback decided. An input_broken claim from any source sets the evaluation aside.
app_native, app_resolution, owner Who in your system this comes from, for example a user or agent id. It is namespaced under your key. Not allowed with source owner: the owner is you.
1 - 256Optional: why the answer was off, in your words. It is context for whoever writes the next change to the decision, so the most useful reason names the question that got it wrong, quotes the words in the content that show it, and states the rule that applies. A sentence is enough.
4000True when the judge is not confident in these claims.
The id of your own earlier submission on the same evaluation that this one replaces. Only the latest submission in a chain counts; the earlier one stays readable and shows superseded_by.
^fbk_[0-9a-f]{8}-[0-9a-f]{4}-7[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$Response
Recorded
- Option 1
- Option 2
The environment of the key that made the call: production or test. Evaluations, feedback, reviews and suggestions are separate per environment; registered structures are shared.
production, test ^fbk_[0-9a-f]{8}-[0-9a-f]{4}-7[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$^evl_[0-9a-f]{8}-[0-9a-f]{4}-7[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$x >= 1