One uniform surface

Boom’s public platform is a single set of capabilities. Each one (say, create a WhatsApp template) is defined once, with one input schema, one output shape, and one set of error codes, and then exposed everywhere:

REST: as an endpoint under /api/v1, authenticated with an organization API key.
MCP: as a tool with the same name and schema, authenticated with your Boom login (set up in two steps).

Whatever you learn on one surface transfers to the other: the field names, the validation rules, the pagination cursors, and the error codes are identical. An integration you prototype by chatting with an AI tool over MCP behaves the same when you port it to server-side REST calls.

This documentation is generated from the same schemas the API validates against. The reference pages cannot drift from what the platform actually does.

Two exceptions, both in the MCP direction. Authoring your agent’s own tools (org_tool_list, org_tool_upsert) has no REST endpoint: those calls change what your customer-facing agent can do. Neither do send drafts (drafts_list, drafts_get, drafts_count, drafts_decide), which approve or reject journey sends a reviewer is holding. Both are deliberately limited to a surface where a named person is signed in — an organization API key identifies the integration, not the person, and “who approved this send” has to name someone. Everything else on this page is available on both.

How names map

MCP tool names are the REST resource and action joined with underscores. A few representative rows per domain (the API and CDP tabs list every endpoint):

Domain	REST endpoint	MCP tool
CDP: People	`POST /api/v1/cdp/people`	`cdp_people_upsert`
CDP: People	`GET /api/v1/cdp/people/{externalId}`	`cdp_people_get`
CDP: Events	`POST /api/v1/cdp/events`	`cdp_events_record`
CDP: Custom objects	`POST /api/v1/cdp/custom-objects`	`cdp_custom_objects_upsert`
CDP: Relationships	`POST /api/v1/cdp/relationships`	`cdp_relationships_link`
Segments	`GET /api/v1/segments`	`segments_list`
Segments	`POST /api/v1/segments/preview`	`segments_preview`
Segments	`POST /api/v1/segments/{slug}/evaluate`	`segments_evaluate`
Initiatives	`POST /api/v1/initiatives`	`initiatives_create`
Initiatives	`POST /api/v1/initiatives/{id}/launch`	`initiatives_launch`
Initiatives	`GET /api/v1/initiatives/{id}/data/summary`	`initiatives_summary`
Participants	`POST /api/v1/initiatives/{id}/participants`	`initiatives_participants_add`
Participants	`GET /api/v1/initiatives/{id}/participants/{participantId}/messages`	`initiatives_participant_messages_list`
Participants	`GET /api/v1/initiatives/{id}/transcripts`	`initiatives_transcripts_list`
Participants	`POST /api/v1/initiatives/{id}/participants/{participantId}/stop`	`initiatives_participants_stop`
Journeys	`GET /api/v1/journeys`	`journeys_list`
WhatsApp templates	`GET /api/v1/whatsapp-numbers`	`whatsapp_numbers_list`
WhatsApp templates	`POST /api/v1/templates`	`templates_create`

What differs per surface

Only the transport-level concerns:

	REST	MCP
Auth	Organization API key (Bearer token)	Your Boom login (OAuth)
Access control	The organization API key	Your role: each tool needs the permission your role grants for the same action in the app (roles)
Rate limits	Per key	Per organization, per tool
Errors	`{ "error": { "code", "message" } }` + HTTP status	Tool error with the same `code: message`

Use MCP

Connect Claude, Cursor, or any AI tool to Boom.

Quickstart

The same capabilities over REST, end to end.

Start here

How Boom works

Connect your tools

Reference

One uniform surface

How names map

What differs per surface

Use MCP

Quickstart

​How names map

​What differs per surface

​Related

Use MCP

Quickstart

How names map

What differs per surface

Related