Connect iPost to Claude: Manage Journeys, DataTables & Segments

If you need to connect iPost to Claude to automate marketing campaigns, synchronize DataTables, or enroll contacts into complex Journey Automations, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's tool calls and the underlying iPost REST API. You can either build, host, and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses ChatGPT, check out our guide on connecting iPost to ChatGPT or explore our broader architectural overview on connecting iPost to AI Agents.

Giving a Large Language Model (LLM) read and write access to an enterprise email service provider (ESP) like iPost is a massive engineering challenge. You are not just dealing with basic CRUD operations. You have to handle encrypted tracking tokens, highly dynamic custom data schemas (DataTables), and specific payload structures for campaign enrollment. Every time iPost updates an endpoint, you have to update your server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for iPost, connect it natively to Claude Desktop or enterprise AI agents, and execute complex marketing workflows using natural language.

The Engineering Reality of the iPost API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools using JSON-RPC, the reality of implementing it against iPost's specific API design is painful.

If you decide to build a custom MCP server for iPost, you own the entire API lifecycle. You are responsible for translating generic LLM requests into the exact, idiosyncratic formats the iPost API expects. Here are the specific challenges you will face when mapping iPost to AI agents:

Encrypted Tracking Tokens (The "Blob") iPost relies heavily on an encrypted tracking token known as the "blob". This token encodes a contact's identity and is optionally appended to tracked URLs in iPost mailings. When an agent needs to retrieve or update a contact based on a click event, it must interact with endpoints that specifically handle these blobs (like get_single_i_post_contacts_blob_by_id). LLMs cannot read or decode these strings. If you expose raw tracking URLs to an LLM, it will often attempt to parse or mutate the token, instantly invalidating it. Your MCP server must treat these as immutable, opaque identifiers.

Implicit Status Booleans and iTL Overrides The iPost contact model uses a unique approach to subscription statuses. Fields like GlobalEmailStatus and GlobalMobileStatus are assumed to be true when their corresponding Email or Mobile fields are present in a payload, and they are completely ignored when those fields are absent. If an LLM explicitly passes null or false when trying to update a separate property, it can inadvertently opt-out a user. Furthermore, Journey Automations rely on a Properties object to supply iTL template variable values for email assembly. This object overrides matching contact profile fields temporarily for that campaign. Prompting an LLM to consistently generate this nested override logic requires perfectly structured JSON Schemas in your tool definitions.

Dynamic DataTable Schemas DataTables in iPost are highly dynamic custom databases. They do not have fixed endpoints or standard JSON structures. Instead, records are arrays of user-defined attributes mapped to specific columns. To let Claude update a DataTable, your custom server has to first fetch the DataTable's attribute schema, dynamically generate a JSON Schema for the LLM to understand what columns exist, and then accept the LLM's payload to execute the bulk update. Hardcoding this is impossible for dynamic enterprise environments.

Strict Rate Limits and Normalization iPost enforces strict API quotas to ensure deliverability performance. If your AI agent gets stuck in a loop and fires hundreds of list queries, iPost will return HTTP 429 Too Many Requests errors. Note on how Truto handles this: Truto does not retry, throttle, or apply backoff on rate limit errors. When an upstream API returns HTTP 429, Truto passes that error directly to the caller. However, Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The caller (or the agent framework) is responsible for implementing retry logic and backoff. Do not rely on the MCP layer to absorb these errors.

Instead of building all this boilerplate from scratch, you can use Truto. Truto normalizes the authentication and schema generation, exposing iPost's endpoints as ready-to-use, dynamically generated MCP tools.

How to Generate an iPost MCP Server with Truto

Truto automatically generates MCP tools dynamically from the underlying iPost API documentation and integration configurations. A tool only appears in the MCP server if it has a corresponding documentation entry, ensuring the LLM only accesses curated, well-described endpoints.

Every MCP server is scoped to a single integrated iPost account and authenticated via a secure, randomly generated hex token that acts as the routing key. You can generate this server via the Truto UI or programmatically via the API.

Method 1: Generating the MCP Server via the Truto UI

For ad-hoc agent workflows or local Claude Desktop usage, generating the server URL from the dashboard is the fastest path.

