API vs. MCP: Which to Use

SDX has two integration surfaces. They are not alternatives in the marketing sense — they solve different problems and you may end up using both. This page is the decision tree for picking the right one for a given workflow.

TL;DR

REST API — for traditional server-to-server integrations: your code fetches data, your code writes data, your servers run on a schedule.
MCP server — for AI agents that need to call SDX as tool use: Claude, Cursor, your own agent, anywhere a model decides what to do next.

You're not picking a tier. Both are free. The choice is about how the calling code is structured.

Use the REST API when…

You have a backend service (Node, Python, Go, Ruby) that needs to read or write SDX data.
You're running scheduled jobs — nightly utility imports, weekly portfolio syncs, end-of-month reports.
Your call sites are deterministic: you know which endpoint, with which arguments, in what order.
You want webhooks, fine-grained pagination, OpenAPI tooling, and a sandbox environment.
You're integrating SDX into an existing software product (a sustainability platform, a property management system, an asset-management tool) and your code path is the same every run.

See: API quickstart, authentication, code examples.

Use MCP when…

You're building an AI agent — Claude Desktop, Cursor, a custom MCP-compatible runtime — that needs to query and modify SDX data based on what the user asks.
The model decides which calls to make. You don't enumerate them up front.
You want SDX exposed as tool calls inside a chat / agent loop, not as endpoints in your codebase.
You need scoped, OAuth-authorized access that the user grants to the agent — not your service account acting on their behalf.
You're prototyping something where the call pattern isn't stable yet and you don't want to write API client code that you'll throw away.

See: /mcp for connection instructions and the full tool list.

Use both when…

These overlap more than they compete. Common patterns where both make sense:

Backend ingest + agent on top. Your platform pushes data into SDX nightly via the REST API. Internal users hit your platform's chat interface, which uses MCP to read SDX in real time. Two surfaces, one pipeline.
Build with MCP, ship with REST. Prototype the workflow inside an MCP-connected agent to figure out the right call shape. Once the pattern stabilizes, port the hot path to REST so it can run server-side without an LLM in the loop.
Agent with deterministic side-effects. The agent decides via MCP what to do, then calls a deterministic REST endpoint to commit the change. Common when you want an audit-trail-friendly write path.

Both surfaces use the same scoped permission model (read:portfolio, read:compliance, write:meters, write:portfolio, admin:org) — a token with read:portfolio cannot write meter readings on either surface.

The difference is who grants consent and how:

REST API — you generate a scoped API key in the SDX UI as a representative of an organization. The key acts on behalf of that org until revoked.
MCP — the user authorizes the agent inside an OAuth flow. The agent's session has the scopes the user granted, scoped to the orgs they have access to.

For multi-tenant consumer-facing agents (one agent, many users), MCP is the right fit because consent is per-user. For server-to-server work where one organization is integrating one platform, the REST API is simpler.

What's not a reason to choose one over the other

"MCP is faster than REST." They hit the same backend. The hot path is identical.
"MCP gives you AI features the REST API doesn't." It doesn't. MCP exposes tools to a model; the model is yours, not SDX's.
"REST is more reliable." Both are. MCP is a transport — when something breaks at the SDX level, both fail the same way.

Still unsure?

Default to the REST API for production server-to-server integrations and MCP for anything an agent drives. If you find yourself writing glue between them, you've probably picked the right combination.