enso.bot / developers

enso.bot Developer Resources

Everything an AI agent (or a human building one) needs to integrate with enso - the agentic growth lab. Public REST endpoints, an OpenAPI 3.1 spec, an MCP server, OAuth 2.1 auth metadata and native llms.txt files.

Quick links

All resources

OpenAPI spec/openapi.json

OpenAPI 3.1 specification for the enso public API. Also served at /api/openapi.json.

Public REST API - company/api/public/v1/company

Structured overview of enso: agents, pricing, founders, canonical URLs.

Public REST API - blog/api/public/v1/blog

List of enso blog posts (blog posts) with slugs, titles, authors and URLs.

Public REST API - research (list)/api/public/v1/research

List of Agentic Lab research experiments (attention-loophole blog posts).

Public REST API - research (detail)/api/public/v1/research/{slug}

Full write-up for a single research experiment by slug.

Public REST API - careers (list)/api/public/v1/careers

Open roles at enso with slug, title, tagline, location and URL.

Public REST API - careers (detail)/api/public/v1/careers/{slug}

Full role description for a single open position.

Signal API - event stream (auth)/api/public/v1/signals

Authenticated read API: every visitor and prospect touch on enso.bot as a normalized event stream. Requires x-api-key.

Signal API - accounts (auth)/api/public/v1/signals/accounts

Touches rolled up per company domain, with people, pages, sources and stage.

Signal API docs/signals-api.md

Full reference for the signal API: event types, filters, account and person lookups, polling notes.

Signal API agent manual/signals-agent.md

Operating manual for autonomous agents: polling loop, intent ranking, allowed actions, enso voice rules for drafted outreach.

MCP server/mcp

Model Context Protocol server. Streamable HTTP transport. Tools: get_company_info, list_experiments, get_experiment, list_blog_posts, list_careers, get_career.

OAuth authorization server metadata/.well-known/oauth-authorization-server

RFC 8414 metadata for the OAuth 2.1 authorization server backing the MCP endpoint.

OAuth protected resource metadata/.well-known/oauth-protected-resource

RFC 9728 metadata describing /mcp as an OAuth-protected resource.

llms.txt/llms.txt

Compact site overview and navigation hints for AI crawlers.

llms-full.txt/llms-full.txt

Extended enso documentation in markdown for LLM consumption.

AGENTS.md/AGENTS.md

Conventions and rules for AI coding agents working in the enso codebase.

Sitemap/sitemap.xml

Canonical URL index for enso.bot.

Auth

The /api/public/v1/* endpoints are read-only and require no authentication. The MCP endpoint at /mcp is protected by OAuth 2.1 with Dynamic Client Registration; discovery lives at /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource. Scoped permissions follow the standard OAuth openid email profile scope model.

Landing page API (write)

Agents can publish conversion landing pages at https://www.enso.bot/p/<slug>. Send x-api-key: $CONTENT_API_KEY. Content only - the enso design system is applied server-side. Blocks: hero, logos, stats, features, steps, quote, richtext, faq, leadform, cta.

  • POST /api/public/content/pages/generate - send a brief, enso writes the copy and the hero visual
  • POST /api/public/content/pages - create or replace a page from finished blocks (publishes immediately)
  • GET /api/public/content/pages - list pages
  • GET|PATCH|DELETE /api/public/content/pages/{slug} - read, edit, unpublish

Publishing has a built-in quality gate: the hero must be first and unique, its subcopy must name a clear ICP, copy and metadata lengths are constrained for responsive layouts, links and images must use safe URL formats, and off-brand wording is rejected with a 422 response. Customer logos and all visual styling come from the shared enso component kit, not from the API payload.

/generate is the recommended path. You send a topic, an ICP and the facts you can prove; enso writes the page against the block registry and the brand voice, renders a hero image with GPT image 2 in the house style, runs the same quality gate, and retries once with the failures fed back to the writer. Pages are saved as drafts so copy and visual can be reviewed before they go live. Never invented facts: with no proof points, stats and quote blocks are left out.

curl -X POST https://www.enso.bot/api/public/content/pages/generate \
  -H "x-api-key: $CONTENT_API_KEY" -H "content-type: application/json" \
  -d '{"slug":"agentic-seo-for-fintech",
       "topic":"Getting fintech brands cited inside AI answers",
       "icp":"Growth leads at Series B fintech companies",
       "proof":["64 citations placed","47 still live after 90 days"],
       "cta_label":"Book a call","cta_href":"/book-a-call"}'

Full reference, block-by-block field tables, layout rules and the publishing checklist: /content-api.md.

Signal API (read, authenticated)

Every touch a person or an account has with enso.bot - book a call submissions, website URLs entered on the homepage and campaign pages, article reads and research unlocks, newsletter signups, wizard progress, Slack requests, briefing registrations and email opens/clicks - normalized into one event stream you can poll into a CRM or outreach system. Send x-api-key: $SIGNALS_API_KEY.

  • GET /api/public/v1/signals - newest-first event stream (since, days, type, domain, email, q, limit)
  • GET /api/public/v1/signals/accounts - the same events rolled up per company domain, with a stage filter
  • GET /api/public/v1/signals/accounts/{domain} - one account: summary, people, full timeline
  • GET /api/public/v1/signals/people/{email} - one person: summary and full timeline

Signal ids are stable (source:row_id) so they double as idempotency keys, and account lookups return seen: false instead of a 404, which makes them safe to call as a journey check.

curl -sS "https://www.enso.bot/api/public/v1/signals?days=7&limit=500" \
  -H "x-api-key: $SIGNALS_API_KEY"

curl -sS https://www.enso.bot/api/public/v1/signals/accounts/acme.com \
  -H "x-api-key: $SIGNALS_API_KEY"

Full reference, event type table and polling notes: /signals-api.md. Point an autonomous agent at the operating manual instead: /signals-agent.mdcovers the polling loop, how to rank intent by signal type, what the agent may and may not do with the data, and the enso voice rules for any copy it drafts.

Example

curl https://enso.bot/api/public/v1/research | jq '.experiments[0]'
curl https://enso.bot/openapi.json | jq '.info'