← Documentation home

How DripPulse works

One-page architecture for evaluators and implementers. For HTTP details see the API reference; for a first win see lead qualification.

What DripPulse is

DripPulse is an agent-operable CRM: a CRM system built so external agent systems can qualify leads, update records, route opportunities, and run workflows—not only for humans clicking through the UI. You model work as workflows (steps: triggers, filters, actions) and agents (deployed runtimes, often from templates), with structured access via skills packs, integrations, webhooks, and the JSON API under /api/v1. Humans define controls, approvals, and oversight.

Core objects and how they relate

Everything below is scoped to an organization (your tenant). Isolation is enforced in the API and dashboard.

Object	Role
Organization	Tenant boundary; billing, settings, and data belong here.
Users & team members	People with roles (Admin, Editor, Viewer, Approver) who use the dashboard.
Projects	Organizational boundary for related workflows and assets.
Agent templates	Reusable definitions (policies, behaviors) used to spawn agents.
Agents (deployed)	Running instances tied to your data and permissions; executions, logs, and metrics attach per agent.
Workflows	Step graphs you author in the UI or API; testable before production.
Integrations	Connections to external systems (see Settings and `/integration_connections`).
Webhooks (outbound)	Subscriptions that deliver events from DripPulse to your HTTPS endpoints.
API keys	Programmatic credentials; `Authorization: Bearer`; revocable; org-scoped.

Relationship diagram (conceptual)

  Organization
       |
       +--- Users / roles
       +--- API keys  ----------------->  HTTP clients, scripts, CI
       +--- Projects
       |         \
       |          `--- Workflows (steps, tests, enrollments)
       +--- Agent templates
       |         \
       |          `--- Deployed agents (executions, logs, metrics)
       +--- Integrations & data sources
       +--- Outbound webhooks (deliveries to your URLs)

Visual overview (same ideas as the tree above):

Execution model

What triggers a workflow: Step types you configure—e.g. schedules, inbound events, manual test runs. Available builders are listed via GET /api/v1/workflows/step_types.
How an agent is invoked: Through the API (e.g. POST /api/v1/agents/:id/execute, .../inference, .../score_lead), from workflow steps, or from inbound signed webhooks—depending on your setup.
Inputs: JSON payloads you send (or that webhooks carry). Org context and integrations supply CRM- and connector-scoped data where configured.
Outputs: Structured results in API responses, stored executions, downstream webhooks, CRM updates via integration steps—exact behavior is what you modeled in the workflow or agent policy.
Lifecycle: Workflow creation and updates are synchronous over the API; first execution logs can appear shortly after a run starts; long-running work may show up in monitoring and agent execution history.

Workflow lifecycle (simplified)

  [ Trigger ]  schedule / event / manual
       |
       v
  [ Filter / branch / score ]
       |
       v
  [ Actions ]  webhooks, integrations, agent steps, logging
       |
       v
  [ Observability ]  enrollments, monitoring, costs

Human control model

What can run automatically: Any step you add to a workflow or delegate to an agent within policy—e.g. scoring, routing rules, outbound notifications—without a manual gate unless you add one.
What can be gated: Product design and your process: use Approver roles and operational discipline for changes that should not ship unattended. Strategy, template changes, and key issuance remain human-controlled.
How actions are logged: Agent executions, workflow tests, webhook delivery history, and monitoring endpoints give a trace of what ran and what failed.
Investigating failures: Agent logs and execution records; failed webhook deliveries; application health via /health and dashboard monitoring—see Monitoring & troubleshooting.

Deployment model

DripPulse is typically a combination of:

Orchestration layer — workflows coordinate steps across time and events.
Augmentation layer — agents add scoring, summarization, and structured decisions on top of your data.
Integration layer — connectors and webhooks move data in and out; your CRM may remain the system of record while DripPulse automates around it.

    Your stack’s system of record (e.g. Salesforce, HubSpot) stays authoritative for customer data unless you explicitly design otherwise; DripPulse executes the automation and observability you configure on top.
  

Flagship example (use one story everywhere)

Across docs we standardize on the Lead Qualification Agent: inbound payload → score / tier → recommended owner → optional approval → CRM update → notification. See inbound lead qualification recipe and API quickstart.

Where to go next

Getting started — outcomes and 10-minute path.
Production readiness — keys, webhooks, retries.
RevOps guide — operator-focused setup.