Restaurants Data: Inspection Records, Global Footprints and Review Corpora · Head-to-head
UK Food Hygiene Rating Scheme (FHRS) Open Data vs Foursquare Places API
Which restaurants data: inspection records, global footprints and review corpora data fits your job: UK Food Hygiene Rating Scheme Open Data, or Foursquare Places API. API, files, or your warehouse. Daily, weekly, or hourly.
UK Food Hygiene Rating Scheme (FHRS) Open Data
Foursquare Places API
Where the fields line up
No shared field names. These two answer different questions.
| Field | UK Food Hygiene Rating Scheme Open Data | Foursquare Places API |
|---|---|---|
Establishment identifier | documented | not in this set |
Business name | documented | not in this set |
Business type | documented | not in this set |
Address and postcode | documented | not in this set |
Geocode | documented | not in this set |
Hygiene rating value | documented | not in this set |
Rating key | documented | not in this set |
Inspection date | documented | not in this set |
Component inspection scores | documented | not in this set |
Scheme type | documented | not in this set |
Local authority | documented | not in this set |
New rating pending flag | documented | not in this set |
Coverage, side by side
| UK Food Hygiene Rating Scheme Open Data | Foursquare Places API | |
|---|---|---|
| Geographic | United Kingdom - England, Wales and Northern Ireland under FHRS, Scotland under FHIS, across ~380 local authority feeds | Global - 100M+ points of interest across 200+ countries and territories, aggregated from 100,000+ sources |
| Temporal | One RatingDate per business anchoring the current rating; extracts re-dated daily | Lifecycle timestamps per venue - date_created, date_refreshed, date_closed - refreshed continuously |
What each contains
Pick by fit, not by loyalty.
| UK Food Hygiene Rating Scheme Open Data | Foursquare Places API | |
|---|---|---|
| Publisher | Food Standards Agency, holding the data on behalf of participating local authorities | Foursquare |
| Subject lens | Regulatory view: the hygiene verdict of an official inspection - 0-5 rating, sub-scores, inspection date, right-to-reply | Commercial view: what a place is and how it trades - cuisine, price tier, hours, chains, popularity |
| Geographic coverage | United Kingdom - England, Wales and Northern Ireland under FHRS, Scotland under FHIS, across ~380 local authority feeds | Global - 100M+ points of interest across 200+ countries and territories, aggregated from 100,000+ sources |
| Temporal coverage | One RatingDate per business anchoring the current rating; extracts re-dated daily | Lifecycle timestamps per venue - date_created, date_refreshed, date_closed - refreshed continuously |
| Documented fields | 26, including RatingValue, RatingKey, three Scores.* sub-scores, SchemeType, NewRatingPending, RightToReply | 15 documented from a 50-plus attribute schema, including categories, chains, hours, price, rating, stats, popularity, veracity_rating |
| Scale | Hundreds of thousands of rated establishments; Camden alone publishes 4,260 records | 100M+ POIs with 1B+ photos/tips/reviews and 16B+ check-ins behind the signals |
| Best for | Compliance screening, risk underwriting, consumer badge display, cross-authority journalism | Prospecting, territory planning, site selection, global venue enrichment |
What each does better
UK Food Hygiene Rating Scheme Open Data
Regulatory standing. Every RatingValue is the outcome of an official food hygiene inspection under the Food Hygiene Rating Scheme - or Scotland's FHIS, which publishes Pass / Improvement Required statuses instead of numerals.
Detail below the headline grade. The three sub-score columns decompose each inspection - hygiene procedures, structural compliance, confidence in management - so a public 4 can hide a perfect hygiene score offset by structural findings, exactly as the Camden sample row shows: Hygiene 0, Structural 5, ConfidenceInManagement 10 behind a published 4. RatingDate dates every verdict, LocalAuthorityName names who issued it, and RightToReply carries the operator's published response.
Scale inside one jurisdiction. Hundreds of thousands of rated establishments across roughly 380 local authority feeds - Camden alone accounts for 4,260 records - with geocodes attached except where a business trades from a private address. A research-time query around central London returned 9,777 rated establishments within 2 km.
Foursquare Places API
Reach. Over 100 million points of interest across 200-plus countries and territories, aggregated from more than 100,000 sources and backed by 16 billion-plus historical check-ins. FHRS stops at the United Kingdom because it only exists where local authorities inspect; Foursquare describes any dining venue anywhere, including the ones that have never been inspected under any scheme.
Chain detection alone separates independent venues from multi-site brands, which is the difference between prospecting a neighborhood and prospecting a market.
Bulk enrichment. Place Match and Transaction Match run as offline batch jobs against an existing customer file, so matching a CRM of thousands of restaurant accounts to place records is a designed operation rather than a hand-built join.
Where they're equivalent
More than their different registers suggest. Both field dictionaries were verified during research, a bar many catalog records miss. Both geocode to individual premises rather than postal districts - FHRS supplies Geocode.Latitude/Geocode.Longitude per establishment, every Foursquare record carries latitude/longitude - which makes premise-level joins and radius work native to both. Both carry a stable primary identifier per row (FHRSID, fsq_place_id). Both keep their records current, FHRS re-dating its extracts daily and Foursquare refreshing continuously with explicit lifecycle timestamps. And both serve JSON alongside other encodings - XML on the FHRS side - placing each among the 675 catalog datasets shipping JSON. Neither publishes raw review text: FHRS holds no reviews at all, and the Foursquare record documents tip counts without the text.
The verdict
Verdict: sample both - they are different instruments pointed at the same high street, and neither substitutes for the other.
Take UK Food Hygiene Rating Scheme (FHRS) Open Data if your question has a compliance clause in it. Which premises in this postcode hold a rating of 2 or below? How old is the inspection behind that badge? Which local authorities publish the weakest distributions? Is a franchisee's estate outperforming the regional baseline? Anything answered by an official verdict dated, scored and attributable to an inspector lives here.
Teams usually discover they asked both questions in the same quarter - the UK operator screening competitors' hygiene while planning its own expansion, the proptech firm underwriting a lease against both footfall proxies and food-safety risk. The samples are scoped independently - name local authorities and rating bands on one, categories, chains and geographies on the other - and both land normalized to their documented field dictionaries.
Sample both, pick by fit. See UK Food Hygiene Rating Scheme Open Data · See Foursquare Places API
Or take both in one feed
Yes - a UK restaurant intelligence table is the natural seam. Let FHRS form the regulated spine: FHRSID, BusinessName, PostCode, RatingValue, RatingDate and the three sub-scores, one feed per local authority.
Three alignments decide whether the merge holds. First, identifiers do not interlock: FHRSID and fsq_place_id belong to different systems, so join on postcode plus normalized business name, confirmed by the geocodes both sides publish - and treat a match as provisional when the pair disagrees. Second, respect the confidence flags on both sides: FHRS marks unpublished re-ratings through NewRatingPending while appeals run, and Foursquare scores its own accuracy in veracity_rating; route low-confidence rows to review instead of the dashboard. Third, mind the unit mismatch in the rating columns: FHRS's 0-5 runs higher-is-better while its three sub-scores run lower-is-better, and none of them is comparable to a Foursquare user rating - keep them in separate columns with their own scales rather than blending into one score. Aligned that way, one feed carries the badge on the window and the economics behind the door.
API, files, or your warehouse. Daily, weekly, or hourly.
Fair questions
Do the two datasets cover the same ground?
Only partly. Both describe individual establishments with names, addresses and geocodes, so premise-level joins work. The overlap is identity; the value sits on either side of it.
Which fields overlap between the two field dictionaries?
Name, address block with postcode, latitude/longitude geocode, a dated timestamp and a stable row identifier - `FHRSID` against `fsq_place_id`.
Can Datadory deliver both datasets together?
Yes - merged or side by side, delivered daily, weekly, or hourly - your call. Each arrives normalized to its documented field dictionary (26 fields on the FHRS side, 15 on the Foursquare side) with sample rows for inspection before anything ships. The join work is postcode-and-name matching confirmed by geocode, since the two identifiers belong to different systems. Or take both in one feed.