Drip API + MCP (2026): v2 REST, v3 Shopper Activity, official MCP

Drip exposes two concurrent HTTP surfaces, the general-purpose REST API v2 and the ecommerce-only Shopper Activity API v3-plus four official clients in Ruby, Node.js, PHP and .NET. There is no message-transport endpoint anywhere in it: you push people, tags and commerce events in, and Drip renders and sends the mail. On the agent side Drip is ahead of most peers, having shipped a first-party remote MCP server at api.getdrip.com/mcp in the June & July 2026 release. OAuth, approval-gated writes, free, with one blocker that costs people an afternoon, because Drip support must switch it on first.

At a glance

MCP integration in 2026

Model Context Protocol lets an AI client such as Claude or ChatGPT call a vendor’s tools directly instead of a human copying data between tabs. For an ecommerce CRM that matters more than usual: Drip’s value sits in segments, workflow enrolment and revenue reporting, all tedious to query by hand. Drip answered in mid-2026 with a first-party server.

Announced August 11, 2026, it reads every subscriber, tag and custom field, pulls opens, clicks and revenue data, and reads any campaign email in full. Writes cover tagging, updating and bulk-importing up to 1,000 subscribers, drafting campaigns, test sends and workflow enrolment.

Available MCP servers

One official server plus two third-party options worth knowing (a third, viaSocket, resells a hosted Drip endpoint). They stay relevant because GravityKit uses an API key rather than OAuth, which suits headless and CI contexts where nobody can click a consent screen, and Zapier MCP chains Drip actions to the rest of a Zapier account.

Drip API essentials

The key structural fact: v2 and v3 are two different surfaces under one host, not two generations of the same one. v3 did not supersede v2, it was added alongside as a schema-bound commerce pipeline and replaces the legacy v2 Orders resource. Merge them in your mental model and you will send orders to the wrong path.

The v2 surface spans roughly 18 resource families, but almost every external write lands in three. Subscribers, Tags and Events, because those are what segmentation and workflow triggers read. v3 has exactly three: cart, order and product, each with a /batch sibling. Collections paginate identically: request ?page=1, read meta.total_pages, loop. Batch endpoints return 202 Accepted and request_ids-queued, not applied.

Authentication methods

Two credential models, chosen by whether you act on your own account or someone else’s.

HTTP Basic auth with an API token

The standard method for private integrations, identical on v2 and v3. Pass the API token as the username with an empty password-in curl, curl -u YOUR_API_KEY:, the trailing colon doing the work. The token lives in your Drip user settings and is account-scoped, treat it as a full-access secret.

OAuth 2.0 bearer tokens

For public integrations acting on behalf of other Drip accounts. Authorize at https://www.getdrip.com/oauth/authorize, exchange at https://www.getdrip.com/oauth/token, then send Authorization: Bearer YOUR_ACCESS_TOKEN. The MCP connector uses this same path, which is why MCP access can be scoped per subaccount in a way an API token cannot.

Required request headers

A descriptive User-Agent is required on every request. Drip’s examples use the form Your App Name (www.yourapp.com), not a default library string. The client must also support SNI over HTTPS. Both are cheap to satisfy and expensive to diagnose.

Rate limits

Drip runs two independent request pools, and the batch pool is far smaller than intuition suggests. Both reset hourly.

The workaround for a large import is arithmetic, not engineering. Loading 40,000 subscribers one at a time burns 40,000 calls against a 3,600-per-hour budget and takes over 11 hours; as 40 batch calls of 1,000 it finishes inside one hour. Batch every migration and nightly sync, never retry-loop a batch call, and count each pool separately.

Official SDKs

Four official clients, all MIT licensed, all under the DripEmail organisation, and not equally maintained: Ruby and Node.js are current, PHP and .NET have not moved in a year.

Ruby is the most actively maintained (updated August 11, 2026). The Node.js client was updated February 11, 2026, latest release 3.1.4, and is the only official client covering both v2 REST and v3 Shopper Activity, the default for a new ecommerce integration.

Notable community SDKs

There is no official Python client, which surprises people given how much ecommerce plumbing runs on Python. Community PyPI wrappers exist but none is endorsed by Drip or tracks v3 reliably, so call the REST API directly with requests-Basic auth, plain JSON, under 50 lines. Same for Go and Java. The GravityKit MCP server above is the one useful third-party project: its 30+ tools double as a readable reference implementation.

Endpoints reference

