Concepts

Pathbound is a unified B2B customer-context platform. It connects data from your CRM, website analytics, email, LinkedIn, and other tools into a single profile per contact and company — then exposes that context through three surfaces: the REST API, the MCP server, and the tracker.

The object model is small. Once you understand these seven concepts, the rest of the docs is just the API surface around them.

Contacts

A contact is a person tracked across all connected sources. Every contact has:

• A unified profile — properties merged from CRM, enrichment providers, and form submissions.
• An event timeline — chronological cross-system activity (page views, opens, replies, syncs).
• Notes — free-form internal annotations.
• Conversations — Gmail threads and Intercom chats (when those sources are connected).
• An association with one company.
• Membership in zero or more segments.

→ Contacts API

Companies

A company is the primary B2B unit. Individual contacts roll up to company-level intelligence. Companies are identified by domain and have properties like industry, employee_count, and lifecyclestage. When you query a company, Pathbound returns its associated contacts (up to 25).

→ Companies API

Events

An event is a tracked interaction across any connected source — a page view, button click, form submission, video play, email open. Events are linked to a contact (when the visitor is identified) and provide the behavioral signal layer that powers segments and agents.

The tracker is the most common source of events, but events can come from email opens, CRM webhooks, video providers (Wistia), and custom track() calls.

→ Events API

Segments

A segment is a named group of contacts used for cohort analysis and agent targeting. Segments answer questions like “who visited pricing twice this week and hasn’t been emailed in 5 days.” You define segments in the dashboard; the API lets you list them and fetch their members.

→ Segments API

Identities

An identity is a sender — the email account or LinkedIn profile that performs an action on behalf of a tenant. Identities have authentication state (Gmail OAuth tokens, LinkedIn session cookies) which is stored encrypted and never returned through the API. Every action requires an identity_id.

→ Identities API

Actions

An action is a unit of work — send an email, send a LinkedIn connection, create a note, update a contact, sync to CRM, escalate to a human. Actions can be:

• Scheduled — queued for a future scheduled_time.
• Pending approval — waiting on a human (or scoped key) to approve.
• Executed directly — direct: true, no scheduling.

Actions are the audit trail for every outbound or write operation Pathbound performs. They’re created by agents automatically, by you via the API, or by users in the dashboard.

→ Actions API

Agents

An agent is an AI worker that monitors contacts matching a filter, analyzes their activity, and proposes actions. Agents run on a schedule (or when manually triggered), and each run produces a list of (contact, proposed_actions, reasoning) tuples that humans (or a key with agents:approve) can review.

Agents have:

• A playbook — a markdown prompt that tells the agent how to think.
• Capabilities — the action types the agent is allowed to propose.
• Monitoring — the filter, schedule, and per-run cap for which contacts to evaluate.
• An LLM config — provider, model, temperature.
• A default identity — used for any outreach the agent proposes.

→ Agents API

How it fits together

Tracker  ───▶  Events  ───┐
                          │
Connected sources  ───▶  Contact  ───▶  Company
(CRM, email, etc.)        │
                          │
                       Segment  ◀───▶  Agent  ───▶  Action  ───▶  Identity
                                                      │
                                                      ▼
                                                  Outbound
                                                  (email, LinkedIn, CRM, …)

A typical loop:

1. The tracker captures behavioral events on your site.
2. A form submission (public form endpoint) identifies the visitor — events are now linked to a contact.
3. The contact lands in a segment (e.g. “pricing visitors with no recent email”).
4. An agent monitoring that segment runs, reads the contact’s timeline, and proposes an action.
5. A human reviewer approves the action — or a scoped API key auto-approves.
6. The action executes via an identity (Gmail send, LinkedIn DM, CRM update).
7. The send itself becomes an event; the loop repeats.