1. Log into your Truto dashboard and navigate to the integrated account page for your specific iPost connection.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Select your desired configuration (e.g., restrict to specific methods like read or apply tag filters).
5. Copy the generated MCP server URL. (e.g., https://api.truto.one/mcp/a1b2c3d4e5f6...)

Method 2: Generating the MCP Server via the API

For automated workflows, you can provision an MCP server for a specific iPost tenant programmatically. The Truto API validates the configuration, generates the secure token, and returns a ready-to-use URL.

Submit a POST request to /integrated-account/:id/mcp:

// POST https://api.truto.one/integrated-account/{ipost_account_id}/mcp
// Authorization: Bearer {truto_api_token}
 
{
  "name": "Claude iPost Marketing Automation Server",
  "config": {
    "methods": ["read", "write", "custom"],
    "tags": ["journeys", "contacts", "datatables"]
  },
  "expires_at": null
}

The response contains the exact URL you will provide to your MCP client:

{
  "id": "mcp_srv_987654321",
  "name": "Claude iPost Marketing Automation Server",
  "config": {
    "methods": ["read", "write", "custom"],
    "tags": ["journeys", "contacts", "datatables"]
  },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/abc123def456..."
}

This single URL contains everything needed to authenticate and route tool calls directly to the specified iPost account.

Connecting the iPost MCP Server to Claude

Once you have your Truto MCP server URL, you must configure your LLM client to discover its tools. The MCP server handles the initialize and tools/list JSON-RPC handshake automatically.

Method A: Via the Claude UI (Desktop/Web)

If you are using Anthropic's official Claude clients with Custom Connector support:

1. Open your Claude settings.
2. Navigate to Integrations or Connectors.
3. Click Add MCP Server or Add Custom Connector.
4. Paste the Truto MCP URL (https://api.truto.one/mcp/...) and click Add.
5. Claude will immediately query the endpoint to list available iPost tools and cache their JSON Schemas.

Method B: Via Manual Config File (Claude Desktop)

If you prefer to configure Claude Desktop manually via its configuration file, you need to use the official SSE transport bridge provided by the MCP project. Truto's servers are HTTP-based SSE endpoints, so you use the server-sse module to connect.

Open your claude_desktop_config.json file (located in ~/Library/Application Support/Claude/ on macOS or %APPDATA%\Claude\ on Windows) and add the following entry:

{
  "mcpServers": {
    "ipost_marketing": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/abc123def456..."
      ]
    }
  }
}

Restart Claude Desktop. When it boots, it will execute the npx command, connect to the Truto server via Server-Sent Events, and load the iPost tool inventory.

Hero Tools for iPost Automation

Truto maps iPost's extensive endpoints into discrete, descriptive tools. Tool names are generated dynamically (e.g., list_all_i_post_contacts), and the schemas dictate exactly which arguments belong to the query parameters versus the request body.

Here are 6 high-leverage hero tools for automating iPost with Claude.

list_all_i_post_contacts

Retrieve up to 10,000 contact records from a specific iPost list. This is essential for auditing list membership or preparing bulk data extraction workflows.

Contextual Usage: Always require Claude to specify the list_id. If pagination is required, Claude must pass back the exact cursor token it receives.

"Fetch all the contacts currently subscribed to list ID 90210. Format the output to show their Contact ID, Email, and GlobalEmailStatus."

create_a_i_post_journey_automation

This tool adds contacts to an iPost Journey Automation to enroll them in a sequence. You can enroll existing contacts via Contact_ID or new contacts via Email.

Contextual Usage: This is where the Properties object comes in. Instruct Claude to populate the Properties object with key-value pairs if you need iTL variable substitutions for the specific email content used in the journey.

"Enroll contact ID 55432 into Journey Automation ID 887. Inject a property called 'DiscountCode' with the value 'WELCOME20' so the journey template can render it."

i_post_datatable_records_bulk_update

Add or update records in a dynamic iPost DataTable. This tool accepts a JSON body with record data whose fields correspond strictly to the user-defined columns of the specified DataTable.

Contextual Usage: Before calling this, Claude usually needs to call get_single_i_post_data_table_attribute_by_id to understand what the dynamic columns actually are.

"Update DataTable ID 445 with these three recent purchase records. Map the purchase totals to the 'Lifetime_Value' attribute column."

get_single_i_post_contacts_blob_by_id

Retrieve an iPost contact using the "blob" - the encrypted tracking token appended to tracked links in mailings.

Contextual Usage: Use this to identify exactly who clicked a link in a campaign without requiring them to log in or provide their email address. Pass the raw blob string exactly as it appears in the URL.

"A user clicked a tracked link with the blob 'xyz123encBlobData'. Look up this blob and tell me the associated contact's email address and profile properties."

update_a_i_post_contact_by_id

Update an existing iPost contact's core information.

Contextual Usage: Warn the LLM about the implicit booleans. If Email or Mobile is present, the corresponding Global status becomes true. If the LLM is just trying to update a custom property, it should omit those fields unless it intends to reset the subscription status.

"Update contact ID 99887 to change their custom field 'LoyaltyTier' to 'Platinum'. Do not alter their email address or subscription status."

create_a_i_post_process_automations_start

Initiates a Process Automation in iPost. The automation must be in an 'active' state; if it is stopped, draft, or paused, the API will reject the execution.

Contextual Usage: Use this to trigger heavy background jobs like data imports or batch processing that have already been configured in the iPost UI.

"Start the daily sync Process Automation with ID 102. Check the response to ensure it executed successfully."

