Turkey sits on one of the most seismically active regions in the world, and it maintains dense national monitoring networks as a result. For developers, that means something unusual: high-quality, keyless, publicly accessible earthquake data.
The catch is that most of the documentation, field names and response text are in Turkish, and the two main sources disagree with each other in ways that look like bugs until you understand why. This guide covers what each source gives you, how to read the fields, and the traps that will silently corrupt your data if you miss them.
Quick comparison
| Source | Best for | Auth | Format | Coverage |
|---|---|---|---|---|
| AFAD | Official, filterable event data | None | JSON, GeoJSON, XML, CSV, KML | Turkey and surrounding region |
| Kandilli (KOERI) | The list Turkish users recognise | None | Plain text / HTML | Turkey and surrounding region |
| USGS | Global cross-reference | None | GeoJSON, QuakeML | Global, higher local threshold |
| Community wrappers | Fast prototyping | None | JSON | Derived from the above |
Why local networks matter
The instinct for a developer outside Turkey is to reach for USGS. It is well documented, returns clean GeoJSON, and covers the entire planet. For Turkish earthquakes, that instinct is only half right.
USGS operates a global catalog. Its detection threshold in any given country depends on how well that region is instrumented within its network. In Turkey, the national networks operate far more stations than contribute to the global picture, so they detect and publish events that never appear in the global catalog at all.
Practically: for a magnitude 5.5 event, all three sources will have it within minutes. For a magnitude 2.3 event near Bodrum, only the local networks will. If your app shows "recent earthquakes in Turkey" and you use USGS alone, users will see an empty list on days when the local sources show dozens of events — and they will conclude your app is broken.
The reverse is also true. If you cover multiple countries, the local Turkish sources will not help you outside their region, and you will need USGS as the global layer.
AFAD — the official source
AFAD is Turkey's Disaster and Emergency Management Authority. It publishes earthquake event data with filtering, and it is the source to prefer when you need something you can attribute to an official body.
Two things make it good to build on. First, the output formats: alongside JSON it offers GeoJSON, which matters more than it sounds. If you are drawing a map, GeoJSON drops straight into a map layer without you parsing coordinates out of text and reassembling them. Fewer transformations means fewer chances to silently swap latitude and longitude — a mistake that puts Turkish earthquakes in Somalia and is surprisingly easy to make.
Second, the filtering. You can constrain by time range, magnitude, depth and geographic bounds. This turns "show me everything above magnitude 4 in the last week within this bounding box" into a single request instead of a fetch-everything-then-filter-locally pipeline.
The response is oriented around Turkish conventions. Location descriptions are Turkish place names, often in the form of a district and province, sometimes with a body of water. If your interface is English, decide early whether you translate these or present them as-is. Presenting them as-is is usually the right call: these are proper nouns, and a user searching for the event will find the Turkish name in news coverage.
Kandilli (KOERI) — familiar but fragile
Kandilli Observatory and Earthquake Research Institute, part of Boğaziçi University, is the source most Turkish users grew up checking. Its "latest earthquakes" list is culturally the reference point, which matters if your users are Turkish and expect your numbers to match what they see elsewhere.
Technically, it is the harder of the two to consume. The list is published as plain text laid out in fixed columns, not as a structured API. You parse it by position and separators.
This has a specific failure mode worth designing against. When a text layout changes — an extra column, a wider field, a different header — a positional parser does not crash. It happily reads the wrong substring and produces plausible-looking garbage. A depth value lands in the magnitude field and your app reports a magnitude 12 earthquake.
Guard against this with validation rather than trust. After parsing, assert that the magnitude falls in a sane range, that latitude and longitude are within the region you expect, that the timestamp is recent and not in the future. Reject rows that fail and log them. A parser that returns fewer rows is recoverable; one that returns wrong rows is not.
Community wrappers
Several community projects consume the official sources and re-publish them as clean JSON. The community earthquake API in our catalog is one of them.
The appeal is obvious: someone else has already written and maintains the fragile parsing layer. For a prototype, a hackathon or a hobby project, this is a reasonable trade.
For production, weigh it carefully. You are adding a dependency that is maintained voluntarily, has no service commitment, and sits between you and the authoritative source. If it goes down or falls behind, your users see stale data and you have no recourse. If you do use one, design so that switching to the official source directly is a small change rather than a rewrite.
Reading the fields
The single biggest barrier for non-Turkish-speaking developers is that response fields and values carry Turkish names and conventions. A short orientation covers most of it.
Büyüklük / magnitude. May be reported on different scales. Local magnitude (ML) is common for smaller regional events; moment magnitude (Mw) is used for larger ones. They are not interchangeable, and a source may switch scale depending on event size. If you compare values across sources, compare like with like.
Derinlik / depth. Reported in kilometres. Shallow earthquakes cause more surface shaking than deep ones of the same magnitude, so if your interface communicates severity at all, depth belongs next to magnitude rather than hidden in a details panel.
Yer / location. A Turkish place description, typically district and province, sometimes a sea area. Treat it as display text, not as a parseable address.
Enlem / boylam. Latitude and longitude, in decimal degrees. Note the ordering convention in whatever format you consume — GeoJSON uses longitude first, which is the opposite of how most people say it.
Tarih / zaman. Date and time. This is where the most damaging mistake lives, so it gets its own section.
The timezone trap
Turkey observes UTC+3 year-round and does not change clocks seasonally. That last part removes one class of bug and introduces another.
The removed bug: you do not need to handle daylight saving transitions for Turkish local time. The introduced bug: libraries and developers who assume every timezone has DST sometimes apply an offset that does not exist.
The real problem, though, is simpler and far more common. Local sources may publish times in Turkish local time, while USGS publishes in UTC. If you merge feeds without normalising, you get the same earthquake appearing twice, three hours apart, looking like two separate events.
The rule that avoids all of this: normalise everything to UTC at the moment you ingest it, store UTC, and convert to a display timezone only at render time. Never store a timestamp without knowing what zone it was in. If a source gives you a local time with no offset, attach the offset explicitly during parsing rather than letting your runtime guess from the server's own timezone — because your development machine and your production server will guess differently, and the bug will only appear after deploy.
Deduplication and revision
Earthquake data is not immutable, and treating it as immutable will make your app look unreliable.
An event is first published from an automatic solution, often within a minute or two. As more stations report and analysts review, the magnitude, depth and coordinates get revised. A quake published as magnitude 4.8 may settle at 4.5. This is normal seismology, not a data error.
Two consequences for your code. First, use the event identifier as your primary key and upsert rather than insert, so revisions update the existing record instead of creating duplicates. Second, if you send notifications, make them idempotent on that identifier — otherwise every revision fires a fresh alert and your users get four notifications for one earthquake.
Merging multiple sources adds a harder problem: the same physical event has different identifiers in each catalog. There is no shared key. The workable approach is fuzzy matching on time, location and magnitude — events within roughly a minute of each other, within a small radius, with similar magnitude, are probably the same event. Keep both records with their sources attached rather than merging them into one, and let the interface decide which to show. Destroying the distinction makes disagreements between sources impossible to explain later.
Beyond earthquakes
If you are building a broader disaster or hazard interface, earthquakes are one layer among several.
For wildfires, satellite-derived active fire and natural event data is available through NASA's open API family. It is observation-based and therefore delayed by satellite pass timing — useful for visualising what is happening, not for first alerts.
For air quality during and after fires, Open-Meteo's air quality endpoint covers Turkey without a key, and OpenAQ aggregates station measurements where they are available.
For weather conditions that affect hazard interpretation, free weather APIs covers the options including Turkey's national meteorological service.
Responsible use
This section is not boilerplate. Earthquake data is the one category in this catalog where a careless interface can cause real harm.
None of these sources is an early-warning system. They are catalogs of events that have already happened and been processed. An interface that implies otherwise — words like "alert", "warning" or "alarm" used prominently, a design that mimics official emergency notifications — can lead a user to believe they will be told before shaking starts. They will not.
Say plainly, in the interface and not only in a terms page, that the data is informational, name the source, and show when it was last updated. If you send push notifications, let users set a minimum magnitude and a region, and respect quiet hours. Notifying everyone about every magnitude 2 event trains users to ignore your notifications, which is worse than not sending them at all.
Attribution is also a licensing matter, not only a courtesy. Both AFAD and Kandilli expect their data to be credited. Show the source next to the data.
Access details and formats in this article reflect the official sources at the time of publication. Because Kandilli's output in particular is a text layout rather than a versioned API, verify current behaviour with your own tests before relying on it in production.
Related API Deposu entries
Sources
Frequently Asked Questions
›Is there an official Turkish earthquake API?
AFAD, the national disaster and emergency management authority, publishes filterable event data in structured formats and is the official source. Kandilli Observatory (KOERI) publishes its own list, but as plain text rather than a documented developer API.
›Do I need an API key for Turkish earthquake data?
No. Neither AFAD's event data nor Kandilli's list requires registration or a key. This makes them unusually easy to prototype against compared to most government data sources.
›Why do AFAD and Kandilli report different magnitudes for the same earthquake?
They operate separate seismic networks with different stations and use different magnitude scales and processing pipelines. Early automatic solutions are also revised as more station data arrives, so a value you fetched minutes after an event may be updated later.
›Should I use USGS instead for earthquakes in Turkey?
USGS covers Turkey but its global catalog has a higher detection threshold there than the local networks. For events above roughly magnitude 4.5 it is a solid cross-reference; for small local events it will miss what AFAD and Kandilli record.
›Can I build an earthquake alerting app on these APIs?
You can build an informational app, but not an official warning system. These are polled event catalogs published after detection and processing, not early-warning feeds. Your interface must make clear that it does not replace official emergency communication.