Skip to main content
Build

Build on the data that runs Akashic Edge.

Ask a question. Explore the map. Analyze a place. Build on the data. Every chart, map, and dossier on the site is powered by the same API you’ll use. Same data, same schema, same 165 years — shipped to your stack in one line of code.

API shape
13 endpoints
Election results, history, comparison, demographics, clusters, and Historian access.
Coverage
165 years
The same election layer behind Akashic Edge product routes and place dossiers.
Delivery
UI + API
Developer dashboard, docs, embeds, and product workflows on the same stack.
What you get

A REST API built for real workloads — not a weekend demo.

Versioned endpoints, an OpenAPI spec you can generate clients from, and predictable pagination.

Every response is the same data we use to render the product. If it’s on akashicedge.com, you can pull it.

What teams build with it

Production-grade election data, shipped to your stack.

Newsrooms, campaigns, researchers, civic tech — here's what the API powers in the wild.

Newsrooms and publishers

Power explainers, election desk utilities, embed rollouts, and shareable county or state context without hand-building every chart.

Researchers and analysts

Move from a place question to reproducible queries, structured exports, and provenance-aware data access without rebuilding the base dataset.

Product and platform teams

Use one source of truth for applications, internal tooling, and public-facing data products instead of stitching together partial vendors.

Capabilities

What the API actually does

Not a wishlist. Every endpoint below is live and documented.
Versioned REST API with a consistent envelope and OpenAPI 3.1 documentation.
Developer dashboard for keys, usage, embeds, billing, and rollout support.
Embeddable widgets that share the same election intelligence layer as the main product.
Natural-language Historian access for higher-tier workflows that need NL-to-SQL alongside standard endpoints.
Example response

One clean schema, everywhere

Same envelope on every endpoint. Predictable, parseable, no surprises.
{
 "data": [
 { "fips": "55025", "county": "Dane County", "margin": 39.51 },
 { "fips": "55079", "county": "Milwaukee County", "margin": 30.36 },
 { "fips": "55133", "county": "Waukesha County", "margin": -18.55 }
 ],
 "meta": { "queryTimeMs": 18, "rowCount": 72, "apiVersion": "v1" },
 "rateLimit": { "limit": 60, "remaining": 59 }
}
A taste

A few endpoints to get the feel

The full catalog lives in the docs. These show the shape and what's on offer.
MethodRouteWhat it is for
GET/api/v1/electionsList election years and office availability.
GET/api/v1/elections/2024/presidentReturn structured election results by office and cycle.
GET/api/v1/elections/timeseriesFetch time-series margin history for a place or comparison set.
GET/api/v1/counties/17031Return county profile, demographics, and election context.
GET/api/v1/compareCompare places or elections on one shared schema.
POST/api/v1/historian/queryAccess the Historian programmatically on eligible tiers.
Access paths

Separate evaluation, production use, and institutional rollout.

The buying structure should match the real shape of the work instead of forcing every visitor through one generic CTA.
Docs first

Evaluate

Read the docs, inspect the schema, and review the developer dashboard flow before you commit.

Inspect docs and OpenAPI
Review embeds and auth flow
Validate route fit for your workflow
Production API

Edge Insider

Use the paid individual build tier when you need repeatable developer access, Historian API workflows, and clean embeds.

Production API access
Developer dashboard and key management
Best fit for solo builders and advanced researchers
Teams

Institutional rollout

Use the institutional path when the actual buyer is a newsroom, classroom, lab, or organization.

Rollout planning and procurement support
White-label embed path
One coordinated relationship for shared access