iContact API + MCP (2026): REST v2.2, three-header auth, no MCP server

iContact exposes one JSON REST API at https://app.icontact.com/icp, pinned by an Api-Version: 2.2 header and authenticated with three custom headers rather than OAuth or HTTP Basic. It is a list-and-campaign API, contacts, lists, subscriptions, messages, sends, not a transactional relay, and there is no SMTP service behind it. As of August 2026 no iContact MCP server exists, official or community: agent access runs through Zapier MCP or a thin wrapper you write yourself.

At a glance

MCP integration in 2026

MCP is how an AI agent gets typed, permissioned access to a product’s data and actions, looking up a contact, adding someone to a list, reading campaign stats without glue code. The question buyers ask in 2026 is whether they can point an agent at their ESP and have it work. For iContact the answer is not directly.

Available MCP servers

There is no iContact entry to list, so this directory covers the routes that actually work today.

iContact API essentials

One API, one version, one base URL. Everything below is verified against iContact’s own PHP client rather than a marketing page, so the header names and paging parameters are literal.

Every data call hangs off a two-level scope: an account, then a client folder inside it. Resources fall into three groups. Audience objects, contacts, lists, subscriptions, segments, custom fields, take most integration time. Content and dispatch objects are campaigns, messages and sends: create a message, attach it to a campaign, then create a send that pushes it at lists. Reporting objects (opens, clicks, bounces, unsubscribes, statistics) are read-only. Bulk loading is its own two-step flow, create an upload job, then PUT the CSV, and is the right path above a few thousand rows.

One structural absence matters more than any feature: there is no transactional send path and no SMTP relay, so receipts and password resets need a dedicated relay such as Postmark or Amazon SES alongside iContact. AWeber and Constant Contact sit in the same marketing-only position; Brevo and Mailjet combine both in one account.

Authentication methods

iContact uses neither OAuth, bearer tokens nor HTTP Basic. It uses three custom headers, and confusing two of them is the most common cause of a day-one auth failure.

Application headers (the only method)

Every request carries Api-AppId, Api-Username and Api-Password alongside Api-Version: 2.2. The AppId identifies an application you register in the developer portal; the username is your iContact account username; the Api-Password is an application-specific password set for that app-not your web UI login password. All three are static strings: no token exchange, no refresh cycle, no expiry to handle.

Accept: application/json
Content-Type: application/json
Api-Version: 2.2
Api-AppId: your-registered-application-id
Api-Username: your-icontact-username
Api-Password: your-application-specific-password

Treat them as long-lived secrets: environment variables or a secret manager, never a client-side bundle. Key rotation is covered in Create and Manage API Keys, permissions in Permissions.

There is no OAuth flow

If you are building a multi-tenant product on iContact, design around this. No authorisation-code grant, no consent screen, no per-customer token: each customer generates their own application credentials and hands you three strings to store per tenant. Workable, but it turns onboarding from a one-click connect into a documented setup task, and revocation stays on the customer’s side. Mailchimp, HubSpot and Constant Contact offer OAuth instead.

Rate limits

iContact publishes no numeric API rate limits in any officially reachable document. What it does document in detail is how plan limits are counted, those are the ceilings that bite.

Treat throughput as something you discover, not assume: run a single writer, keep concurrency at 1 until you have measured real behaviour, and back off exponentially on the codes listed in HTTP Status Codes. For volume loads the /uploads job plus a PUT of the CSV moves tens of thousands of contacts in one request pair. The ceiling that costs money is the contact ceiling: crossing it raises the invoice rather than blocking the send.

Official SDKs

iContact’s GitHub organisation holds exactly 3 repositories. All PHP, all Apache-2.0, none touched since 2018, and two of the three target generations that are no longer the product you sign up for.

Notable community SDKs

No widely adopted third-party iContact client exists in any language, itself informative about integration volume. What exists is no-code, the official Zapier app, 8 triggers and 8 actions, the same surface Zapier MCP re-exposes, and platform plugins: iContact Lead Forms for WordPress and the iContact for Salesforce package. Beyond those you write the client, starting from the Code Library article.

Endpoints reference

Paths are relative to {scope} = https://app.icontact.com/icp/a/{accountId}/c/{clientFolderId}. Those IDs are neither optional nor inferable, fetch them first. Full documentation: the official Resource Call References List.

