Rotten Tomatoes movie reviews API

Endpoint facts

Method

GET

API path

/rottentomatoes/movie/reviews

Auth

apiKey

Credits

3 credits/request

Charged on

Successful 2xx responses only

Platform

Rotten Tomatoes

Execution

Managed browser rendering where the target needs it

Response schema

#/definitions/rottentomatoes.reviewsResponseDoc

How this endpoint behaves

Query parameters:

• path: Rotten Tomatoes movie path, for example /m/inception.
• url: absolute https://www.rottentomatoes.com movie URL.
• type: review type. Allowed values: critics, top-critics, audience, verified-audience.
• limit: reviews per page. Defaults to 10; maximum 20. A page holds limit reviews, or fewer at the end of a list.
• after: pagination cursor. Pass data.page_info.end_cursor from the previous response and keep limit the same on every page of one walk. A critic cursor is a page index encoded as base64 (MQ== is page 2), so it points at a position of index × limit reviews: changing limit between pages repeats or skips reviews. Audience cursors are opaque keyset values and should be passed back unchanged. The feed can serve up to 500 reviews; the browser fallback is capped at five pages (100 reviews at the maximum page size). Invalid cursors are rejected before upstream work.

Three transports, reported in data.transport

Rotten Tomatoes serves each review list as a JSON feed. The service reads that feed directly and keeps the page-render and embedded-sample paths as fallbacks, so a caller gets the same response shape whichever path served it.

• data.subject identifies what the feed is about. Its kind is one of movie, season, episode, critic or publication; this endpoint sets movie. The movie field remains present for compatibility. (The season, episode and critic kinds belong to the dedicated /rottentomatoes/season/reviews, /episode/reviews and /critic/reviews endpoints.)
• data.transport is feed_api in the normal case, for all four type values. It is one request per page: the reviews are newest-first, each has a stable id, ISO created_at/updated_at timestamps, the critic identity and the original article URL, and data.page_info carries has_next_page and end_cursor. audience and verified-audience are served from the same feed, so a verified-audience response is a full paginated list, not a six-review sample. A title with no reviews yet, or a top-critics, audience or verified-audience list that is still empty, is a real answer: the response is 200 with reviews: [] and has_next_page: false, charged as a normal call.
• data.transport is browser_render when the feed could not be read and the movie's own review page could: the service loads the page the way a visitor's browser does, lets that page request the list itself, and reads what the page receives. Nothing is generated or replayed outside the page. Those responses also carry data.render. The browser path is bounded to page 5 (100 reviews), because every page beyond the first costs a click.
• data.transport is public_page as the last resort: for a page-0 request whose feed and render both failed, the response holds the about-six reviews the movie page embeds, has no cursor, and sets data.public_page_derived to true.
• If the full list cannot be read for the first page by either path, the response falls back to that public-page sample, reports transport: public_page, and fills data.render_error with the reason. A request with after has no fallback, because the public page cannot supply another page, and returns an upstream error instead.

Notable response behaviour:

• data.render is present for browser_render responses and records how many distinct review pages were loaded, how many "Load More" steps were needed, and the total time in milliseconds. It is an audit record, not a cache age. feed_api responses have no render block.
• data.reviews_api_url is the review-list request on the Rotten Tomatoes website that corresponds to the requested page. It identifies the page; it is not necessarily the request that served the response, and it cannot be fetched by an ordinary HTTP client.
• data.source_url is the public review page for the requested list, for example https://www.rottentomatoes.com/m/clayface/reviews/all-critics.
• created_at is the review's upstream creation time in ISO 8601 (for example 2026-10-28T22:12:45.000Z) for feed_api and browser_render responses. It is not a record of when a review became visible on the site, and it is not the display text on the page. For public_page responses created_at is only what the page prints, which for older films is a calendar date (Mar 20, 2024) and for a film in its first day or two is relative text such as 2 hrs ago.
• updated_at is set when a review was edited after it was created, and status is the upstream review status (normally ACTIVE).
• rating and rating_label are the audience star rating: rating is the numeric value (4.5) and rating_label the upstream label (STAR_4_5). Critic reviews carry original_score instead when the critic published a score (4/5, B+).
• publication_review_url links to the original article. Corrections and removals are not reported.
• Review type values other than critics, top-critics, audience, and verified-audience are rejected before upstream IO.
• Blocked requests, malformed review data, and parser drift return upstream errors.

Freshness and cost

• data.fetched_at is the UTC time, to the second, when the Rotten Tomatoes data behind the response was fetched. A cached response keeps its original time.
• The same instant is in the X-Availability-Last-Success-At response header (RFC 3339, sub-second), and X-Availability-Last-Success-Age-Seconds gives the age of the data in whole seconds. X-Cache is miss for a live fetch and hit for a reused response.
• Identical requests are reused for about 30 seconds, and each distinct request is cached on its own. A reused response is still charged as a normal call, and there is no way to bypass the cache. Polling more often than that returns the same data.
• A call that could not read the full feed and returned the public-page sample instead (transport is public_page and render_error says why) is not charged. That includes a reused copy of such a response. A feed_api or browser_render response is charged as usual.
• If the live fetch fails, a saved copy at most 5 minutes old may be served instead, marked by X-Availability-Mode: stale and X-Stale-Cache: hit.
• A feed_api response reads the movie page and then the review list, and normally returns in a few seconds (4 to 8 seconds measured). A browser_render response loads a real page, so it is much slower, about 16 seconds for the first page and about 43 seconds for the fifth (each deeper page takes extra time). The first call after a quiet period of about five minutes takes roughly 5 to 8 seconds longer. Concurrent callers may wait briefly, bounded by their own request deadline.
• Rotten Tomatoes can also serve from its own cache for a couple of minutes, so fetched_at is the latest the data could have been captured, not the time a review was published.

Live monitoring

Monitored request

GET /rottentomatoes/movie/reviews?limit=5&path=%2Fm%2Finception&type=critics

Checks passed, 7 days to 14 Oct 2026

100%

Median response time

0.74 s

Current status of every endpoint

Sampled response

Request, 14 Oct 2026

GET /rottentomatoes/movie/reviews?limit=10&path=%2Fm%2Finception&type=critics

Items in reviews

6

Fields filled in every checked item

17

Fields empty in some or all items

1

Shared guides

Related