An online reviews API is a single interface for reading customer reviews and posting replies to them. It works across review surfaces. You do not integrate each platform's native review endpoints by hand. In practice today the primary programmatic review surface for businesses is Google Business Profile. A verified owner or manager can list reviews for a location, batch-get reviews across many locations, and reply to them.
A reviews aggregation API takes those reviews and normalizes them. Rating, author, text, time, and reply collapse into one consistent Review object. Your code gets one shape to render and respond to. This is the same pattern described in the unified social inbox API pillar, applied to the review surface specifically. This guide covers which platforms expose reviews, how the Google Business Profile verification gate works, how cross-location and cross-source aggregation works, the read versus reply versus report distinction, the reputation-monitoring use case, and a working example.
What is an online reviews API and which platforms expose reviews?
An online reviews API is an abstraction. It exposes customer reviews (a rating, an author, free text, a timestamp, and an optional owner reply) through one consistent interface. You do not write one client per review source. The distinction that matters: reviews are not comments. A comment is public chatter on a post you own. A review is a rating-plus-text attached to a business entity, with its own lifecycle and its own reply mechanic. Treating them as the same surface is the most common modeling mistake.
Which platforms actually expose reviews programmatically is a short list. Being honest about it is the whole point. Google Business Profile is the primary surface a developer can read and reply to through an official API. Several large social platforms have either deprecated their ratings and reviews product or never exposed reviews through a general developer API at all. As a result, a reviews API that claims broad coverage is usually overselling. The realistic posture in 2026: build for Google Business Profile reviews as the core surface, and treat anything else as additive rather than guaranteed.
The job an online reviews API solves is not novelty, it is consolidation. If reviews are a feature of your product (a reputation dashboard, an agency reporting tool, an AI agent that drafts owner replies), the review integration is undifferentiated work. Your users do not pay you for OAuth token refresh or for parsing one provider's review schema. They pay you for what you do with the rating and the text once it is in a normal shape.
How does Google Business Profile review access work?
Google Business Profile is the surface most online reviews APIs are really built around. Its capabilities are specific. The Business Profile APIs support working with review data: listing the reviews for a location, batch-getting reviews across multiple locations in one call, and replying to a review as the business. Each review carries a star rating, the reviewer's display name, and the review text. It also carries timestamps for when it was created and last updated, plus the business reply if one exists (Google Business Profile review data documentation).
The gate is verification, not payment. Review access requires a verified Google Business Profile. The authenticated account must be an owner or manager of the location whose reviews you are reading or replying to. This is an account-ownership and verification requirement, not a plan tier. You cannot read an arbitrary business's reviews through this API. You read the reviews of profiles you control. That single fact shapes the entire product: a reviews API here is a tool for businesses managing their own reputation, not a scraper of competitors.
The fields you get back are stable and predictable, which is what makes normalization clean. A rating maps to a numeric star value. The reviewer maps to an author. The review body maps to text. The create and update times map to a timestamp. The owner response maps to a reply field that is either present or absent. Those five fields are the entire normalized contract, and they are enough to build a reputation surface on.
How do you aggregate reviews across locations and platforms into one feed?
Two axes define what a reviews API actually consolidates: locations and sources. The first axis is locations. A multi-location business has reviews scattered across every storefront's Business Profile. A useful feed merges them into one stream you can sort by recency or by rating. The second axis is sources. Where a platform other than Google exposes reviews, the same normalization step folds it into the same Review object. A single consumer then renders all of it.
Reviews from Google Business Profile (the dominant source) and other platforms, across many locations, normalize into one Review object. Proxied in real time, not stored, because rating and text can change after the review is posted.
In our integrations the hard part of aggregation was never the merge, it was the normalization underneath it. Every source models a review differently: the star scale, the way the author is represented, whether the reply is a nested object or a separate call, how timestamps are formatted. Aggregation only works if all of that is collapsed into one shape first. Because if it is not, you have a list that mixes incompatible objects. That is aggregation in name only and a switch statement in practice.
A reviews aggregation API does the collapse for you. You connect each location's profile once. From then on the reviews arrive in one Review object regardless of which location or source produced them. In practice, sorting a unified feed by recency across many storefronts becomes one query, not a stack of paginated calls you have to interleave by hand. The aggregation is the product. The per-source parsing is the part you stop owning.
What is the difference between reading, replying, and reporting reviews?
A reviews API has a small, well-defined set of actions. Conflating them causes most integration bugs. Reading lists reviews for a location and batch-reads across locations. Replying posts an owner response to a specific review. That is the one write operation most reputation workflows need. Reporting (flagging a review as inappropriate or fake) is a moderation-style action. It depends entirely on what the underlying platform exposes, and it is the least universally available of the three.
| Capability | What it does | Availability |
|---|---|---|
| Read (list) | List reviews for a location with rating, author, text, time | Core surface on Google Business Profile |
| Read (batch) | Get reviews across many locations in fewer calls | Core surface on Google Business Profile |
| Reply | Post or update the business owner response to a review | Available where the platform exposes an owner-reply write |
| Report / flag | Flag a review as inappropriate or fraudulent | Platform-dependent; least universally exposed |
| Delete a review | Remove a reviewer's review | Not an owner action; reviewers and the platform control this |
The storage question is just as important as the capability question. SocialAPI.ai proxies reviews in real time and does not store them. The reason is correctness, not a limitation. A review's rating and text can be edited by the reviewer after it is posted, and an owner reply can be added or changed later. A stored copy goes stale silently, so the system reads the current state from the source on each request rather than serving a snapshot that may no longer be true.
Real-time proxying has a practical consequence for how you design around it. The review you render is the review as it exists now, not as it existed when you first ingested it. We have seen reviewers revise a rating upward after an owner reply lands, and a reputation dashboard wants the current value, not the cached one. The Review object also carries a stable id whose prefix is sapi_rev_. As a result, deduplication and reply dispatch work without a database lookup on your side.
What does the reputation-monitoring use case look like?
Most teams reach for a reviews API to monitor reputation, and that workload has a consistent shape. A business wants to know the moment a new review lands. It wants to route negative reviews to a human fast. It wants an owner or an agent to post a reply without leaving the dashboard. Reviews are one input here. Mentions are the other. Together they form the brand-monitoring pair: reviews are owned surfaces you can respond on, and mentions are other people's surfaces you mostly observe.
The review side and the mention side are usually built together. They answer the same business question from two directions. Reviews tell you what customers say on a surface you control. A social media mentions API tells you what they say everywhere else. A complete reputation tool watches both. It wants both delivered in the same normalized envelope, so one triage queue handles a fresh negative review and a critical mention with the same code path.
Delivery method matters for reputation work because latency is the whole point. Polling every location for new reviews on a tight interval burns request budget on storefronts that are quiet most of the time. By contrast, pushing new reviews to your endpoint the moment they arrive is the pattern that hits a fast response SLA. That approach is covered in the social listening webhooks playbook. The mature setup is push for new reviews, pull for periodic reconciliation.
What does one reviews API call look like?
The point of a reviews API is simple. Reading reviews and replying to them are ordinary HTTP calls returning one shape, not a set of provider-specific clients. Reading lists the reviews for a connected account in the normalized Review object. Replying posts an owner response to a specific review by its stable id. It uses the same interaction-reply call shape used for a comment or a DM, because the platform is decoded from the id server-side rather than branched on in your code.
# Read reviews for a connected Google Business Profile account.
curl https://api.social-api.ai/v1/accounts/$ACCOUNT_ID/reviews \
-H "Authorization: Bearer $SOCAPI_KEY"
# Reply to one review by its stable interaction id (sapi_rev_...).
curl -X POST \
https://api.social-api.ai/v1/accounts/$ACCOUNT_ID/interactions/$REVIEW_ID/reply \
-H "Authorization: Bearer $SOCAPI_KEY" \
-H "Content-Type: application/json" \
-d '{ "text": "Thanks for the feedback. We have followed up by email." }'{
"data": [
{
"id": "sapi_rev_Z29vZ2xlOmxvY2F0aW9uMS9yZXZpZXcx",
"type": "review",
"platform": "google",
"account_id": "acc_01HZ9X3Q4R5M6N7P8V2K0W1J",
"author": { "name": "Dana R." },
"rating": 4,
"content": { "text": "Quick service, friendly staff." },
"created_at": "2026-05-14T09:21:00Z",
"updated_at": "2026-05-15T11:02:00Z",
"reply": { "text": "Thanks Dana, see you next time." }
}
]
}The data array is the same envelope returned for comments, DMs, and mentions. Review-specific fields (rating, the reviewer as author, the timestamps, the optional reply) are populated. That is the entire promise of a reviews aggregation API in one response: one parser, one reply call, one feed across locations. The exact endpoint paths, parameters, and the full field reference live in the SocialAPI.ai API documentation so they stay current rather than drifting in a blog post. For the platform-specific connection flow and the verification requirement, see the Google reviews API page.
Frequently asked questions
- What is an online reviews API?
- An online reviews API is a single interface for reading customer reviews and posting owner replies across review surfaces, instead of integrating each platform's native review endpoints separately. It normalizes the rating, author, text, timestamp, and any owner reply into one Review object so one piece of code can render and respond to reviews regardless of which source produced them. The primary programmatic review surface for businesses today is Google Business Profile.
- Which platforms expose reviews through an API?
- Google Business Profile is the primary surface a developer can read and reply to through an official API: a verified owner or manager can list a location's reviews, batch-get reviews across locations, and post owner replies. Several large social platforms have deprecated their reviews product or never exposed reviews through a general developer API, so a reviews API that claims broad multi-platform review coverage is usually overselling. Build for Google Business Profile as the core surface.
- Do I need a verified Google Business Profile to use the reviews API?
- Yes. Review access on Google Business Profile requires a verified Business Profile, and the authenticated account must be an owner or manager of the location whose reviews you are reading or replying to. This is an account-ownership and verification requirement, not a paid plan tier. You read and respond to the reviews of profiles you control; you cannot pull an arbitrary business's reviews through this API.
- Can I aggregate reviews from multiple locations into one feed?
- Yes, cross-location aggregation is the main value of a reviews API. A multi-location business has reviews scattered across each storefront's Business Profile. A reviews aggregation API normalizes every review into one Review object and merges them into one stream you can sort by recency or rating, so reading fifty storefronts becomes one query instead of fifty paginated calls you interleave by hand.
- Are reviews stored or fetched in real time by SocialAPI.ai?
- SocialAPI.ai proxies reviews in real time and does not store them. A reviewer can edit a review's rating or text after posting, and an owner reply can be added or changed later, so a stored copy goes stale silently. Reading the current state from the source on each request means the review you render is the review as it exists now, which is what a reputation dashboard needs.
- Can I reply to a review through the API?
- Yes. Replying posts or updates the business owner response to a specific review, using the same interaction-reply call shape used for a comment or a DM. Each review has a stable id with a sapi_rev_ prefix, and the platform is decoded from that id server-side, so you do not branch on platform in your code. Reply availability depends on the underlying platform exposing an owner-reply write.
- Can I delete or report a review through the API?
- Deleting a review is not an owner action; reviewers and the platform control review removal, so a reviews API does not let a business delete a customer's review. Reporting or flagging a review as inappropriate or fraudulent is platform-dependent and the least universally exposed action. Reading and replying are the two operations you can rely on as the core of a reputation workflow.
Treat an online reviews API as a consolidation decision, not a feature gimmick. If reputation is part of what you ship, the model in this guide is the substrate to build on: Google Business Profile as the core surface gated on verification, one normalized Review object, real-time proxying instead of stored snapshots, and reply as the same call shape as any other interaction. Pair it with mentions for full brand coverage. Push new reviews through webhooks for a fast SLA. Check the API documentation for the exact endpoint and field reference rather than a post that would drift.
Factual references in this guide are linked inline so each capability can be checked at its source. Primary source: Google Business Profile: review data (list reviews, batch-get across locations, reply to reviews; access requires a verified profile)