GetResponse API + MCP (2026): v3 REST, no official MCP server

GetResponse exposes one documented REST surface — API v3 at https://api.getresponse.com/v3 — covering contacts, campaigns, newsletters, ecommerce objects and the transactional stream, with quotas of 80 requests per second and 30,000 per 10-minute window. The SDK story is thin: the PHP wrapper has not shipped since August 2023. And on agents GetResponse made an unusual choice — as of August 2026 there is no official GetResponse MCP server, its first-party AI tooling shipping as Agent Skills instead.

At a glance

MCP integration in 2026

The Model Context Protocol is how an AI agent discovers and calls a vendor’s tools without bespoke glue code — look up a list, add a contact, queue a newsletter, all as tool calls. GetResponse is a negative on this axis in 2026, but the reason is more interesting than a simple absence.

Available MCP servers

Three routes are worth knowing. Only one is published by GetResponse, and it is not an MCP server at all — it is listed because it is the best machine-readable description of API v3 in existence.

GetResponse API essentials

API v3 is a conventional JSON REST API: resources are plural nouns, GET returns a record or a filtered collection, POST creates or modifies, DELETE removes by ID. The version only increments on a backward-incompatible change, which has meant no bump since v3 landed. The most common mistake here is not a payload error but a base-URL error, because MAX and 360 accounts live on a different host entirely.

Two conventions repay reading before you write code. First, GetResponse calls its contact lists campaigns, so /campaigns is the list endpoint and almost every contact write needs a campaignId. Second, several writes are asynchronous: POST /contacts and POST /contacts/batch answer 202 Accepted and queue the work, so reading a contact back immediately will intermittently 404. And per-account sending quotas are deliberately not static numbers — GET /accounts/sending-limits is the authoritative runtime answer, so build that check into your deploy rather than hard-coding a figure that drifts with the plan.

Authentication methods

Two mechanisms, plus extra headers MAX and 360 accounts must send on every request. Both authenticate at account level and neither constrains what the credential may touch.

API key header

The route nearly every integration uses. Generate a key under Account › Integrations › API, then send it on X-Auth-Token with the literal api-key prefix:

X-Auth-Token: api-key YOUR_API_KEY
Content-Type: application/json

The prefix is mandatory: a bare key fails with a plain 401 and no explanation, which costs people an afternoon more often than it should. Hold one key per integration so you can revoke individually.

OAuth 2.0

Use this when you build something other people install, so you never hold their API key. Authorisation happens at https://app.getresponse.com/oauth2_authorize.html; tokens come from /v3/token. Four grants: Authorization Code, Client Credentials, Implicit and Refresh Token. Tokens travel on the standard header:

Authorization: Bearer ACCESS_TOKEN

Lifetimes differ by grant: an Authorization Code token lives 3600 seconds, a Client Credentials token 86400 seconds, and the authorization code must be exchanged within 10 minutes or it expires unused. Plan the refresh path before shipping — the failure mode is a job that passes testing and dies an hour into production.

MAX and 360 account headers

Enterprise accounts change three things at once: the base URL becomes api3.getresponse360.pl/v3 or api3.getresponse360.com/v3; every request must carry X-Domain with the client domain minus the protocol prefix; and OAuth authorises against a custom-domain getresponse360.com endpoint. X-Parent-Login optionally pins one parent account.

X-Auth-Token: api-key YOUR_API_KEY
X-Domain: client.example.com
X-Parent-Login: parent_account_login

Rate limits

GetResponse publishes its API limits plainly. Three ceilings apply at once and any can be breached independently.

Exceeding a ceiling returns HTTP 429 with currentLimit and timeToReset in the body — sleep for timeToReset rather than applying blind exponential backoff, since the reset is a window boundary and backing off longer only wastes throughput. The workaround for large syncs is structural: batch writes 1,000 at a time through /contacts/batch instead of firing individual POST /contacts calls, cap the worker pool at 10, and pull collections at perPage=1000. A 100,000-contact import done correctly is 100 requests; done naively it is 100,000 and spends most of its life in 429 handling.

The 10 parallel connections figure is an API limit. GetResponse publishes no concurrent-connection ceiling for its SMTP relay and the two must not be conflated — see the SMTP settings tab for what is documented on the relay side.

Official SDKs

