GetResponse
Manage GetResponse contacts, campaigns (lists), tags, custom fields and newsletters — on the retail platform and on GetResponse MAX.
About
GetResponse ships in the w6w first-party pack. It declares 14 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.
- App id
io.w6w.getresponse- Version
- 0.1.3
- Author
- w6w
- Licence
- MIT
- Categories
- Marketing · Email
Overview
GetResponse is an email marketing platform built around contacts, lists (which it calls campaigns) and the newsletters sent to them, and this app lets a workflow manage all three: create, update, look up and remove contacts, tag them, and read the campaigns and custom fields that shape how they’re segmented.
Sending a newsletter is the one action here with real, immediate consequences — it requires a verified sender address and an existing campaign, and defaults its audience to that same campaign so the common case of “send this to the list it’s already tied to” takes one field rather than several. Because GetResponse queues a new contact rather than creating it instantly, a workflow that creates and immediately reads back has to expect a short delay, which is simply how the platform’s own API behaves.
This app works against both GetResponse’s retail product and its enterprise MAX platform, since a single account only ever lives on one of the two. Design-time surfaces like forms, landing pages and autoresponders stay out of scope — this is about the contacts and sends a marketing workflow actually needs to touch.
Build with GetResponse
Three routes to the same 14 actions. The Workflow tab is generated from GetResponse's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
List Campaign Contacts
campaign-contacts List the contacts on one campaign (list), with the same filters as List Contacts.
List Campaigns (Lists)
campaign-list List the account's campaigns — GetResponse's word for contact lists. Start here for the campaign id the contact and newsletter actions need.
Create Contact
contact-create Add a contact to a campaign. GetResponse queues the add and answers 202 — the contact may not be readable immediately, and a duplicate address is a 409.
Delete Contact
contact-delete Remove a contact, optionally recording which message and IP prompted it.
Update Contact
contact-update Update a contact's details, or move them to another campaign. Only the fields you set are changed.
List Custom Fields
custom-field-list List the account's custom fields — their id, name, type and permitted values. Read this before setting custom field values on a contact.
List From Fields
from-field-list List the account's sender addresses. Create Newsletter needs one of these ids, and only an active (verified) address can send.
Create Newsletter
newsletter-create Create and queue a broadcast newsletter to a campaign's contacts. This sends real email and cannot be undone once it starts.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying GetResponse's real ids.
{
"manifestVersion": "2",
"name": "getresponse-example",
"steps": [
{
"id": "campaign-contacts",
"uses": {
"app": "io.w6w.getresponse",
"action": "campaign-contacts",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"campaignId": "<campaignId>"
}
}
]
}Here are some of the things you can do
-
List Campaign Contacts
searchcampaign-contacts -
List Campaigns (Lists)
searchcampaign-list -
Create Contact
performcontact-create -
Get Contact
readcontact-get -
List Contacts
searchcontact-list
+9 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for GetResponse, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to GetResponse. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "contact-create",
payload: {
email: "<value>",
campaignId: "<value>",
// name: "<value>",
// dayOfCycle: "<value>",
// tags: "<value>",
// customFieldValues: "<value>",
// ipAddress: "<value>",
// scoring: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value);npm install -g @w6w/cliw6w run conn_YOUR_CONNECTION_ID --action contact-create --payload '{"email":"<value>","campaignId":"<value>"}'Give an AI agent GetResponse — without giving it GetResponse's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.getresponse#campaign-contacts",
"input": {
"campaignId": "<campaignId>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's GetResponse connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
What the agent gets
Credentials it can't read
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
A tool surface scoped to the caller
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
A durable workflow in one call
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
Health-aware discovery
GetResponse's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. GetResponse itself is MIT, and the runtime that executes it is source-available (FSL).
Health checks
GetResponse declares its own checks, so its health is a property of the app rather than something the host guesses at.
GetResponse platform status
Component status from status.getresponse.com (Atlassian Statuspage), which publishes 42 components including API, Webhooks and Contacts. It does not separate retail from MAX.