The deployment layer decides where the Decision System appears. The intelligence and the reasoning are the same wherever it runs, so the choice of surface is yours to make based on where your teams already work rather than on where the capability happens to live.
The principle: no new destination application
Adoption usually fails at the point where a seller has to remember to open something. The deployment layer exists so that they do not have to. Guidance arrives in the tool they already have open, and the Databook application becomes one surface among several rather than the only one.
This also means you can consolidate rather than add. If your teams have standardised on a CRM and a messaging tool, the system comes to those two places instead of becoming a third.
Choosing a surface
Surface | Best for | What it takes |
Databook application and GTM Command Center | Deep work: account planning, research, building a point of view | Available to your users as standard |
CRM, Slack and Teams | In-workflow guidance and proactive notifications where your teams already are | An integration, configured with your account team |
MCP | AI assistants and agents, where a language model is the interface | Connection details from your account team, no custom build |
API | Your own applications, embedded intelligence, or a front end you build | Credentials from your account team, plus development work |
Reasoning inside your own agent platform | Using Databook as the domain-specific inference layer behind agents you build elsewhere | The Reasoning API, configured with your account team |
Building with the APIs
Databook's APIs expose capabilities rather than raw data, which means you call the thing you want done rather than assembling it yourself from records.
Chat API for real-time conversational responses, with full reasoning and access to coaches. Use it to let a user interact with Databook from another surface, such as your CRM or a messaging tool.
Batch API for pre-configured insights generated across large numbers of accounts, returned as a CSV file. Use it to populate fields at scale, for example adding strategic priorities to the account object in your CRM, or to sweep your account base for a specific change (e.g. management changes).
Reasoning API for structured output produced by a pre-defined reasoning agent, where you need control over the sources used, the reasoning steps taken and the shape of what comes back. Territory scoring is a common example use case for this API.
A few constraints apply across all of them:
All connections use OAuth 2.0, and credentials are issued by your account team rather than created self-service.
The Batch and Reasoning APIs need configuration by Databook first, so that the insights and reasoning agents you want to run are set up before you call them.
Output carries usage terms. It cannot be used to extract the underlying data, to train or fine-tune models, and it needs the required disclaimers and citations when published.
Read Databook APIs and MCP server: an overview before you pick one.
Using MCP
MCP suits the case where the interface is already a language model. Any client that supports the Model Context Protocol can connect to the Databook MCP server, and your developers do not need to build against the API to get there.
The server exposes Databook conversational access including coaches and asset generation, a set of purpose-built insight tools covering company summaries, financial and earnings analysis, management initiatives, industry benchmarking and product alignment, and asynchronous retrieval for longer-running queries.
It is deliberately not a general-purpose door into Databook. Only the published tools are available, there is no bulk data extraction, and it is not a substitute for scheduled high-volume processing, which belongs on the Batch API.
Building your own front end
Some organisations want an interface designed around their own motion rather than a general-purpose application. The deployment layer is built to support that: you host and own the front end, and Databook hosts and owns everything beneath it.
Databook provides | You provide |
The Decision System underneath the surface: intelligence, agentic workflows, coaches, assets and the Customer Context Graph | Your front end: hosting, deployment, look and feel, and the glue specific to your surface |
External APIs and MCP with a documented, versioned contract, plus performance, rate limits and guardrails | Any connector or plugin into a specific AI application or CRM you want it inside |
Reference components, a reference architecture and guidance so that what you build is built correctly | Ongoing maintenance of the code you build from those references |
Reference components and the accompanying developer guidance are in development. If building your own surface is on your roadmap, raise it with your account team early so the sequencing works, rather than starting from the API reference alone.
The same model applies to connectors and plugins for a specific AI application. Databook provides the MCP server and guidance on building against it, and you build and maintain the connector into the application you have chosen.
What to expect
Response times vary by route. Conversational calls return in seconds. Batch jobs run for hours rather than seconds, and the Reasoning API sits between the two depending on how much reasoning the agent does.
Output can differ from the application. The same question asked through an API and in the Databook application reasons over the same context, but the formatting and the level of detail are shaped by the route you used.
Capability availability depends on your configuration. Which coaches, insights and reasoning agents you can reach through an API or MCP reflects how your Databook instance is set up, not a fixed list that is identical for everyone.
Getting access
Credentials are not self-service today, so start with your account team. Tell them which surfaces you want Databook delivered into and what you intend to build, and they will set up the credentials, configure any insights or reasoning agents your workload needs, and point your developers at the right documentation.