This is the weakest part of the GetResponse developer story. Five SDK repositories exist, but only two wrap the REST API and both are PHP; the rest are mobile push libraries that do nothing for a server-side integration. No first-party Python, Node, Ruby, Go, Java or .NET client exists.

Notable community SDKs

Because API v3 is plain JSON REST with a single auth header, most teams skip the SDK layer and use their language’s standard HTTP client, which is what the examples below assume. Where a wrapper helps is in typed languages, and the useful 2026 move is to generate one: GetResponse’s public-api-agent-skills repository publishes an AI-optimised openapi.json that feeds straight into openapi-generator or oapi-codegen, yielding a client matching the current surface rather than the 2023 one. Community packages on npm and PyPI have no real traction or vendor endorsement — audit the source first.

Endpoints reference

These paths are verified against GetResponse’s own OpenAPI specification. The full resource index is at apidocs.getresponse.com/v3/resources, with webhook payloads at /v3/payloads. Confirm sub-paths and payload fields there before coding against the final row.

Code examples

Python — resolve a campaign, add a contact, read the live quota

Three things catch people here: the api-key prefix, POST /contacts returning 202 rather than the created record, and assuming a quota instead of reading it.

import requests

API_KEY = "YOUR_API_KEY"
BASE = "https://api.getresponse.com/v3"
HEADERS = {
    "X-Auth-Token": f"api-key {API_KEY}",
    "Content-Type": "application/json",
}

# 1. Find the campaign (list) you want to write into
r = requests.get(f"{BASE}/campaigns", headers=HEADERS,
                 params={"query[name]": "Newsletter", "perPage": 100})
r.raise_for_status()
campaign_id = r.json()[0]["campaignId"]

# 2. POST /contacts upserts - it updates if the email already exists.
payload = {
    "email": "ada@example.com",
    "name": "Ada Lovelace",
    "campaign": {"campaignId": campaign_id},
    "dayOfCycle": "0",
}
r = requests.post(f"{BASE}/contacts", headers=HEADERS, json=payload)

print(r.status_code)  # 202 Accepted - queued, not created inline

# 3. Read the live quota rather than assuming a static one.
limits = requests.get(f"{BASE}/accounts/sending-limits", headers=HEADERS).json()
print(limits)

# Budget: 80 req/s, 30000 per 10 min, 10 parallel connections.
# On 429 the body carries currentLimit and timeToReset - sleep timeToReset.

Node.js — batch import with rate-limit handling

Above a handful of contacts use /contacts/batch: cap 1,000 per request, work queued, so treat 202 as success and confirm via the contact import finished webhook rather than polling.

const API_KEY = process.env.GETRESPONSE_API_KEY;
const BASE = "https://api.getresponse.com/v3";
const headers = {
  "X-Auth-Token": `api-key ${API_KEY}`,
  "Content-Type": "application/json",
};

async function importBatch(campaignId, contacts) {
  // Hard cap is 1000 contacts per request
  const res = await fetch(`${BASE}/contacts/batch`, {
    method: "POST",
    headers,
    body: JSON.stringify({ campaignId, contacts }),
  });

  console.log(res.status); // 202 Accepted = queued for async processing
  console.log("remaining:", res.headers.get("X-RateLimit-Remaining"));

  if (res.status === 429) {
    const { timeToReset } = await res.json();
    await new Promise((r) => setTimeout(r, timeToReset * 1000));
  }
}

importBatch(campaignId, [
  { email: "ada@example.com", name: "Ada Lovelace" },
  { email: "grace@example.com", name: "Grace Hopper" },
]);

Common gotchas

Deprecations and changelog

• August 17, 2026 — Per-message open-tracking controls added, so senders can disable the tracking pixel on individual messages. Introduced to meet French CNIL and Italian Garante requirements.
• August 12, 2026 — Promo price feature launched: emails can show original and sale price side by side across Shopify, Magento, WooCommerce, PrestaShop, Shoper and custom API integrations.
• April 16, 2026 — Revenue attribution released, tying individual emails and workflows to purchases and reporting attributed revenue per message.
• August 22, 2023 — Last release of getresponse/sdk-php (v3.0.0) and its HTTP client. No first-party PHP SDK release since.

The product feed is at getresponse.com/about/whats-new; API changes appear at apidocs.getresponse.com/v3, which states the version only increments on a backward-incompatible change. The legacy JSON-RPC v1 and v2 APIs are no longer documented and should be treated as retired.

Frequently asked questions