Skip to main content
Four steps from no account to real rows. The first three are free.
1

Sign up

Create an account with Google or an email address. Email signups get a confirmation link; it signs you in and brings you back here to step two. No payment method is needed for a Free account.
2

Create a key

Open API keys, click Create New Key, name it and copy it. Keys look like gdelt_sk_… and are shown once. A key belongs to the workspace it was created in, so check the workspace switcher first if you belong to a team.
That is the whole authentication story: a bearer token on every request.
3

Make your first calls

Your Free account includes 200 starter calls for the REST API and the MCP server. They are a one-time credit and never expire. Run the hello-world call below.
4

Choose Builder when you need more

Choose Builder for every data endpoint, a monthly Query Unit allowance and three daily Monitors. Checkout shows the price and billing date before you confirm, and the owner can cancel in Subscription. Compare every plan on Pricing.
What Free includes. 50 QU a month in the web app and API Arena, plus the 200 starter calls for the REST API and MCP server. Once those are used, API keys, OAuth, the MCP server and scheduled Monitors need a paid plan, and a call answers 403 PROGRAMMATIC_ACCESS_DENIED with a details.pricing_url to choose one (errors). Ordinary data reads cost 1 QU each; see Pricing for each plan’s allowance.
When adding filters, pick values from the value reference and Event taxonomy. Use explicit dates for repeatable queries; the effective request window is in meta.query_window, and available history is in meta.coverage. When part of a valid Event or Story date range has not published, the API returns the safely published rows with coverage.served_dates, lists withheld partitions and reasons in coverage.missing_dates, and sets coverage.window_complete to false. It returns a retryable snapshot error only when no requested partition can safely answer.

Hello, world

No filters. The most significant event in the endpoint’s default window. The Python sample needs pip install requests; the TypeScript sample needs Node 18+ as an ES module (top-level await).
A real response, trimmed to the fields worth meeting first:
That is the whole product in one row. An event is a coded claim — a date, a place, actors, a taxonomy code and metrics — and story_refs points at the clustered coverage it was read from. The 162 articles behind it are one event, not 162.
Every response on this page was returned on 2026-08-26 and is reproduced as returned, trimmed to the fields under discussion. A live row carries more — metric sub-factors with their stated reasons, entity references, a language breakdown and the top source articles — and the values move with the news.

Then, in the workspace

In the signed-in workspace, investigate a company, follow a country or retrieve coded Events. Use this data shows the actual request and response; copy its code or open the supported scope in the API Arena. Confirm a company’s identity before following its reporting. Profile overview panels retain their labelled recent windows; the Events and Stories links carry your chosen reporting dates. Semantic search retrieves a bounded similarity candidate pool. Changing page size can change that pool, and deep pagination is not an exhaustive, stable export of every matching record. For extraction jobs, use structured filters and the documented dataset download scope. Inspect the source articles: a Story may match a country through a linked Event while its representative geography describes another location. Monitor this carries compatible filters into a draft. Preview shows 7 or 30 days of evidence; scheduled matching follows newly committed records since the previous successful checkpoint. The original discovery dates remain in the saved request for context. It does not save a Monitor or enable deliveries automatically. If a source needs additional access, its plan link retains your results and shows current catalog options. Return to the same work after reviewing access. The Data & coverage page is the source inventory; it distinguishes measured holdings from planned coverage and available API access from published bulk files.

The same shape, for narratives

/events answers what happened. /stories answers what is being said — the article clusters underneath.
443 articles, one story, one linked event. That collapse is why an article count and an event count answer different questions — the nouns are in Concepts.

Count before you list

This is the step that saves the most time. The summary endpoints return counts grouped by date, geography or category — the shape of a period — so you can see where the volume actually is before committing to a filter.
Seventeen buckets came back; the first six, with the noisiest fields dropped:
Read it before you filter. The first bucket holds 1,786 events and the fifth holds 72 — and the fifth is the one carrying the highest average significance of the six. Volume and importance are different questions, and a list query aimed at the biggest bucket would have walked past the answer.
A summary endpoint takes many of the same filters as its list sibling — days, date, entity, country_match, geo_precision_*, near and radius_km work here. It does not take search; that filter is refused with a 400. See the exact set in the endpoint index and inspect applied_filters on the response.
/stories/summary does the same for narrative clusters. Now filter the list endpoint down to the buckets that actually carried volume — and read applied_filters on both calls to confirm the two describe the same population.
Add filters one at a time. Stacking four on the first call is the most common way to get an empty result and conclude the data is missing, when it is really the AND of your filters. Check applied_filters in the response — it echoes exactly what the server used.

Prefer to work through an agent?

The data server answers questions about the world, and it is the one to connect first. It uses your API key or an OAuth sign-in, and its calls draw on the same starter calls and plan allowance as the REST API:
The plugin is the fastest path for coding agents: one install wires the data server, the docs server and the workflow skills. Your Connect page shows the same steps with your key filled in.
Optionally add the docs server too. It needs no account and returns documentation (every page, parameter and value list), so your assistant can write correct code:
Connecting only the docs server and then reporting “no events found” is the most common setup mistake. See the MCP overview and Integrations for both.
https://docs.gdeltcloud.com/mcp is a JSON-RPC endpoint, not a page — opening it in a browser returns 405, which is expected. The page describing the MCP surface is /mcp/overview.

Then pick your path

I'm building something

Resolve an identity, then use each dataset’s supported identifiers across news, tone, awards and assets.

I'm answering a question

Work in plain language through the MCP server, with citations.

Two things that will save you time

Event and story lists do not default to a week or all of history. Without an entity filter, omitting the window uses a rolling 24 hours. With an entity filter, it defaults to 30 calendar days. Other families carry their own defaults, declared in Parameters. Read meta.query_window for the effective bounds and pass days or explicit date_start/date_end whenever the window matters to your answer. Coverage does not run all the way back. A query reaching before the coded window returns a near-empty result that looks like a bug and is not. The window, and what it means for a query, is in Coverage; per-dataset windows are in the data catalog.