RidingDesk publishes two REST APIs that share the /api/v1/* URL space but are distinct products. The free Electoral Data API is open to anyone — the Canadian dataset of riding boundaries, postal-code lookups, and election results. The paid Customer Data API lets an active campaign read and write its own CRM data — voters, donations, canvassing, lawn signs.
Canadian boundaries, postal-code lookups, election results
Look up the federal, provincial, and municipal ridings for any Canadian postal code; browse boundary geometries as GeoJSON; list past elections and candidates. Free for all non-commercial use. Keys begin with ced_.
Read/write your campaign's CRM data
A scoped JSON API for the data inside an active RidingDesk campaign — voters, donations, volunteers, canvassing interactions, lawn signs, campaign metadata. Keys begin with rd_live_; STARTER tier or higher.
The official @ridingdesk/mcp-server npm package wraps every endpoint as a Model Context Protocol tool. Add to claude_desktop_config.json:
"ridingdesk": {
"command": "npx",
"args": ["-y", "@ridingdesk/mcp-server"],
"env": { "RIDINGDESK_API_KEY": "rd_live_..." }
}Both APIs live under https://ridingdesk.ca/api/v1/. The path segment after /v1/ tells you which product (electoral vs the customer resources).
ced_* only works against the electoral surface. rd_live_*only works against your campaign’s CRM resources. They aren’t interchangeable.
Both APIs are vanilla JSON over HTTPS. The Customer Data API ships an OpenAPI 3.1 spec you can feed into any codegen tool.