Skip to main content
The pages an engineering team reaches first — what Beacon reads from your systems, what it will never do to them, what it writes back, and the two read contracts it publishes. The API reference and the MCP tool catalogue are published; neither is served yet. Both fix the names and shapes ahead of the build, so anything written against them will not have to change when they arrive. Nothing you read there can be called today.

Connect your tools

What Beacon reads, what each connection unlocks, and what connecting actually involves.

Connector catalogue

Every source Beacon reads, how each one connects, how often it refreshes, and whether it can write.

Boundaries

What Beacon will never do with your systems — each limit with the mechanism that enforces it and how to check it.

When a source is missing

What billing being down does, what any other missing source does, and what a refused read returns.

Which path to use

Four ways to get Beacon’s figures into the rest of your stack, and the one question that decides between them.

Access and grants

What a reader grant states, how outside software connects, and what a request outside a grant returns.

Data model

The objects Beacon publishes and the values on each one, with the account and deal objects in full.

API reference

The Beacon Data API contract — what your systems will read, what travels with every value, and the refusals it returns. Published, not yet served.

MCP tools

The resources Beacon’s MCP server publishes and what it will never do. Published, not yet served.

Troubleshooting

What a figure that is missing, switched off, refused or stale is telling you, and what to do about it.