--- title: "Optimizely Campaign Integration" description: "Manage recipients and mailings through the Optimizely Campaign REST API, covering recipient lists and Smart Campaigns. Agents keep the audience current and trigger sends off events in the systems of record." url: https://flowrunner.ai/integrations/optimizely-campaign date_modified: 2026-08-07T17:20:23-07:00 --- # Optimizely Campaign [Email Marketing](https://flowrunner.ai/integrations/category/email-marketing) Manage recipients and mailings through the Optimizely Campaign REST API, covering recipient lists and Smart Campaigns. Agents keep the audience current and trigger sends off events in the systems of record. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 30 actions · Basic auth · available [Optimizely Campaign website](https://broadmail.de/) · [Platform Documentation](https://api.broadmail.de/apidoc/index.html) · Capability data verified 2026-08-12 1. A CRM contact reaches the subscribed lifecycle stage during the nightly sync 2. Get Recipient List Fields returns the attribute keys the target list actually accepts 3. Create Recipient adds the person with attributes mapped to those keys and the opt-in process attached 4. Get Recipient Opt-In Status reports whether the double opt-in has been confirmed yet 5. Update Recipient appends the acquisition source to the tracking attribute instead of replacing it 6. Recipients still sitting unconfirmed are grouped into a single daily digest rather than alerted one by one 7. The marketing owner decides whether the unconfirmed cohort waits, gets a reminder, or is dropped ## What This Integration Enables Optimizely Campaign is enterprise email infrastructure with a long European history, and it still answers on the Broadmail host its documentation lives at. That heritage shows in the shape of the API, and the shape is the reason to build an agent against it: consent is not a boolean on the contact. Unsubscribes, blocklist patterns, opt-in process state and delivery responses are four separate objects with their own operations. Deleting a recipient does not make them contactable again, because their suppression record was never stored on the recipient in the first place. The connector exposes all four surfaces, plus recipient lists, Smart Campaigns, transactional mailings and webhook registration. Two operational details shape how workflows get built against it. Every request carries a Client ID as its first path segment, so a single FlowRunner account can address several Campaign clients without ambiguity about which one a write landed in. And recipient attributes expand into the list's own data fields, which means Get Recipient List Fields is not an optional discovery call, it is the thing that keeps an import honest when a list's schema changes underneath a workflow. Agents can do the sync, the sizing, the reporting and the suppression mirroring. The decisions that change whether a person may be mailed stay with people. ### Without FlowRunner **Attribute keys guessed from memory**: Imports fail or silently drop values because the list defines different fields than the mapping assumes **Opt-in state checked after the send**: Unconfirmed contacts get mailed, and the problem surfaces as a complaint **Suppression lists diverge**: Campaign knows about an unsubscribe that the CRM and the warehouse never hear about ### With FlowRunner **Field definitions read first**: The list's own field definitions drive the mapping, so a schema change is caught on the next run **Opt-in state checked before the send**: Confirmation status is part of the mailability decision, not a post-mortem finding **One suppression truth**: Unsubscribes, blocklist patterns and hard bounces are mirrored outward so every system honours them ## Use Case Scenarios ### Keeping a recipient list in step with the CRM Subscriber attributes live in [Salesforce](https://flowrunner.ai/integrations/salesforce-pro) or [HubSpot](https://flowrunner.ai/integrations/hubspot) and get stale in Campaign within days. The agent reads Get Recipient List Fields to learn what the list will accept, then writes each subscriber through Create Recipient with an opt-in process ID so the double opt-in mail actually goes out, or without one where the consent was captured elsewhere and documented. Attribute changes flow through Update Recipient, which can append to a string attribute rather than overwriting it, so an acquisition source accumulates on the profile instead of the last touch erasing the first. Count Recipients gives the audience size for reporting without exporting anything. ### Transactional mail that is monitored like infrastructure Receipts and password resets run through List Transactional Mailings and Send Transactional Mail, with personalisation passed as recipient data that matches the fields defined on the transactional list. Because these messages are load-bearing, the agent pulls Get Transactional Mail Report on a schedule and watches the bounce figure. A bounce spike on a password reset mailing is almost never a content problem, it is a data or DNS problem, so the agent routes it to the platform team in [Slack](https://flowrunner.ai/integrations/slack) with the report attached rather than filing it as a marketing metric. ### Mirroring suppression outward so every system agrees Campaign holds the authoritative record of who opted out, but the CRM, the warehouse and any second sending tool do not read it. On a schedule, the agent pulls List Unsubscribes, List Blocklist Entries and List Responses filtered to hard bounces, and writes them into [Snowflake](https://flowrunner.ai/integrations/snowflake) so downstream segmentation stops building audiences that include people Campaign will refuse to mail. Delete Recipients with a removal type handles the reverse direction, clearing bounced or unsubscribed records out of the list as periodic hygiene rather than enumerating identifiers one at a time. ## Human-in-Loop Highlight Delete Unsubscribes takes people off the internal unsubscribe list and makes them contactable again. It is the only operation in this connector that turns a recorded no back into a maybe, and an agent is exactly the wrong thing to be making that judgement, because the evidence it would need is not in Campaign. Optimizely's own documentation is clear that opt-out records are stored separately from the recipient precisely so a data cleanup cannot quietly undo them, and whether a claimed re-consent is a documented re-consent is a question for the people who own that policy, not for a workflow. So the agent does the part it is good at. It reads the current suppression record with List Unsubscribes, checks where the person stands with Get Recipient Opt-In Status, pulls the re-consent evidence the upstream system attached, and stops. It posts to the compliance queue: "Data cleanup proposes removing 214 addresses from the internal unsubscribe list. 190 carry a re-consent record with a timestamp and a source; 24 carry none. Approve the 190, approve all, or reject?" A compliance owner answers, and only the approved set reaches Delete Unsubscribes. That is [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) doing its actual job: the agent assembled a case that would have taken a person a day, and then handed over the one decision that carries the risk. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 30 actions ### Recipient Lists 3 - **List Recipient Lists** Returns the recipient lists configured on the client, the containers that hold all subscriber data. Agents call it to resolve a list name into the numeric ID every recipient operation requires. - **Get Recipient List** Retrieves one recipient list with its configuration. Used to confirm a list still exists and which opt-in process is attached before pushing subscribers into it. - **Get Recipient List Fields** Returns the attribute names and types a list will accept. This is the discovery call that keeps an import from silently dropping values when the list schema changes. ### Recipients 8 - **List Recipients** Returns the recipients in a list, optionally restricted to a target group and enriched with opt-in data. Naming only the attributes the workflow needs keeps large exports affordable. - **Count Recipients** Returns the number of recipients in a list or target group. Used for audience reporting and as a cheap guard before an expensive export runs. - **Get Recipient** Retrieves one recipient with the requested attributes and optionally their opt-in record. The recipient ID is normally the email address unless the list is configured with a different ID field, in which case the address is sent too. - **Create Recipient** Adds a recipient with their attribute values. Supplying an opt-in process ID runs that process and sends the double opt-in confirmation; omitting it adds the person directly, which is a consent decision rather than a technical one. - **Update Recipient** Updates a recipient's attribute values, with string attributes able to be overwritten, prepended to or appended to. Appending is how tracking values accumulate on a profile instead of each write erasing the last. - **Delete Recipient** Removes a single recipient from a list. Their unsubscribe and blocklist records live separately, so this does not make an opted-out person contactable again. - **Delete Recipients** Removes several recipients at once, or clears everyone in a given removal state such as bounced or unsubscribed. This is the operation periodic list hygiene should use. - **Get Recipient Opt-In Status** Reports where a recipient stands in a list's opt-in process. Checking it before mailing someone imported from another system is how an unconfirmed double opt-in gets caught before a send rather than after. ### Campaigns 4 - **List Smart Campaigns** Returns the Smart Campaigns on the client with status and schedule, optionally limited to a date window or folder. The detailed view returns full node configuration when a workflow needs more than a summary row. - **Start Smart Campaign** Activates a Smart Campaign so it begins processing recipients through its nodes. This sends live mail, so content and target groups belong in a check step ahead of it. - **Stop Smart Campaign** Halts a running Smart Campaign so no further messages are dispatched. This is the kill switch an incident workflow reaches for when a data problem is found mid-send. - **Get Smart Campaign Report** Returns sends, opens, clicks, bounces and unsubscribes for a Smart Campaign. This is the figure set that belongs in a warehouse or a weekly digest rather than a screenshot. ### Transactional Mail 3 - **List Transactional Mailings** Returns the transactional mailings configured on the client, the templates behind receipts, password resets and other triggered messages. Used to resolve a mailing name into the ID a send needs. - **Send Transactional Mail** Sends one transactional message to a single recipient, adding them to the transactional recipient list on the way through. Personalisation values are passed as recipient data and must match the fields defined on that list. - **Get Transactional Mail Report** Returns delivery and engagement figures for a transactional mailing. Monitored on a schedule, it turns a receipt deliverability problem into an alert rather than a support ticket trend. ### Suppression 6 - **List Unsubscribes** Returns the entries on the internal unsubscribe list, optionally narrowed by list, recipient or delivery channel. Mirroring this outward is what stops other systems building audiences Campaign will refuse to mail. - **Create Unsubscribes** Adds recipients to the internal unsubscribe list so Campaign stops mailing them. People are identified either by recipient ID or by the mail ID of the message they opted out from, one or the other. - **Delete Unsubscribes** Removes recipients from the internal unsubscribe list, making them contactable again. This reverses a recorded opt-out, which is why it belongs behind a human decision rather than inside an automated cleanup. - **List Blocklist Entries** Returns the client's blocklist patterns, which suppress whole addresses or domains across every mailing. This is typically where competitor domains and role accounts are excluded. - **Create Blocklist Entry** Adds a blocklist pattern so matching addresses are suppressed everywhere. Wildcards match several characters or exactly one, and either can be escaped to match literally. - **Delete Blocklist Entries** Removes patterns from the blocklist, making matching addresses contactable again. The exact stored pattern strings must be sent, not the addresses they matched. ### Deliverability 1 - **List Responses** Returns the delivery responses recorded for recipients in a given category, such as hard bounces or auto-responders. Feeding hard bounces into upstream suppression stops bad addresses being retried by systems that never saw the bounce. ### Webhooks 5 - **List Webhooks** Returns the webhooks registered on the client with event type, target URL, authentication mode and status. Used to audit which external systems are receiving Campaign event data. - **Create Webhook** Registers a webhook that posts JSON event data to an endpoint when the chosen event occurs. The target must accept HTTPS POST from Optimizely's sending address, and the authentication mode is declared as part of the registration. - **Activate Webhook** Switches a registered webhook on so it starts delivering events. New webhooks are created inactive, so this is the second half of setting one up and a common cause of a webhook that appears to do nothing. - **Deactivate Webhook** Switches a webhook off without deleting it, so deliveries stop while the configuration is kept. Used while a receiving endpoint is under maintenance. - **Delete Webhook** Permanently removes a webhook registration. Deactivation is the right call when the pause is temporary. ## Frequently Asked Questions ### What can FlowRunner do with Optimizely Campaign? FlowRunner agents can run List Recipient Lists, Get Recipient List, and Get Recipient List Fields in Optimizely Campaign, plus 27 more actions. ### Does connecting Optimizely Campaign to FlowRunner require OAuth? No. Optimizely Campaign connects to FlowRunner with basic authentication (a username and password), no OAuth flow required. ### Can Optimizely Campaign trigger a FlowRunner workflow automatically? Optimizely Campaign doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Optimizely Campaign?** This integration exposes Optimizely Campaign to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/optimizely-campaign. Site index: https://flowrunner.ai/llms.txt