Open Brewery DB — API Documentation

It is the interface contract for the most-cited establishment corpus in craft beer: developer documentation specifying five JSON operations over 11,822 breweries, cideries, brewpubs and bottleshops across 23-plus countries, every operation returning the same flat object rather than a bespoke payload per route.

Four of the five return establishment objects - a single lookup keyed by a stable UUID-style identifier, a filterable list, a random sampler and a full-text search. The fifth returns aggregates instead of rows: totals and breakdowns by state, country and brewery type, the cheapest way to detect drift between syncs without pulling a single venue.

Scale check on the shape itself: a complete establishment object runs roughly 400 bytes, which is why this corpus pipelines so cheaply - the entire 11,822-venue universe is a few megabytes of JSON, small enough to hold in memory and awkward to excuse not joining against sales, review or production data. Within Datadory's Brewers catalog it scores 9 out of 10, a band shared by 534 of the 1,744 datasets we catalog. Get a sample of this dataset cut to your countries and types, or read the rows below first.

One Antwerp establishment, exactly as captured during the August 2026 research pass - and notably, this is the example the documentation itself publishes as its conformance specimen:

id            : 474ff690-0e75-4a02-bbdd-eb64efb17c88
name          : Pakhuis
brewery_type  : micro
address_1     : 76 Vlaamsekaai
city          : Antwerpen
state_province: Vlaanderen
postal_code   : 2000
country       : Belgium
longitude     : 4.387955
latitude      : 51.2073246
phone         : +32 3 315 90 95
website_url   :

Read what the row proves about the schema's discipline. A non-US venue arrives with the same fourteen-column spine as a Colorado taproom - no country-specific forks, no localized field names. Coordinates land at six decimal places, precise enough to resolve the building on the Vlaamsekaai rather than the block. And brewery_type: micro is doing quiet work: it separates a neighborhood tank room from a regional producer before any analysis starts, which is why the field anchors nearly every interesting cut of this corpus.

Fourteen current fields define every response, and they divide cleanly into identity, geography and contact. The identity pair - id and name - gives every venue a stable join key plus a human-readable label. The geographic block - city, state or province, postal code, country and the three-line address ladder - carries the rollup grain, which is why country and postal-code cuts never need imputation. The contact block - phone and website_url - populates unevenly and says so honestly, arriving typed as nullable rather than pretending completeness.

The one field to handle deliberately is brewery_type: a closed ten-value enum (micro, nano, regional, brewpub, large, planning, bar, contract, proprietor, closed) that separates business models rather than describing beer. Two of those values are flagged deprecated inside the specification itself, and the project's own population statistics quantify the soft spots elsewhere - the second address line sits around 3 percent filled and the third effectively at zero, facts worth knowing before a mailing or geocoding run, not after.

Definitions below were verified end to end during the August 2026 research pass; every example traces to the published specimen record above.

The fourteen-column spine ships by default; the layers below fold into additional fields on request because they depend on the shape of the delivery:

1. The deprecated compatibility pair. Legacy state and street fields survive in the specification purely so older consumers keep working - carrying both spellings of geography in one table invites silent join mismatches, so they ride along only when named.
2. Aggregate-count snapshots. The summary operation's totals and per-state, per-country and per-type breakdowns, captured as dated columns beside the establishment rows so drift between pulls becomes a queryable series instead of a re-run.
3. Nullability and completeness metadata. The project's own per-field population figures joined onto the dictionary, so downstream users inherit coverage expectations with the columns rather than discovering them in production.
4. Crosswalk joins. Establishment rows keyed onto the bulk distributions elsewhere in the catalog, putting the interface's live shape and reproducible snapshots in one table.

Name the ones your models need when you request the sample; column naming locks against live records at that point.

• Geography: worldwide, 23-plus countries and 213-plus states or regions, with depth following craft-brewing concentration: about 8,224 records in the United States, roughly 1,445 in Germany, around 514 in Australia, then Belgium (~478) and Canada (~283) leading a long tail reaching from Singapore to Scandinavia.
• Temporal: a current-state mirror of a continuously edited community corpus. You get one present-tense object per establishment - no archive of prior states, no versioned releases - and the specification itself states no update cadence, so treat stored extracts as perishable and re-pull rather than assume.
• Granularity: one flat object per physical establishment, fourteen current fields per object, list results paginated at up to 200 records per page. Nothing aggregates above the venue except the count summaries - no city totals, no brand rollups - which keeps a 'how many breweries in Denver' question answerable with a filter instead of a deduplication debate.

API, files, or your warehouse. Daily, weekly, or hourly.

Name the countries, brewery types and fields when you request the sample and it lands shaped to that scope with the fourteen-field dictionary unchanged - enums kept as enums, coordinates kept typed, nulls preserved rather than silently coerced. Most teams take the full 11,822-row table once and keep a refresh rotating at whatever cadence matches their operations cycle; because the underlying corpus is continuously community-edited, a scheduled warehouse load keeps dashboards current without anyone babysitting the pipeline. The sample ships first either way.

• Territory and account lists - a filterable register of every brewery, cidery and brewpub is a ready-made ICP list; distributors and suppliers segment by type, city and country before the first call, and the fuller workflow lives on our lead enrichment page.

• App backends and finders - lookup, list, random and search cover the four verbs a brewery finder needs; a weekend build becomes a shippable product because the response shape never varies by route.

• Market sizing - venue counts by type and country anchor top-down models for equipment, supplies and service markets; see market sizing for the method alongside volume ledgers.

• Competitive footprint monitoring - the count summaries expose openings, closures and type migrations between pulls, catching a competitor's expansion pattern before trade press writes it up.

• Citation-grade sourcing - a named, community-maintained register gives journalists and academics a citable answer to 'how many breweries' questions traceable to individual venues; see citation-grade research.

Developers and data-product builders get a fully specified interface whose every route returns the same shape - the difference between an afternoon integration and a week of payload archaeology; see developers builders brewers use cases. Sales and growth teams get a ready ICP list with business-model segmentation already encoded in the type field - see sales growth teams brewers use cases. Market researchers and consultants get venue-level counts that turn 'the craft market' into a number with a methodology - see market researchers brewers use cases. Journalists, academics and students get a citable establishment register where every claim traces to a named venue - see journalists academics brewers use cases. Data scientists and ML engineers get tidy typed JSON that pivots into features without a scraping layer - see data scientists brewers use cases.

Scope note - this record is the interface-specification face of Open Brewery DB; the same 11,822-establishment universe surfaces as a packaged bulk distribution elsewhere in the catalog, and both describe one schema. Pick by consumption pattern, not by content.

Verification note - field definitions carry a verified flag from the August 2026 research pass, and the same pass logged two open questions worth keeping in a runbook: the specification publishes neither a stated update cadence nor quota figures, so monitor drift with the count summaries rather than assuming either. The brewery establishment record glossary entry explains the grain underneath.

Where to go next:

• Same universe, bulk face: Open Brewery DB - Free Brewery API & Bulk Datasets.
• Same universe, pinned files: Open Brewery DB - GitHub Repository (Bulk CSV/JSON/SQL) - per-country directories plus 51 US state files.
• American volumes beside it: TTB Statistics Portal (Beer, Wine & Spirits Reports) - monthly US production and removals.
• UK counterpart: UK HMRC Alcohol Bulletin - quarterly production and duty clearances.
• Trade-association lens: Brewers Association Insights & Statistics Hub - economist-authored craft analyses.
• Drinker opinion to join on venue: Hugging Face Datasets - Beer Search.
• The full ranked field: best brewers datasets, scored on Datadory's 0-10 rubric, with everything above collected in the brewers data hub.