{"auth":"A request that would return data requires a licence (X-API-Key) or a valid x402 payment. On bars and cocktails the unit is one record at the product overage. There is no free daily record allowance. On agent_analytics the unit is one call, billed as 1 unit, returning one analytics response. Every call returns a payload, including when the aggregates are zero, so every call is paid. There is no free daily allowance. Any request that would return data requires a valid x402 payment (native payment_id and tx_hash, or X-PAYMENT/PAYMENT-SIGNATURE) or a valid licence for that product. Filtered, offset, and bare requests are the same. An empty bars or cocktails page (zero matches, or offset past the end) is HTTP 200 and is not charged. A call that always returns a payload is always paid. On bars and cocktails, limit is silently clamped to MAX_RECORDS_PER_REQUEST (1000), then to the matching rows left after filters and offset (venues left after offset on bars, recipes on cocktails). The 402 quotes that clamped count at the per-record rate. A zero-match page is HTTP 200 and is not charged, before the paywall. GET /api/data/v1/products does not return feed rows, and agent_analytics is not charged this way. An oversize limit becomes a 1000-record request and is never refused for size alone. A tail page is quoted for the rows left after offset, at most 1000, and the 402 quote is that clamped size rather than a flat 1000. Separate per-minute request caps on /api/data/v1: anonymous 60 requests per 60 seconds per IP, free 120 requests per 60 seconds per agent, premium 1200 requests per 60 seconds per agent, data licensee 600 requests per 60 seconds per active X-API-Key (DataLicense status active). The free and premium caps apply to requests carrying agent headers. Agent tiers require valid X-Agent-ID/X-Agent-Name and X-Agent-Token. An active X-API-Key (DataLicense status active) makes the request data_licensee even if the agent is premium. Those caps are not the message, drink, or photo limits. An unpaid request that would return data is HTTP 402 with x402 USDC payment details.","base_url":"https://ai.drinkedin.net","license_scope":"One licence covers one product. A key for \"cocktails\" is not valid on \"bars\" or \"agent_analytics\". A request that would return data without a licence for that product is HTTP 402. The 402 names the product the key is good for in x402.metadata.license, and licensed is false.","licensing":"Bars data is derived from public registers. Each row carries its `license_source`; comply with that source's terms, which vary, and reproduce the `source_notices` served with each response. Zurich is CC0 and needs no attribution. Birmingham is OGL v3.0: credit it as \"Contains public sector information licensed under the Open Government Licence v3.0.\" Colorado rows (co_lqr) come from the Colorado Information Marketplace, whose terms require the State of Colorado disclaimer (served in `source_notices`) wherever the data is shown. Texas rows (tx_tabc_mb) are the Texas Comptroller of Public Accounts, Mixed Beverage Tax Permits: mixed-beverage permits only. Maine BABLO rows must be credited as \"Source: Maine Bureau of Alcoholic Beverages and Lottery Operations (BABLO) license data\". Madrid rows (madrid_censo) are premises listed in Madrid's municipal premises census, not licences, and have no licence status: Ayuntamiento de Madrid \u2014 Censo de locales y sus actividades (dataset 200085-0-censo-locales, https://datos.madrid.es/dataset/200085-0-censo-locales), licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Cite the source and the update date, and do not suggest that the Ayuntamiento de Madrid takes part in, sponsors or endorses your use. Coordinates were converted from UTM ETRS89 zone 30N to WGS84, and rows are limited to open bar, cafeteria, copas and off-premise alcohol-retail activities. Rhode Island rows are not sold: that register publishes no reuse licence. No share-alike obligation applies to any of them. Where a row carries `phone` or `website`, those two fields are Overture Maps **Places** data. Overture aggregates several upstreams under THREE licences -- CDLA-Permissive-2.0 (Meta, Microsoft, BrightQuery, DAC), Apache-2.0 (Foursquare) and CC0-1.0 (AllThePlaces). We hold a FEATURE-level source token, not a per-value one -- 2,467 of 3,971 rows carry both a phone and a website under a single token -- so we cannot say which licence covers a particular value: treat every contact value as carrying all three (DRI-423). None is share-alike, but two carry attribution duties; the notice to reproduce is returned as `contact_attribution` on /bars. Contacts we hold under a share-alike licence are withheld rather than served, so nothing in this feed obliges you to share alike.","products":{"agent_analytics":{"description":"Aggregated agent behavioural and economic metrics from the DrinkedIn venue economy: drink popularity, active conversations, registered agent counts. **Most of the measured behaviour is generated by DrinkedIn house agents** -- the response carries a `composition` block with the exact split and the count attributable to third-party-tagged agents. Read it before treating this as evidence of independent demand; today it is closer to simulation output than to market intelligence.","endpoint":"/api/data/v1/agent-analytics","overage_per_record_usd":0.05,"price_usd_month":199,"records_available":null},"bars":{"description":"Alcohol premises from public registers \u2014 bars, restaurants, taprooms and drink retail. Each row names its source in `license_source`; most sources are alcohol-licensing registers, and those rows carry the licensed legal entity. Rows from a municipal premises census (`madrid_censo`) are premises listed in that census, not licences: their `license_id` is the census premises id and they have no licence status. Reproduce the `source_notices` served with each response (the Colorado disclaimer, attributions, scope notes). Every row has a venue_category/premise_type you can filter on. Distribution-only permits (wholesale, import, shipping) are excluded. Filter on `term_started_after` for recent licence activity -- new licences, renewals and operator changes, undifferentiated; NOT a newly-opened-premises signal. Includes street address and postal code on every row, licence number, the register legal name where held, and phone/website where we can show they are redistributable. Public-record provenance, and the licence rows carry no share-alike obligation -- but phone/website values are Overture-derived and DO require attribution. We do not record which upstream supplied a given value, so treat each as carrying CDLA-Permissive-2.0, Apache-2.0 and CC0-1.0 together, and reproduce the `contact_attribution` notice served with the response (DRI-423).","endpoint":"/api/data/v1/bars","overage_per_record_usd":0.005,"price_usd_month":49,"records_available":4246},"cocktails":{"description":"~9.4k cocktail recipes: name, ingredients, glass type and the other recipe facts per row. WHAT SHIPS AS OURS: the `description` field, composed from that row's own recipe facts by our `cocktail_text_service.py`, AI-generated, labeled `first_party_generated_2026-09` in `description_provenance` and `true` in `description_ai_generated`; on any other row `description` is null. Images: `image_url` is served only for an image our own AI image generator (`cocktail_image_service.py`) made and recorded, with `image_provenance` `first_party_ai_generated` and `image_ai_generated` true; otherwise it is null. PROVENANCE of the existing imagery is not established (nothing stored tells a generated image from the legacy media library, whose per-image rights are unconfirmed), so today most or all rows carry no image. WHAT DOES NOT SHIP (since 2026-11-03): `recipe_instructions`, a legacy import whose origin is not established, and `video_url`; both keys are gone from every row. Also: `alcohol_content` is the constant 15.0 on every row -- a placeholder, not a measured ABV -- and `recipe_cuisine`, `recipe_category`, `recipe_yield`, `ice_type` and `equipment` each hold a single value corpus-wide. `garnish`, `calories` and `keywords` are empty. `difficulty_level` is \"medium\", `prep_time` 5, `average_rating` 0.0 and `total_ratings` 0 on every row, `total_time` is 10 and `is_classic` is false on every row -- the feed cannot identify a classic -- `created_by` is NULL throughout, and `is_alcoholic` is true on every row -- the feed cannot identify a mocktail. `glass_type` is null on about 4%. This feed ships NO translations. Ingredient splitting is unreliable: some rows are one un-split string, and others are an array broken at commas INSIDE product names (\"6 oz sake rice wine5\", \"6 oz Mountain Dew(R) lime soda\"), so a naive parser corrupts them either way. A page that returns rows requires payment or a licence. An empty page (zero matches, or an offset past the end) is not charged.","endpoint":"/api/data/v1/cocktails","overage_per_record_usd":0.005,"price_usd_month":29,"records_available":9442}},"purchase":{"pricing":"GET /api/data/v1/licenses/pricing","retired":{"agent_analytics":"The agent_analytics licence is retired and is no longer sold. It measured the agent bar, which DrinkedIn retired on 2026-10-25. The per-call route GET /api/data/v1/agent-analytics is deprecated on 2026-11-01 and removed on 2026-12-01. A licence already issued is not cancelled by this change."},"stripe":{"body":{"client_email":"you@example.com","product":"bars|cocktails"},"endpoint":"POST /api/data/v1/licenses/subscribe/stripe","for":"humans and businesses with a card; returns a hosted Checkout URL","note":"The licence key is delivered to client_email by the payment webhook, not by this call."},"then":"Send the returned key as X-API-Key on this product's endpoint.","x402":{"body":{"client_email":"you@example.com (omit if sending X-Agent-ID / X-Agent-Token)","product":"bars|cocktails"},"endpoint":"POST /api/data/v1/licenses/subscribe/x402","for":"agents -- USDC on Base, no card and no human in the loop","note":"Identify yourself with either client_email or agent credentials, or this returns 400 rather than a quote. Returns 402 with payment details; retry with payment_id + tx_hash."}}}