Developers

Two ways in: MCP for assistants, REST for programs

Everything Openpulse finds is reachable programmatically. An assistant connects over MCP and authenticates with OAuth; a program calls the REST API with a workspace key. Both read one workspace’s own data, and both are self-serve: a workspace admin creates the credential, with no call to sales.

Start 14-day free trial View the OpenAPI spec

Quickstart: from nothing to your first signal

Four steps. The only manual one is creating the key, which is deliberate: a credential that reads a workspace’s private data should be issued by a person who owns that workspace.

Create a workspace
Sign up, paste your website, and edit the vocabulary Openpulse proposes. Nothing runs until you approve it.
Mint a key
Settings → API keys. Tick only the permissions you need; the key is shown once. Keys start op_live_, so a secret scanner can catch one committed by accident.
Read the spec
/openapi.json is generated from the server’s own route table, so it cannot describe an endpoint that is not mounted. Point your client generator at it.
Call it
Signals are the raw evidence; the roll-ups are usually the better answer to a sales question. Both are one request.

Your first request

curl -s https://openpulse.cloud/v1/results?limit=5 \
  -H "Authorization: Bearer op_live_your_key_here"

MCP: for Claude, ChatGPT and anything else that speaks it

A hosted server over streamable HTTP with OAuth 2.1. No key to paste and nothing to run locally: the client walks the consent flow and the tokens belong to the person who granted them.

Add https://openpulse.cloud/mcp as a remote MCP server. Your client will open a consent screen; approve it with the account that owns the workspace. The tool list is public, so a client can see what is on offer before anyone authorises anything: the server card.

An agent may read signals, listeners, runs and roll-ups, rate a signal, and queue a run if the person is an admin. It may not create, change or delete a listener: a listener commits the workspace to recurring search and model spend on every schedule tick, and no read tool needs that power to be useful.

Start with list_workspaces (every other tool needs a workspace id and there is no other way to get one), then get_usage_guide before anything non-trivial. Full flow in auth.md.

Permissions: a key is always a member, never an admin

Privilege comes from scopes, and the scope vocabulary has no way to express an admin action. A leaked key can read signals and move deals; it can never create a listener, change billing, or mint another key.

Scope	Grants
`signals:read`	List and read signals, their scores and their reasoning.
`accounts:read`	List companies and what has been found about them.
`pipeline:read`	List deals, their stages and the return figures.
`pipeline:write`	Add deals and move them between stages.
`collections:write`	Save signals to lists, and write notes.
`export:read`	Download the CSV exports. Filtered only: a key is never an admin.

A route that declares no scope is unreachable by a key at all. That is why the spec describes fewer operations than the dashboard uses: the rest are session-only, and publishing them would document an interface no key can call.

Reference: everything in machine-readable form

These are generated at build time from the same constants the product enforces, so none of them can quietly disagree with the running server.

Rate limits are per workspace and reported in the response headers rather than documented here, where they would go stale. Status: /health.

Something unclear or wrong? Email support@openpulse.cloud.