Reviews & moderation

Endpoints

The review payload

curl -X POST $API/reviews \
  -H "Authorization: Bearer $KEY" -H 'Content-Type: application/json' \
  -d '{
    "site_id": "'$SITE_ID'",
    "offer_id": "'$OFFER_ID'",
    "author_name": "Henrik J.",
    "city": "Toronto",
    "title": "Exactly what I needed",
    "content": "Setup took ten minutes, import worked flawlessly…",
    "rating": 5,
    "status": "approved"
  }'

# the site has review.criteria = ["Appearance", "Personality", "Value"]
# send the SAME names — ALL of them, integers 1-5
curl -X POST $API/reviews \
  -H "Authorization: Bearer ***" -H 'Content-Type: application/json' \
  -d '{
    "site_id": "'$SITE_ID'",
    "offer_id": "'$OFFER_ID'",
    "author_name": "Jane D.",
    "content": "…",
    "rating": 5,
    "status": "approved",
    "criteria_scores": {"Appearance": 5, "Personality": 4, "Value": 5}
  }'

# invalid payloads get a 422 with details, e.g.
# {"error":"criteria_scores invalid",
#  "unknown_criteria":["Swag"], "missing_criteria":["Value"],
#  "invalid_values":["Appearance"]}

Moderation workflow

Whether new reviews wait for approval is a per-site setting (settings.review.moderation — see Sites & settings). With moderation on, visitors' reviews arrive as pending and only render after approval. The same setting also controls email confirmation (review.email_confirmation) and per-criterion ratings (review.criteria list — the public form then asks for a score per criterion, and averages display on the offer page). API-seeded reviews can carry the same scores via criteria_scores on POST /reviews — they join the per-criterion averages exactly like form submissions.

# what's waiting?
curl -s "$API/reviews?site_id=$SITE_ID&status=pending" -H "Authorization: Bearer $KEY"

# approve everything in one call
curl -X POST $API/reviews/bulk \
  -H "Authorization: Bearer $KEY" -H 'Content-Type: application/json' \
  -d '{"ids": ["uuid1", "uuid2"], "action": "approve"}'

Visitor reviews & community accounts

Every site has a built-in account system (no platform-wide login — accounts belong to one site). With review.require_account (default on), only logged-in visitors with a verified email and a confirmed 18+ date of birth can post reviews or article comments. Identity comes from the account session, so the public form drops its name/email fields — no more fake author names.

• Reviews posted from an account carry a ✓ Registered badge wherever they render, and link back to the account's display name.
• Unverified users can log in but see a confirm-email banner on every page until they click the link (with resend + change-email options); posting stays blocked.
• Accounts are managed per site in the panel (Site → Community): list, ban with reason, unban. Banned users can't log in.
• Registrations accept the Terms of Service and Privacy Policy (each site serves its own generated /terms/ and /privacy/) and consent to occasional offer emails — see Contacts.

Replies

Two kinds of replies exist: operator replies (you, answering a review — shown as an official response from the site team) and visitor replies (named guest replies, rendered with the author's name; moderated like reviews).