Yelp Reviews API Returning an Empty Array? Check Filters and Pagination

Saved Gary Danko response	Review rows returned	Reported count	Page metadata	Diagnostic conclusion
A: populated review page	3	6149	current_page=1, per_page=3	One page collected, not the entire history
B: reviews=[]	0	null	Page 1, total_pages=1, next=null	Empty response with an unknown total

Three review rows and an empty array are separate test cases

A Yelp reviews API returning an empty array does not, by itself, prove that a restaurant has no reviews. These saved responses concern the same Gary Danko business, but they are separate observations, not a controlled experiment establishing why the second response was empty. Do not assign the cause to language, keywords, permissions or a temporary failure without further evidence.

Start an incident record with the requested business, every supplied parameter, retrieval time and a redacted response. Record HTTP status separately from the platform envelope's code, message and data. Gateway code=200 indicates business success; HTTP 200 alone is insufficient. A transport failure, a business failure and a successful empty collection need different handling.

Only inspect the review array after establishing success and extracting the operation payload from data. A missing reviews field or an unexpected type is a schema problem, not an empty review page. Keep the two saved cases separate when testing your parser.

Treat count=6149 and count=null as different states

In response A, 6149 is the reported count; three is the number of rows actually received. Neither number proves that the remaining reviews can all be retrieved. In response B, null supplies no usable total. Preserve it as unknown rather than converting it with count or 0.

Keep three measurements separate: rows on this page, unique reviews collected so far, and the response's reported total. Do not replace one with another in an export summary. Likewise, a review_count from business details describes another response, not the coverage of this review request.

Even total_pages=1 alongside an empty array belongs to that particular response. Retain the metadata, but do not promote it into a claim that the whole business has zero reviews. An unknown total should remain visible in downstream reports, not disappear behind a zero-valued progress bar.

Freeze one business, then change only one review filter

First confirm the branch. If you only have a name, quick-search accepts query and location, with an optional limit. It can return broad keyword matches and nearby-city listings, not just exact-name matches. Compare business names and addresses, then use details to check the chosen branch. Taking the first result can send every subsequent review request to the wrong location.

For a confirmed business, save a baseline without optional keyword, rating, original-language or translation inputs. Keep the business reference, sort order and page size fixed while changing one input at a time:

• query selects a review keyword; omit it for the unfiltered baseline.
• rating accepts comma-separated star ratings, such as 1,2.
• language selects the reviews' original two-letter language code, such as en.
• translate_to requests an additional translation; it is not a substitute for language.

These are documented inputs, not evidence that every combination returns populated results. Preserve the requested filters with each response so a later empty page can be compared with the correct baseline.

Use an authorized platform key from the dashboard, not a Yelp password or session cookie. This manually executed request reproduces the inputs of saved case A; it does not guarantee the same rows today. Opening the guide or copying the example sends no request.

curl --get 'https://api.opendata-api.com/api/project/yelp/business-reviews?key=YOUR_API_KEY' \
  --data-urlencode 'business=gary-danko-san-francisco' \
  --data-urlencode 'sort_by=newest' \
  --data-urlencode 'page=1' \
  --data-urlencode 'page_size=3'

Replace YOUR_API_KEY only in a server-side environment. Because the key travels in the query string, redact complete request URLs from logs, tickets and exception reports. Do not put a working key in a shared notebook or repository.

Check current_page and returned rows before requesting another page

The business-reviews contract documents page defaulting to 1, with a range of 1–1000. page_size defaults to 20, with a range of 1–49. The three-row diagnostic page is not a three-review ceiling, and increasing page size is not a promise of more available reviews.

For each successful page, compare the requested page with current_page. Record per_page, the actual array length, review IDs, next and total_pages. Check these together before deciding whether another page is justified. Do not follow a returned navigation value blindly or substitute a different route for the documented operation.

Pause on a page-number mismatch, a fully repeated page, contradictory navigation or an unexpected empty array. Save the response for review rather than declaring the export complete. Unknown totals are not an instruction to increment page numbers indefinitely. Set a request budget and bounded retries with backoff for transient failures; do not repeatedly retry an unexplained empty page as if success were inevitable.

Checkpoint partial exports instead of labeling them complete

Commit each page's rows and its checkpoint together before advancing. Your application-owned checkpoint should retain:

• The confirmed business reference, all filters, sort and requested page size.
• The requested page, returned page metadata and actual retrieval timestamp.
• The nullable reported count, returned row count and cumulative unique count.
• Saved review IDs, the last validated page and any page awaiting investigation.
• An explicit coverage state such as partial, plus the reason collection stopped.

These are local bookkeeping fields, not additional API parameters or promised response properties. Keep credentials out of checkpoints. Deduplicate using the business identity and review ID, retain retrieval dates, and version changed text if your use case requires it.

After interruption, recheck the last saved page before resuming. A changed filter starts a separate collection run. newest ordering is not a guaranteed incremental cursor: newly added reviews can move older rows between numbered pages while collection is underway.

A report should say how many unique reviews were collected and which pages remain unresolved. Hitting a request budget, retry limit or documented page ceiling is a stopping condition, not evidence of complete history.

State the limits: unknown totals, missing reviews and API differences

This independent Yelp data project has its own contract. Do not import the official API's authentication, pagination, language rules or three-review excerpt assumptions. The saved rows included text, but that does not establish that every review contains complete, untruncated text or that all historical reviews are accessible.

Review topics, highlights and topic-specific reviews are different analytical views. Obtain a topic for the same business before requesting reviews by topic; a highlight count is not a representative sentiment percentage. Keep not-recommended reviews separate from ordinary review analysis, and do not treat recommendation status as a fraud finding.

Menus, photos and other business content also vary by listing. A populated menu or photo response does not fill missing reviews, prove complete coverage or grant redistribution rights. Only selected operations have saved response observations; the 27 retained operations must not be described as all live-tested.

Check current Yelp project pricing and account terms rather than assuming a free allowance. Confirm access, storage, analysis, attribution and republication rights for your actual use. Unknown totals, missing reviews and unverified filter combinations remain delivery limits even when a request succeeds.