Fomo
AdvertisingPush purchase, signup, and review events into a live Fomo social proof feed and manage the templates that render them. Agents surface real activity on the site as it happens rather than on a scheduled refresh.
What This Integration Enables
Social proof notifications are only proof if the events behind them are real, and the Fomo API will accept whatever you send it. That is the whole design decision this connector puts in front of you. FlowRunner's position is that the feed should be driven by the order and signup records your business already keeps, not by a synthetic generator that happens to produce believable output, because the first version keeps its promise to visitors and the second one does not. Agents push purchase, signup and review events into the live feed the moment they happen, populate them from the source record rather than from a template of plausible-sounding activity, and remove them again when a sale reverses or a customer asks not to be named. They also provision the templates that render the messages, tune the widget's position, timing and UTM tagging, and read back impressions, clicks and conversions so the widget stops being a thing nobody has looked at since launch.
Without FlowRunner
With FlowRunner
Use Case Scenarios
The storefront drives the feed
An order is paid in Shopify or WooCommerce. Before anything reaches the widget, the agent verifies the order is settled, is not a staff or test purchase, and belongs to a customer whose record permits publicity. Only then does Create Event fire, carrying the product name, the city derived from the order IP address, and custom fields that the template turns into merge variables. Visitors see the last hour of the store rather than a loop of manufactured activity, and the store never has to argue about whether the widget is honest, because the answer is a query against the orders table.
Provisioning Fomo for many sites at once
An agency running social proof across a portfolio of client stores does not want a person clicking through the Fomo dashboard per site. The agent calls Create Template to build the notification types each client needs, referencing event attributes and the built-in title_with_link helper in the message, then calls Update Application Settings to place the widget, set how long each notification shows, cap how far back events may be pulled from, and stamp the click-throughs with the client's UTM parameters. Onboarding a new store becomes a flow run instead of a checklist, and every site ends up configured the same way.
A refund or an opt-out unwinds the notification
A refund posts in Stripe, or a preference form in Typeform records that a customer does not want to appear in marketing. The agent calls Find Event with that customer's email address or external ID, takes the numeric event ID from the match, and calls Delete Event so the notification stops appearing. The removal, the reason and the timestamp land in the same log as the publication, which is what makes the widget defensible later. Deletion stops future impressions; it does not retract the ones already served, which is exactly why the verification in Scenario 1 runs before publication rather than after.
Human-in-Loop Highlight
Create Event is the operation with no real undo. It publishes to whoever is on the site at that second, and Delete Event removes the notification afterward without unsending it. So the agent stops at the point where verification fails. When it replays historical activity, or when a batch contains refunded orders, cancelled orders, internal test purchases, customers whose record says do not use my name, or events it would have to backdate with Update Event to make them look recent, it posts one message to the store owner in Slack: "34 of 212 orders did not pass publication checks. 9 refunded, 4 test accounts, 21 opted out of publicity. Publish the 178 that passed, publish all 212, or hold the batch?" The owner answers in the channel and the flow resumes on that answer. This is the digital andon cord pointed at a marketing widget: the agent is fully capable of publishing all 212, and it deliberately will not, because the person who knows those orders is one message away. FlowRunner treats human-in-the-loop as the default on any write a customer will read, not as a setting somebody remembers to switch on.
Agent Capabilities
8 actionsEvents
5- Create Event Pushes a new notification into the live feed for the site the auth token belongs to, using the numeric template ID from the Fomo dashboard. Supplying an IP address lets Fomo derive city, province and country, and supplying an email address produces a customer avatar without the address ever being displayed. Used as the last step after an order or signup has been verified against its source record.
- Retrieve Event Fetches a single event by its numeric ID and returns the stored data along with the rendered message and click-through link its template produced. Used when a flow needs to confirm what a visitor actually saw before acting on a report or a complaint.
- Find Event Looks up an event by external ID or email address and returns the most recent match. This is how a flow gets the numeric ID that Delete Event needs, which makes it the first step in opt-out handling and in de-duplicating an import.
- Update Event Changes attributes of an existing event without recreating it, so the notification keeps its place in the live feed. Only supplied fields are sent. Setting Created At backdates a notification when replaying historical activity, which is a decision worth putting a person behind.
- Delete Event Permanently removes an event from the feed by its numeric ID so it stops appearing. Paired with Find Event, it is the mechanism behind an opt-out flow that clears every notification generated for one customer's email address.
Templates
1- Create Template Creates a notification template, which Fomo calls an event type, without touching the dashboard. This is the path for provisioning Fomo on behalf of mutual customers, and the message can reference any event attribute as a merge variable plus the built-in title_with_link helper.
Application and Reporting
2- Get Statistics Returns notification impressions, clicks and conversions for the site the auth token belongs to over a supplied date range. Used to report on what the widget is actually contributing rather than assuming it still works.
- Update Application Settings Changes how the widget behaves on the site: where notifications appear, how long each one shows, how far back events may be pulled from, and which UTM parameters get appended to click-throughs. Only supplied fields are sent, so a single setting can be adjusted without resending the whole configuration.
Frequently Asked Questions
What can FlowRunner do with Fomo?
FlowRunner agents can run Create Event, Retrieve Event, and Find Event in Fomo, plus 5 more actions.
Does connecting Fomo to FlowRunner require OAuth?
No. Fomo connects to FlowRunner with an API key, no OAuth flow required.
Can Fomo trigger a FlowRunner workflow automatically?
Fomo doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Fomo
$100 in credits. No card required. Connect in minutes.