What I learned integrating 25 review platforms into one API

Every review platform looks the same from the outside: a star rating, a text, an author, maybe a reply. Getting at that data looks nothing alike.

I spent the last months building Prisma Reviews, a single REST API for reviews, and these are the notes I wish I'd had on day one.

1. There are four kinds of "review API"

Once you've done a few platforms, every one falls into one of four kinds:

• OAuth, business-owner API - Examples: Google Business Profile, Trustpilot - How you connect: The owner approves your app - Can you reply? Yes
• Keys from a developer console - Examples: App Store Connect, Google Play - How you connect: The owner creates a key and gives it to you - Can you reply? Yes
• Shop-app tokens - Examples: Judge.me, Trusted Shops, eKomi, Okendo - How you connect: An API token from the platform's admin - Can you reply? Sometimes
• No owner API at all - Examples: Yelp, Tripadvisor, Booking.com - How you connect: Only the public listing URL - Can you reply? No: link to the platform

Each kind needs its own onboarding UI, its own error handling and its own way to refresh credentials. If you design for only one, the next one won't fit.

2. Access is the real bottleneck, not code

The code for a connector is usually a day or two. Getting permission takes far longer:

• Google Business Profile needs an access application. It's reviewed by hand, and the default quota is very low until you're approved.
• Trustpilot sells API access as a paid add-on to the business, not to you.
• eBay and Etsy need a developer app per integrator, with their own review of your use case.
• Apple and Google Play are the easy ones: the owner creates a key in their console (an App Store Connect .p8 key, a Play service account) and you can start right away.

The lesson: ship the platforms with self-serve keys first, apply for the gated ones on day one, and be honest in your UI about which ones are still waiting.

3. Normalise early, and keep the original

Every platform has its own field names (starRating: "FOUR", rating: 4, stars: "4.0"), dates (ISO, Unix seconds, "2026-10-19 12:41:07 +00:00") and ideas of what an "author" is.

We map everything into one shape:

{
  "id": "rev_01KJ8Q2M4T7HX3VB9CWD6NRZ5E",
  "platform": "app_store",
  "rating": 4,
  "title": "Great, one bug",
  "text": "Love the app, the widget crashes on iOS 19.",
  "author": "marta_g",
  "language": "en",
  "created_at": "2026-10-19T12:41:07.000Z",
  "reply": {
    "text": "Thanks! Fixed in 3.2.",
    "status": "published"
  }
}

Two rules that saved us later:

• Ratings are integers 1-5 or null. Some platforms allow reviews with no rating, so a missing rating is null, never 0.
• Prefer the original text over the translation. Several sources auto-translate reviews to the reader's language. Store what the customer actually wrote and its language.

4. Polling is fine if you're honest about cost

Most platforms have no webhooks, so you poll. That's fine for official APIs, where calls are free and rate limits are generous. It's not fine when every read costs you money (scraped sources charge per review).

What worked for us:

• Poll official APIs often (every 15-60 minutes).
• Poll paid sources rarely (every 6-24 hours), always ask for "newest first", and stop at the first review you've already seen.
• Reserve a budget before every paid job and cap the job at that budget, so a bug can't spend a month's margin in an hour.
• Expose one webhook (review.created, review.updated) to your users, whatever the platform does underneath.

5. Replies are a queue, not a request

Publishing a reply can take seconds (Apple), fail because the review was deleted, or be rate-limited. So POST /reviews/{id}/reply returns at once with status: "queued", a worker publishes it, and a reply.published or reply.failed webhook tells you how it went.

Idempotency keys stop a retry from posting the same reply twice, and a customer reading the review a second later sees a queued reply instead of none.

6. Make it testable without a real account

The biggest friction for a developer trying a reviews API is "I need a real business with real reviews first". Test keys (pk_test_…) that return realistic sample data for every platform let someone build the whole integration before connecting anything real. They're also what we use in our own test suite.

7. Agents are users too

A surprising share of our early traffic was AI agents reading docs. Three cheap things helped:

• Every docs page is also available as Markdown (add .md to the URL), and there's an llms.txt file.
• GET /v1/platforms returns, for each platform, which fields to send, the steps the owner follows and an example body. An agent can connect a platform without reading the docs.
• Error responses include required_fields and an example, so the next request can fix itself.

Wrapping up

If you're integrating reviews from more than two platforms, the time goes into access, normalisation and cost control, not HTTP calls. That's the work we packaged into Prisma Reviews. It's free for 2 locations, with test keys for every platform.

If you'd rather build it yourself, I hope the notes above save you a few weeks. Questions about a specific platform's API? Ask in the comments. I've probably hit the same wall.