--- title: "CrowdPower Integration" description: "Feed customer identification and behavioral data into CrowdPower through the Beacon API. Agents keep lifecycle campaigns triggered by what customers actually did rather than by a nightly export." url: https://flowrunner.ai/integrations/crowdpower date_modified: 2026-08-07T17:20:23-07:00 --- # CrowdPower [Email Marketing](https://flowrunner.ai/integrations/category/email-marketing) Feed customer identification and behavioral data into CrowdPower through the Beacon API. Agents keep lifecycle campaigns triggered by what customers actually did rather than by a nightly export. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 9 actions · API key · available [CrowdPower website](https://crowdpower.io/) · [Platform Documentation](https://docs.crowdpower.io/getting-started/beacon-api) · Capability data verified 2026-08-04 1. A migration job finishes loading two years of historical activity into the product database 2. Agent reads the customer records, their events and their charges from the source 3. Agent confirms every record carries a user ID or an email so no profile is created blind 4. Agent groups the events by date and finds that most of them predate the current live window 5. Agent posts the record count, the event date range and the event types involved to the lifecycle channel 6. Lifecycle owner confirms which automations are paused before the agent runs the bulk load ## What This Integration Enables CrowdPower is not a place you send from. It is a place you tell the truth about your customers, and everything downstream of that truth is CrowdPower's own automation engine. The Beacon API is write-only by design: there are no list endpoints, no read endpoints and no webhooks, so this connector ships no pickers and no triggers. That is not a limitation to work around, it is the shape of the product. Your systems know what happened. CrowdPower needs to be told. FlowRunner's job here is the pipe, and it is a better pipe than a nightly export because it can be event-shaped. An agent can call Identify Customer the moment a profile trait changes, Create Customer Event when someone activates a feature, and Create Customer Charge when a payment settles, so segments stay accurate against what people actually did rather than against a snapshot taken at 2am. Every operation has a bulk variant for the cases where volume matters, and Track Customers folds profile, events, charges and tags into one atomic call so a full activity snapshot cannot land half-applied. The write-only shape has one consequence worth stating plainly: an agent cannot read back which automations are currently armed, which is exactly why the bulk paths need a person in front of them. ### Without FlowRunner **Lifecycle data arrives on a delay**: Automations fire against whatever last night's export happened to contain **Four calls per customer**: Profile, events, charges and tags each go in separately and can land out of order **Backfills are done blind**: A history import goes in with no advance view of what it will set off ### With FlowRunner **Behavior arrives as it happens**: A signup, an upgrade or a feature activation reaches CrowdPower as its own event **One atomic snapshot**: Profile traits, events, charges and tags land together in a single call **Backfills get reviewed first**: The scale and the date range of a replay are put in front of a person before the write runs ## Use Case Scenarios ### Product behavior as it happens A user upgrades their plan. The payment settles in [Stripe](https://flowrunner.ai/integrations/stripe), and the agent handles the whole consequence in one flow: Identify Customer to merge the new plan tier and seat count into the profile, Create Customer Charge with the amount in the smallest currency unit so lifetime spend stays correct, and Create Customer Tag to move them out of the trial cohort. CrowdPower's revenue segments and spend-based automations react to a customer who upgraded eleven seconds ago, not to one who upgraded sometime yesterday. ### Enrichment from a system CrowdPower never sees A support conversation in [Intercom](https://flowrunner.ai/integrations/intercom) is resolved with a churn-risk sentiment. The agent does not need CrowdPower to know anything about the support desk. It calls Create Customer Tag to mark the person as a churn risk and Create Customer Event to record the interaction on their timeline with the ticket reference in the properties. A save campaign built on that tag now fires on evidence that came from a system with no CrowdPower integration at all, because the agent carried it across. ### A full snapshot in one call An overnight reconciliation compares the product database in [PostgreSQL](https://flowrunner.ai/integrations/postgresql) against what was last sent. For each customer whose state has drifted, the agent assembles the corrected profile traits, the missed events, any unrecorded charges and the current tag set, then sends the whole thing with Track Customers. One request per customer, applied atomically, instead of four requests that can succeed in part and leave a profile describing a person who does not exist. ## Human-in-Loop Highlight The gate is on the bulk write, and the reason is specific to how CrowdPower works. Events are the primary trigger source for its lifecycle automations, and Create Customer Events In Bulk is the tool for replaying history. Put those two facts together and a data backfill becomes a mass send: import two years of upgrade events and every automation armed on an upgrade fires, retroactively, for thousands of people who upgraded in 2024 and will be extremely confused to receive a congratulations email about it this morning. The agent cannot check for this on its own, because the Beacon API is write-only and offers no way to ask which automations are live. So it stops and asks the only party who knows: "Ready to load 41,200 customers and 380,000 events dated between March 2024 and today via Identify Customers In Bulk and Create Customer Events In Bulk. Event types include upgraded, invited\_teammate and activated\_feature. Confirm the automations on those event types are paused, or tell me to hold." That is [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) placed where the platform's own design makes it necessary, not bolted on for form. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via email Human decides Agent resumes with decision ## Agent Capabilities 9 actions ### Customer Profiles 2 - **Identify Customer** Creates a customer record in CrowdPower or updates an existing one, matching on the supplied user ID or email address. Used whenever someone signs up, changes a profile trait, or is enriched from another system. Custom attributes merge into the existing profile rather than replacing it, so a flow can send only the fields it actually knows about. - **Identify Customers In Bulk** Creates or updates many profiles in one request. Used to backfill an existing user base or to replay a sync without issuing a call per record. Every entry needs a user ID or an email address, and user ID wins when both are present. ### Behavioral Events 2 - **Create Customer Event** Records a behavioral event on a customer's timeline, registering the event type on the project automatically the first time it appears. Used for the meaningful moments that should drive a campaign: an upgrade, an invite, a feature activation, a plan downgrade. - **Create Customer Events In Bulk** Records several events for one customer in a single request, each keeping its own action, properties and timestamp. Used to replay historical activity or to flush a buffered queue. This is the operation that makes armed automations fire retroactively, which is why it belongs behind a review step. ### Revenue 2 - **Create Customer Charge** Records a payment against a customer and rolls it into their lifetime charge summary, which powers revenue segments and spend-based automations. Amounts go in the smallest currency unit, so a 49.00 USD payment is sent as 4900. - **Create Customer Charges In Bulk** Records several charges for one customer in one request, each with its own amount and optional timestamp. Used to import billing history from a payment processor or an internal ledger without one call per invoice. ### Tags 2 - **Create Customer Tag** Applies a tag to a customer, creating the tag on the project automatically when the name is new. Used to mark cohorts such as trial users, churn risks or webinar attendees so automations can branch on membership. - **Create Customer Tags In Bulk** Applies several tags to one customer in one request, creating any names that do not exist yet. Used when a segmentation job assigns multiple labels at once. ### Combined Write 1 - **Track Customers** Creates or updates customers and attaches their events, charges and tags in one combined call, so a whole activity snapshot lands atomically rather than across four separate requests. Used for reconciliation runs and for any flow where a partially applied profile would be worse than no update at all. ## Frequently Asked Questions ### What can FlowRunner do with CrowdPower? FlowRunner agents can run Identify Customer, Identify Customers In Bulk, and Create Customer Event in CrowdPower, plus 6 more actions. ### Does connecting CrowdPower to FlowRunner require OAuth? No. CrowdPower connects to FlowRunner with an API key, no OAuth flow required. ### Can CrowdPower trigger a FlowRunner workflow automatically? CrowdPower doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at CrowdPower?** This integration exposes CrowdPower 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/crowdpower. Site index: https://flowrunner.ai/llms.txt