We integrated 32 review platforms into one API. Here is what each one actually lets a developer do, as of October 2026. Full report with the per-platform table: https://prismareviews.com/guides/state-of-review-platform-apis-2026
The numbers
| Measure | Count |
|---|---|
| Platforms in the report | 32 |
| Let the owner reply to reviews by API | 8 (25%) |
| Read only for third parties | 24 (75%) |
| Expose an official reviews API the owner can authorise | 16 (50%) |
| No usable third-party reviews API (public page only) | 16 (50%) |
| Official API gated behind a paid plan or add-on | 4 |
| Official API gated behind manual approval of the integrator | 4 |
| Push notifications for new reviews to third parties | 1 (Google, and only with Cloud Pub/Sub) |
Read the first two rows together: if you build a product that "replies to reviews", only a quarter of the platforms your customers care about will let you, and on every one of them you need the owner's own authorisation.
1. Replies are the exception
The 8 platforms with a reply API: Google Business Profile, App Store, Google Play, Judge.me, Trustpilot, eBay, Trusted Shops and eKomi. Even there the rules differ:
- Google caps a reply at 4,096 bytes and 10 edits per minute per profile, and needs the
business.manageOAuth scope. - Judge.me can create a reply but never edit or delete it by API.
- Apple and Google Play allow create, update and delete, with an App Store Connect key (Customer Support role) or a Play Console service account.
- Trustpilot's reply API comes with its API module, sold to the business, not to the integrator.
The other 24, including Yelp, Tripadvisor, Booking.com, G2 and Capterra, expect the owner to answer in their own dashboard. The honest design for a multi-platform product: a reply endpoint that returns 422 reply_not_supported plus a link to the review on the platform, instead of pretending.
2. Half the platforms have no reviews API at all
16 of 32 give a third party nothing better than the public listing page:
- Never had one: OpenTable, DoorDash, Checkatrade, Avvo, Angi, Apartments.com, Capterra, Salesforce AppExchange.
- Had one and closed it: Facebook removed the Page ratings API in Graph API v22.0; Booking.com paused new connectivity partners; Tripadvisor's Content API returns a handful of reviews for display, not an owner feed.
- Public read endpoints with no merchant credentials: Steam, WordPress.org and Etsy.
Yelp is the edge case: its Fusion API exists, but returns 3 review excerpts per business.
3. Access is gated by process more than by code
Of the 16 platforms with a usable official API:
- Manual approval of the integrator: Google Business Profile, Trustpilot, eBay (and Etsy for its public reviews API). Google requires a Business Profile verified for 60+ days before you can even apply.
- Paid plan on the business's side: Trustpilot (API module), REVIEWS.io (Plus plan), Loox (Convert or Unlimited), ProvenExpert (Premium or Enterprise).
- Just credentials: App Store Connect, Google Play, Judge.me, Yotpo, G2, Okendo, Feefo, Trusted Shops, eKomi, Shopper Approved.
4. Nobody pushes
Only Google offers notifications for new reviews, and only through the Notifications API plus a Cloud Pub/Sub topic you run. Everyone else: you poll, within each platform's quota (Google Play: 200 reads per hour per app; Google: 300 QPM shared across the whole project).
What this means if you are building on reviews
- Design for read-only first. Replies are a feature of 8 platforms, not of "reviews".
- Budget for approvals in calendar time, not engineering time. Google alone is 60 days of verification plus the review of your application.
- Store history yourself. Google Play returns 7 days; Yelp 3 excerpts; some platforms change their mind (Facebook).
- Normalise early. 32 JSON shapes, 4 rating scales (5 stars, 10 points, thumbs, recommend/not), 3 date formats.
The per-platform table (read, reply, access type, gate, webhooks) is in the full report: https://prismareviews.com/guides/state-of-review-platform-apis-2026. The access rules for each platform, with the connection body you send, are on https://prismareviews.com/which-review-platforms-have-an-api.
If a platform in the list has changed its API since October 2026, tell me in the comments and I will update the report.
Top comments (8)
The 422 reply_not_supported endpoint is the honest move. Pretending replies work everywhere just fails quietly on the other 24.
Thanks, that was the reasoning. A silent no-op is worse than an error: the team thinks the customer got an answer and nobody did. With the 422 your code knows straight away, and every review carries its url, so you can send someone to answer it on the platform itself. Curious whether you’ve run into the same thing with other APIs.
The review URL in the 422 is the part that saves it. Without that link, the error is just a dead end.
Exactly. That’s also why the link is on every review, not just in the error: on read-only platforms the client can show an “Answer on Yelp” button from day one, before anyone tries to reply. Thanks for reading closely.
Good point about the read-only case. Putting that button in from day one beats waiting for someone to hit the error first.
The create-only reply case is where I'd make the API contract expose an unknown outcome, not just success/failure. If a connection drops after the provider accepts a reply, blindly retrying could publish twice, and your adapter can't undo it. I'd persist the attempted reply's identity and reconcile against the remote review before offering another send. A stable idempotency key in the unified API is useful, but it shouldn't promise exactly-once delivery when the underlying platform offers no equivalent guarantee.
Agreed, and thanks for spelling it out. Today Prisma exposes three reply states (
pending,published,failed), anIdempotency-Keyon the request so the same call never queues twice, and retries at the job level for transport errors. Your case is the gap: a create-only platform like Judge.me, whose reviews API doesn't expose replies, so after an ambiguous failure we can't reconcile by reading back. Retrying there is the wrong default.The change we're making: on create-only platforms, an ambiguous failure after the request was sent ends in a fourth state,
unknown, with no automatic retry and a webhook so a human decides. On platforms that do return replies (Google, the app stores) we reconcile against the remote review first and retry only when it's confirmed absent. The idempotency key stays a client-side guarantee only, as you say.Shipped, same day. Replies that get no answer from the platform now end as
unknown(withreply.errorand areply.unknownwebhook) on Judge.me, eBay, Trusted Shops and eKomi, with no automatic retry; on Google Business Profile, the App Store and Google Play we read the review back first and only retry when the reply is confirmed absent. Docs: prismareviews.com/docs/api-referen... (step 5). Thanks again for the push.