For the complete tool inventory and granular JSON schemas, refer to the iPost Integration Page.

Workflows in Action

Individual tools are useful, but MCP servers unlock their true power when Claude strings them together into agentic workflows. Here are two real-world examples of how AI agents execute multi-step iPost operations.

Scenario 1: Resolving a Click and Enrolling in a Journey

A marketer wants to automatically funnel anonymous click traffic from a specific campaign into a targeted onboarding journey based on their encrypted blob token.

"A user clicked the upgrade link in our newsletter. The URL contained the blob 'encAbc890XYZ'. Find out who this contact is, and immediately enroll them into the 'Premium Upgrade Onboarding' journey (Journey ID 412)."

Step-by-step execution:

1. Claude calls get_single_i_post_contacts_blob_by_id passing the blob string.
2. The Truto MCP server queries the iPost API and returns the exact Contact_ID and Email.
3. Claude parses the contact information.
4. Claude calls create_a_i_post_journey_automation using the retrieved Contact_ID and the provided journey_id (412) to initiate the enrollment.

sequenceDiagram
    participant User as User Prompt
    participant Claude as Claude Agent
    participant Truto as Truto MCP Server
    participant iPost as iPost API

    User->>Claude: "Find contact for blob 'encAbc890XYZ' and enroll in Journey 412"
    Claude->>Truto: Call get_single_i_post_contacts_blob_by_id<br>{"id": "encAbc890XYZ"}
    Truto->>iPost: GET /api/contacts/blob/encAbc890XYZ
    iPost-->>Truto: Return Contact_ID 7765
    Truto-->>Claude: JSON Result (Contact_ID 7765)
    
    Claude->>Truto: Call create_a_i_post_journey_automation<br>{"journey_id": 412, "Recipients": [{"Contact_ID": 7765}]}
    Truto->>iPost: POST /api/journeys/412/enroll
    iPost-->>Truto: 204 No Content
    Truto-->>Claude: Success Confirmation
    Claude-->>User: "Contact 7765 successfully identified and enrolled in Journey 412."

Scenario 2: Synchronizing External BI Data to DataTables

A data analyst needs to push calculated lead scores from their local environment into a dynamic iPost DataTable so the marketing team can build segmentation rules off the new scores.

"I have a list of three users with new lead scores. User A (ID 10) scored 85. User B (ID 11) scored 92. Fetch the schema for DataTable ID 55 to find the correct column name for lead scores, then bulk update those records."

Step-by-step execution:

1. Claude calls get_single_i_post_data_table_attribute_by_id passing id: 55.
2. Truto returns the DataTable schema, revealing that the custom attribute key is actually lead_score_v2.
3. Claude formats a bulk update JSON payload mapping the user IDs to the lead_score_v2 attribute.
4. Claude calls i_post_datatable_records_bulk_update with the payload.
5. The iPost API updates the custom table.

flowchart TD
    A["Claude receives<br>lead score data"] --> B["Call get_single_i_post_data_table_attribute_by_id<br>for Table 55"]
    B --> C["Extract dynamic column key<br>(lead_score_v2)"]
    C --> D["Format JSON payload<br>mapping scores to column"]
    D --> E["Call i_post_datatable_records_bulk_update"]
    E --> F["Truto executes POST<br>Data successfully synced"]

Security and Access Control

Exposing an enterprise ESP to an autonomous agent carries inherent risks. Truto provides several mechanisms to lock down your iPost MCP servers at the infrastructure layer.

• Method Filtering: When generating the server via the API or UI, you can restrict the token to specific operations. Passing "methods": ["read"] ensures the agent can only call get and list tools. It cannot execute Journey enrollments or update DataTables, completely removing the risk of accidental bulk mutations.
• Tag Filtering: Limit the server's scope to specific functional areas. By filtering for the contacts tag, the MCP server will omit all tools related to DataTables, Process Automations, or Lists.
• Require API Token Authentication: For highly sensitive setups where the MCP URL might be exposed in logs, setting require_api_token_auth: true forces the connecting client to pass a valid Truto API token in the Authorization header. URL possession alone becomes insufficient.
• Automatic Expiration: You can set an expires_at timestamp when creating the server. Truto's background alarm handlers will automatically purge the database record and invalidate the KV store entries the moment the timestamp is reached. This is perfect for granting temporary agent access for a specific batch job.

Moving Forward with Agentic Marketing

Connecting iPost to Claude via a managed MCP server removes the heavy lifting of API maintenance. By letting Truto handle the schema generation, blob token routing, and rate limit normalization, your engineering team can focus on designing complex, agentic marketing workflows rather than writing endless JSON parsing logic. Whether you are bulk updating DataTables or orchestrating dynamic Journey enrollments, the combination of Claude's reasoning and Truto's infrastructure provides an immediate operational advantage.