Backing up District

We backed up District’s public catalog: 35,833 listings across 1,328 Indian cities. The result is a searchable archive and an open TypeScript SDK.

District is the layer Zomato built for leaving the house. Open the app and it tells you what is playing, where to eat, which comedian is in town, and where you can spend a Saturday afternoon. It is a useful map of what a city can do right now.

The problem is that “right now” disappears. An event ends, a venue closes, a movie leaves theatres, and the record quietly falls out of the product. The app is designed for the next booking, not for memory.

I started with a smaller goal: build the API that District never published. I wanted a typed client instead of another folder of copied network requests. Once search, events, movies, dining, and locations worked, the obvious question became: what is actually in here?

That question turned a client library into a nationwide catalog. What follows is the honest version of that work: what we preserved, what the collection says about District, how to use it, and where the archive stops.

Before diving into the details, here is a quick overview:

• 24,513 restaurants, 5,089 events, 837 movies, 3,154 cinemas, 1,783 play venues, and 457 stores.
• The collection spans 1,328 cities. Big metros are dense; the long tail is much thinner.
• The website is a public reading and search layer. The underlying catalog is kept in a queryable SQLite-compatible database.
• district-kit exposes the live guest surface as a typed TypeScript SDK and CLI.
• This is a metadata archive. It does not contain tickets, purchases, private accounts, payment data, or copyrighted media.

— Vandit · vaandeetttt.com

Data exploration

Let’s look at the shape of the collection. These are live counts from the public archive:

Restaurants are the map

Dining is not just the largest category; it is the geographic spine of the archive. Events pass through a city. Restaurants stay put. They reveal where District has meaningful coverage and where it only knows the outline of a place.

The headline number—1,328 cities—needs that context. A city appearing in a location index does not mean it has the depth of Bengaluru, Mumbai, or Delhi. Coverage is a long tail, not a flat map.

Events are perishable

Events are the part most worth preserving and the hardest to keep. Restaurant and cinema identities are relatively stable. An event is born with a date attached and starts disappearing almost immediately. A catalog of 5,089 events is therefore less like a directory and more like a frame from a film.

Over time, those frames become the interesting part: which artists toured where, what kinds of experiences appeared, and how the center of gravity moved between cities.

Movies are shared; cinemas are local

A movie is one object shown in many places. A cinema is a physical venue tied to a city. That is why the archive can contain 837 movies but 3,154 cinemas. The useful graph lives in the relationship between content, venue, city, and time—not in any one table.

The collection

Metadata

The archive keeps the public identity needed to recognize and query an entity: names, stable identifiers where available, city, category, slugs, and selected public attributes such as rating or price.

It is deliberately not a byte-for-byte mirror of the app. Product responses carry presentation details, experiments, and temporary UI state. The public dataset keeps the useful shape while leaving that noise behind.

The website

The simplest way to inspect the data is the search box above, or the full catalog browser. The exploration page shows aggregate cuts, and status shows freshness.

The SDK

For live reads, there is district-kit, a hand-written TypeScript client with typed resources for search, discovery, events, movies, dining, locations, and more.

npm install district-kit

import { DistrictClient } from "district-kit";

const district = new DistrictClient({ city: "bangalore" });
const results = await district.search("comedy");

The SDK came first. The archive is what happened when the client became reliable enough to ask larger questions.

The honest limits

This is not a complete copy of District.

• Coverage is uneven. Dining has breadth; deep detail varies by vertical and city.
• Prices, availability, and showtimes are live facts. A snapshot can only say what was visible when it was observed.
• New listings appear and old ones disappear. Historical coverage begins with this project, not with District’s launch.
• The archive excludes tickets, purchases, private accounts, payment data, and copyrighted media.

It is also not a checkout bot or an operational guide to District’s infrastructure. The public work is the catalog, SDK, and the protocol knowledge required to use them responsibly. Credentials, raw research notebooks, and sensitive implementation details stay private.

Why make it public?

Without a public reference, every developer starts from zero: rediscovering the same interfaces, building the same parsers, and keeping private notes that never help the next person. Publishing a clean SDK turns that repeated work into a foundation.

Publishing the catalog does something different. It preserves the context around those interfaces: the actual places, films, events, and activities they described.

Any single listing is ordinary. At nationwide scale, the collection starts to look like cultural metadata: where people ate, what they watched, which performers toured, and what kinds of places existed at a particular moment. Things that feel permanently available often are not. If the record is worth keeping, the time to start is while it still exists.

This is the first public version of the District archive. The numbers in this essay are read from the live catalog. Explore the data, use the SDK, or follow the project on GitHub.