The official article index confirms further resource families whose exact paths were not machine-verifiable: Message Clicks, Message Bounces, Unsubscribes, Custom Fields, Contact History, Automations, Sign-Up Forms, Statistics, Users and a Time endpoint returning iContact’s server clock. Scheduled sends are evaluated against that clock, not your host’s timezone.

Code examples

Header names and paging parameters below come verbatim from iContact’s own PHP client, so they are literal rather than reconstructed. Point them at the sandbox first.

Python: create a contact, subscribe it, page the list

import os, requests

BASE = "https://app.icontact.com/icp"   # sandbox: https://app.sandbox.icontact.com/icp

s = requests.Session()
s.headers.update({
    "Accept": "application/json",
    "Content-Type": "application/json",
    "Api-Version": "2.2",
    "Api-AppId": os.environ["ICONTACT_APP_ID"],
    "Api-Username": os.environ["ICONTACT_API_USERNAME"],
    "Api-Password": os.environ["ICONTACT_API_PASSWORD"],
})

# 1. Resolve the scope every other call needs.
acct = s.get(BASE + "/a/", timeout=30).json()["accounts"][0]["accountId"]
folder = s.get("%s/a/%s/c/" % (BASE, acct), timeout=30).json()["clientfolders"][0]["clientFolderId"]
scope = "%s/a/%s/c/%s" % (BASE, acct, folder)

# 2. Create a contact. The payload is an ARRAY, even for one record.
r = s.post(scope + "/contacts", timeout=30,
           json=[{"email": "ada@example.com", "firstName": "Ada", "lastName": "Lovelace"}])
r.raise_for_status()
contact_id = r.json()["contacts"][0]["contactId"]

# 3. Subscribe that contact to a list.
s.post(scope + "/subscriptions", timeout=30,
       json=[{"contactId": contact_id,
              "listId": os.environ["ICONTACT_LIST_ID"],
              "status": "normal"}]).raise_for_status()

# 4. Page with limit/offset, sort with orderby.
page = s.get(scope + "/contacts", timeout=30,
             params={"limit": 100, "offset": 0, "orderby": "lastName:asc"}).json()
print(page["total"])

Node: create a message, then dispatch it

const BASE = "https://app.icontact.com/icp";
const headers = {
  Accept: "application/json",
  "Content-Type": "application/json",
  "Api-Version": "2.2",
  "Api-AppId": process.env.ICONTACT_APP_ID,
  "Api-Username": process.env.ICONTACT_API_USERNAME,
  "Api-Password": process.env.ICONTACT_API_PASSWORD,
};

async function call(path, init) {
  const res = await fetch(BASE + path, Object.assign({ headers }, init || {}));
  if (!res.ok) throw new Error(res.status + " " + (await res.text()));
  return res.json();
}

const acct = (await call("/a/")).accounts[0].accountId;
const folder = (await call("/a/" + acct + "/c/")).clientfolders[0].clientFolderId;
const scope = "/a/" + acct + "/c/" + folder;

// Step 1: create the message content.
const created = await call(scope + "/messages", {
  method: "POST",
  body: JSON.stringify([{
    campaignId: process.env.ICONTACT_CAMPAIGN_ID,
    subject: "Monthly product update",
    htmlBody: "<h1>Hello</h1>",
    textBody: "Hello",
  }]),
});

// Step 2: dispatch it. The /sends payload fields (message id, target lists,
// schedule) are defined in the official Sends article - confirm the key names
// there before hard-coding them. There is no SMTP path: iContact has no relay.
await call(scope + "/sends", { method: "POST", body: JSON.stringify([sendPayload]) });

Common gotchas

Deprecations and changelog

• August 19, 2026-API and MCP surface inventoried for this review. No iContact MCP server in the official GitHub organisation or the public MCP ecosystem; REST v2.2 confirmed as the only current generation.
• March 12, 2018-final commit to icontact-pro-api-php, closing out the api.icpro.co Pro generation. The newest commit anywhere in the organisation.
• January 2, 2018-final commit to icontact-api-php, the official SDK for the current app.icontact.com/icp API v2.2. No official SDK release since.
• October 28, 2014-final commit to icontact-pro-select-api-php. The OutMarket-era api.omkt.co generation is dormant and should be treated as retired.
• Undated-iContact for Salesforce reached v2.4 (Lightning) and v2.4.3 (Classic) per the official upgrade articles; no release dates are published.

The official version history lives at API Version Changelog; new integrations start at the API Getting Started Guide. Check both before assuming anything here is still current.

Frequently asked questions