Programmatic Access
MCP is the way in for your own code, the webhook inbox for incoming data. There is deliberately no classic REST interface.
How other systems talk to the platform — and how they don’t.
There is no classic REST interface with an API key. That is a decision, not a gap: the tool surface is the one definition of what the platform can do, and the UI and agents use the same one. A parallel REST surface would be a second truth that drifts apart. So MCP is the API — with the advantage that a client reads the tools and their parameter schemas on connect, instead of following a typed-out endpoint list that goes stale.
The short answer: for automation and your own code, MCP; for incoming data from third-party systems, the webhook inbox. The web app’s routes (/api/app/...) are not a public API and cannot be used from outside.
1. MCP — the programmatic entry point
One endpoint per workspace, carrying the whole tool surface (the same functions the UI uses):
https://app.cegtec.net/api/mcp/<workspace-mcp-key>Create or fetch the key in the workspace settings, or via the generate_mcp_key / get_mcp_key tools. The key is workspace-bound — it cannot see or change anything outside that workspace.
MCP clients exist for most environments (Claude, Claude Code, your own scripts, n8n). You do not need to look up the full tool list: a client asks for it on connect, and every tool ships its description and parameter schema. That is why there is no typed-out endpoint table here to go stale.
Setting it up per client — copy-paste blocks for Claude Code, Cursor, VS Code and stdio-only clients — is on Claude Code & Other Agents.
2. Webhook inbox for your own data
The generic data entry point — send rows from any system (a form, Zapier, Make, your own backend) into a workspace:
POST https://app.cegtec.net/api/webhooks/ingest/<orgId>/<sourceId>Authentication: a shared secret per source, either as the header x-webhook-secret: <secret> or as the query parameter ?secret=<secret> — the query variant exists for no-code tools that cannot set headers. Missing or wrong secret: 401. Source disabled: 403.
You create such a source with create_webhook_source; that produces the sourceId and the secret.
What happens to the data: it is mapped onto the ontology (company or lead) and can trigger a workflow — that is part of the source configuration, not of the request.
3. Integration callbacks
Connected services report events back — opens and replies from email sending, LinkedIn activity, calendar bookings, billing, telephony. The platform sets these callbacks up as soon as you connect an integration. You never call them yourself, and there is nothing to configure.
Every callback verifies the origin of the incoming data (signature, secret or token) and attributes it to the workspace the integration belongs to.
4. What is not an API
/api/app/<orgSlug>/... — the web app’s routes. They are session-authenticated: they expect the browser’s login cookie and additionally check the request’s origin. A call with curl, from n8n, or from your own code fails even with a valid login — that is intended, not a defect. For anything programmatic: MCP (section 1).
/api/cron/... and /api/admin/... — internal operational endpoints, protected by a shared secret. Not intended for customers.
Known limitations
- No public REST surface for the core objects. Companies, leads and deals are reachable programmatically through MCP, not through HTTP endpoints with an API key. Should that change, it belongs here.
- No OpenAPI schema, because there is no public REST surface. The MCP tools carry their own parameter schemas and clients can read them.