These fifteen paths cover essentially everything an external system does with Drip; full schemas and error codes live in the official Drip API reference. Note the version prefix on the last two rows, separate v3 surface, not a v2 sub-resource. Outside the list sit /forms, /users, /conversions, /event_actions and /v3/:account_id/shopper_activity/product.

Code examples

Verify credentials and find your account ID

curl -u YOUR_API_KEY: -H "User-Agent: SMTPedia Example (www.smtpedia.com)" https://api.getdrip.com/v2/accounts

# 200 => {"accounts":[{"id":"9999999","name":"Example Store", ...}]}
# 401 => wrong token, or you dropped the trailing colon that supplies
#        the empty password Basic auth requires.

Python: subscribers, events and orders without an SDK

import os, requests

API_KEY = os.environ["DRIP_API_KEY"]
ACCOUNT = os.environ["DRIP_ACCOUNT_ID"]
HEADERS = {"Content-Type": "application/json",
           "User-Agent": "SMTPedia Example (www.smtpedia.com)"}
AUTH = (API_KEY, "")          # API key as username, empty password
v2 = f"https://api.getdrip.com/v2/{ACCOUNT}"
v3 = f"https://api.getdrip.com/v3/{ACCOUNT}/shopper_activity"

# 1. Upsert a subscriber (POST to the collection keys on email)
requests.post(f"{v2}/subscribers", auth=AUTH, headers=HEADERS, timeout=30,
    json={"subscribers": [{"email": "shopper@example.com",
                           "tags": ["vip"],
                           "custom_fields": {"first_name": "Ada"}}]}).raise_for_status()

# 2. Generic behavioural event
requests.post(f"{v2}/events", auth=AUTH, headers=HEADERS, timeout=30,
    json={"events": [{"email": "shopper@example.com",
                      "action": "Viewed sizing guide"}]}).raise_for_status()

# 3. Orders go to v3, never to /v2/events, or revenue attribution
#    and abandoned-cart flows will never see them.
order = requests.post(f"{v3}/order", auth=AUTH, headers=HEADERS, timeout=30,
    json={"provider": "my_custom_platform",
          "email": "shopper@example.com",
          "action": "placed",
          "occurred_at": "2026-08-19T10:15:00Z",
          "order_id": "ORD-1001",
          "grand_total": 79.90,
          "currency": "USD",
          "items": [{"product_id": "SKU-42", "name": "Trail Runner",
                     "quantity": 1, "price": 79.90}]})
print(order.status_code, order.json())   # 202 Accepted + request_ids

Node.js with the official client

// npm install drip-nodejs --save
const client = require('drip-nodejs')({
  token: process.env.DRIP_API_KEY,
  accountId: process.env.DRIP_ACCOUNT_ID,
});

// Since v3.1.2 responses expose `.data`, not `.body`.
async function main() {
  await client.createUpdateSubscriber({ email: 'shopper@example.com', tags: ['vip'] });

  // v3 Shopper Activity: the only path that feeds revenue reporting.
  await client.createUpdateOrder({
    provider: 'my_custom_platform',
    email: 'shopper@example.com',
    action: 'placed',
    occurred_at: new Date().toISOString(),
    order_id: 'ORD-1001',
    grand_total: 79.9,
    currency: 'USD',
    items: [{ product_id: 'SKU-42', name: 'Trail Runner', quantity: 1, price: 79.9 }],
  });

}

main().catch((err) => {
  // 429 => rate_limit_error. Two pools: 3,600 individual, 50 batch per hour.
  console.error(err.response ? err.response.status : err);
  process.exit(1);
});

Common gotchas

Deprecations and changelog

• August 11, 2026-June & July 2026 release notes headline Drip MCP, “a secure bridge between Drip and the AI tool you already use”. Same release adds API-based draft email creation via the Custom HTML builder, workflow email metrics over the API, and custom Reply-To addresses.
• May 20, 2026-April & May 2026 release notes launch the Metrics API for campaign engagement, delivery and revenue data (enablement required), plus the Product Library under Settings.
• March 27, 2026-February & March 2026 release notes add soft bounce reporting, auto-resume automations, an Onsite SMS Consent form element, and WooCommerce webhook cleanup fixes.
• Ongoing-the v2 Orders resource is labelled “Orders (Legacy)”. New commerce integrations should target Shopper Activity v3.

Drip publishes dated release notes rather than a formal API changelog. The official release notes are the record; deprecation labels appear in the API reference.

Frequently asked questions