Judge.me User Management API Guide

Auth method: API token (shop token passed as query parameter api_token)

Setup steps

1. Log in to your Judge.me account.
2. Navigate to Settings > Integrations > API.
3. Copy the shop API token shown on that page.
4. Pass the token as a query parameter: ?api_token= on every request.

User object field mapping is not yet verified for this app.

List reviews

• Method: GET
• URL: https://judge.me/api/v1/reviews?api_token=TOKEN&shop_domain=SHOP
• Watch out for: Reviewer email is returned but is not a managed 'user' object; Judge.me has no user-account provisioning API.

Request example

GET /api/v1/reviews?api_token=TOKEN&shop_domain=mystore.myshopify.com&page=1&per_page=10

Response example

{
  "reviews": [
    {"id": 123, "title": "Great!", "body": "...", "rating": 5,
     "reviewer": {"name": "Jane", "email": "jane@example.com"}}
  ]
}

Get single review

• Method: GET
• URL: https://judge.me/api/v1/reviews/:id?api_token=TOKEN&shop_domain=SHOP
• Watch out for: No user-management fields; reviewer data is read-only metadata attached to a review.

Request example

GET /api/v1/reviews/123?api_token=TOKEN&shop_domain=mystore.myshopify.com

Response example

{
  "review": {
    "id": 123, "rating": 5, "body": "...",
    "reviewer": {"name": "Jane", "email": "jane@example.com"}
  }
}

Create review

• Method: POST
• URL: https://judge.me/api/v1/reviews?api_token=TOKEN
• Watch out for: reviewer_email is stored with the review, not as a platform user account.

Request example

POST /api/v1/reviews
{
  "shop_domain": "mystore.myshopify.com",
  "platform": "shopify",
  "id": 456,
  "rating": 5,
  "title": "Excellent",
  "body": "Love it",
  "reviewer_name": "Jane",
  "reviewer_email": "jane@example.com"
}

Response example

{
  "review": {
    "id": 789, "rating": 5, "title": "Excellent",
    "reviewer": {"name": "Jane", "email": "jane@example.com"}
  }
}

List products

• Method: GET
• URL: https://judge.me/api/v1/products?api_token=TOKEN&shop_domain=SHOP
• Watch out for: Product endpoints have no user-management relevance.

Request example

GET /api/v1/products?api_token=TOKEN&shop_domain=mystore.myshopify.com&page=1&per_page=10

Response example

{
  "products": [
    {"id": 1, "title": "Widget", "handle": "widget",
     "reviews_count": 42, "rating": 4.8}
  ]
}

• Rate limits: No publicly documented rate limits found in official docs.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No rate-limit tiers or headers documented officially. Treat as unknown; implement exponential back-off as a precaution.

• Pagination method: offset

• Default page size: 10

• Max page size: 100

• Pagination pointer: page / per_page

• Webhooks available: Yes

• Webhook notes: Judge.me supports outbound webhooks that fire on review lifecycle events. Configured via the dashboard or API.

• Alternative event strategy: Poll GET /api/v1/reviews with updated_at filter if webhooks are unavailable.

• Webhook events: review/created, review/updated, review/published, review/unpublished

• SCIM available: No
• SCIM version: Not documented
• Plan required: Not documented
• Endpoint: Not documented

Limitations:

• No SCIM support documented.
• No SSO or IdP integration (Okta, Entra, Google Workspace, OneLogin) available.
• User provisioning/deprovisioning must be done manually through the Judge.me dashboard.

Three primary integration patterns are supported by the documented API.

First, bulk-export of reviewer contact data via paginated GET /api/v1/reviews (per_page max 100); note that the same customer email may appear across multiple review records with no native deduplication, so identity consolidation must be handled client-side.

Second, programmatic review import via POST /api/v1/reviews - there is no idempotency key, so duplicate submissions will create duplicate review records; deduplicate before sending.

Third, event-driven workflows via outbound webhooks on review lifecycle events (review/created, review/updated, review/published, review/unpublished). webhook payloads are not signed, so validate the shop_domain field in the payload against your expected value to confirm source integrity.

Bulk-export reviewer contact data

1. Authenticate with your shop api_token.
2. GET /api/v1/reviews?api_token=TOKEN&shop_domain=SHOP&per_page=100&page=1
3. Extract reviewer.name and reviewer.email from each review object.
4. Increment page until the returned array is empty.

Watch out for: Reviewer emails are tied to individual reviews; the same customer may appear multiple times across reviews with no deduplication.

Programmatically import reviews (e.g., from another platform)

1. Obtain api_token from Judge.me dashboard under Settings > Integrations > API.
2. For each review, POST /api/v1/reviews with reviewer_name, reviewer_email, rating, title, body, and the product id.
3. Check the response for the created review id and store it for reference.

Watch out for: There is no idempotency key; duplicate POSTs will create duplicate reviews. Deduplicate on your side before importing.

React to new published reviews via webhook

1. In the Judge.me dashboard, navigate to Settings > Integrations > Webhooks.
2. Add a webhook URL and subscribe to the review/published event.
3. Receive the POST payload containing the review object including reviewer name and email.
4. Use the payload to trigger downstream workflows (e.g., CRM update, loyalty points).

Watch out for: Webhook payloads are not signed by default; validate the source by checking the shop_domain field in the payload against your expected value.

The most significant API caveat is the absence of any user provisioning surface: reviewer emails are stored as attributes of review objects, not as first-class identity records, making Judge.me incompatible with automated lifecycle management pipelines that depend on a user API or SCIM endpoint.

Rate limits are not publicly documented - treat them as unknown and implement exponential back-off on all polling loops. The shop_domain parameter is required on most endpoints; omitting it returns a 422 error. No official SDK is published, so all integrations require raw HTTP calls.

For teams building on an MCP server with 60+ deep IT/identity integrations, Judge.me's API should be treated as a review-data source only, with no identity graph contribution beyond reviewer email extraction from review payloads.