We built an API for events, places, and local news in Barcelona and Madrid

Building a local API for events, places, and news in Barcelona and Madrid GitHub

Most city products run into the same problem sooner or later.

You want to answer simple questions like:

• What is happening today?
• What is near these coordinates?
• Which places belong to this category?
• Which local news is still actually relevant?

But once you start building, local data is rarely clean enough. Events, places, and news often live in separate systems, use different filters, and do not map well to the way people actually explore a city.

That is one of the reasons we started opening up the data layer behind DondeGo.

DondeGo is a local media and city guide focused on Barcelona and Madrid. The editorial side is built around practical discovery: things to do, places to know, and local news that matters in city life. Recently, we have been turning more of that into an API that can be reused in real products.

What the API is trying to solve

The goal is not to build a huge generic directory.

The goal is to make local urban content easier to work with for developers, editorial teams, maps, newsletters, recommendation tools, and city-focused products.

Right now the API is centered around three main object types:

• events
• places
• news

That makes it possible to support workflows like:

• showing events happening today in Madrid
• finding places within a radius from a point on the map
• filtering objects by tags or categories
• returning only current news items
• building city guides or local recommendation layers

Recent changes in v0.1.0

We have just published v0.1.0, partly because I wanted the project to have a visible public milestone and partly because the API has become much more usable recently.

A few of the changes included in this version:

• daily events now also include films
• daily events can now return a title override
• event and place categories now expose identifiers
• filtering by tag slugs is supported via tags
• news now supports an actual_only filter for current items
• event date serialization now includes:
  • start_date
  • start_time
  • end_date
  • end_time
  • is_continuous
  • is_endless
  • is_startless
  • schedules
• image serialization now includes authorship
• it is now possible to fetch only films with free screenings
• it is now possible to fetch only places with free events
• is_free is now interpreted more strictly
• categories for events and places can now be disabled in collection responses

None of this is especially flashy, but it moves the API closer to being something that is genuinely usable in production.

The kind of queries we care about

The API is most useful when it reflects how people actually navigate a city.

For example, a basic daily query:

GET /api/v1/events/?location=madrid&date=hoy

A proximity-based query:

GET /api/v1/events/?lat=40.4168&lon=-3.7038&radius=3000&date=hoy

And place discovery around a point:

GET /api/v1/places/?lat=41.3874&lon=2.1686&radius=2000

That may sound simple, but in practice this is the layer many local products need most.

Not “all possible city data”, but structured answers to questions like:

• what can I do today?
• what is nearby?
• what is free?
• what is still current?
• what belongs to this area or category?

Why I find local APIs interesting

There are many great APIs in the world, but local discovery still feels oddly underserved.

A lot of the difficulty is not in storing records. It is in making the data useful in the context of a real city. Dates matter. Geography matters. Editorial freshness matters. Category structure matters. Free vs paid matters. Sometimes a simple “today” filter matters more than a complex taxonomy.

That is why I think local APIs are interesting. They sit somewhere between media, maps, structured data, and product design.

If you are building in this space

We are opening access gradually, but if you are working on a project around Barcelona or Madrid and need local events, places, or news, that is what we are building toward.

The public project is here, a bit more context lives there: DondeGo

I would also be curious how other people here would design this kind of API.

Would you prioritize geospatial search first, editorial freshness first, or category and tag structure first?