Simvoly

Connect AI agents to Simvoly, a website and funnel builder with a built-in store, memberships, and email lists. Agents manage contacts, members, products, and orders, read form submissions and bookings, and maintain subscriber lists so funnel data flows straight into the rest of the stack.

Verified 38 actions API key available

Simvoly website ↗ Platform Documentation ↗ Capability data verified 2026-08-10

A schedule opens the fulfillment run, because Simvoly manages webhook subscriptions as ordinary actions rather than as a FlowRunner trigger, since the vendor publishes no fixed payload schema

List Orders returns the orders placed since the last run, each with its buyer and its line items

Search Contact By Email decides whether this buyer is already known to the site or is arriving for the first time

Create Or Update Contact upserts the buyer with the tags, custom properties, and subscriber lists the purchase implies

Get Product confirms which purchased items are membership products and which member groups each one grants

Create Member adds the buyer to the membership area with those groups, with no password supplied so Simvoly sends its own reset email

Any request to mint a sign-in link with Start Member Session goes to a named owner before a link exists

What This Integration Enables

Simvoly's proposition is that the site, the funnel, the store, the membership area, and the email list are one product rather than five you have to wire together. That is a real position, and it has a consequence worth stating plainly: one API key reaches all of it. This connector exposes 38 actions across contacts, members, member groups, products, orders, form submissions, bookings, subscriber lists, site analytics, and webhook subscriptions, all against your own site domain. An agent operating here is not touching a marketing surface. It is touching the customer record, the entitlement, the catalog, and the money in the same connection.

The customer side is the richest part. Contacts carry tags, custom properties, and subscriber list membership, and Create Or Update Contact upserts on email, which is the correct primitive for keeping a site list synchronized with a system of record without creating duplicates. Members are separate from contacts and are the paid-access identity: Create Member takes groups and an approval state, and omitting the password makes Simvoly send its own reset email rather than putting you in the business of transmitting credentials. Member groups are fully manageable here, meaning a flow can create and retire access tiers rather than only assigning existing ones. Start Member Session sits at the end of that list and does something categorically different from everything around it, which the human-in-loop section below covers on its own.

The commercial side is broad and mostly straightforward. Products can be created and updated across physical, digital, service, and membership types with images and categories. Orders can be read and updated, and Update Order is the meaningful write: it changes status, marks an order paid, records payment details, and attaches fulfillment tracking. Form submissions and bookings are read-only lists with date filters, which makes them clean inputs for routing rather than surfaces to write back to. Subscriber lists are fully managed. Get Website Stats returns hourly, daily, referrer, device, browser, or usage metrics for a date range. Webhook management is present as actions rather than as triggers, deliberately: Simvoly lets you subscribe a URL to store and contact events, but does not publish a fixed payload schema, so a flow subscribes a FlowRunner endpoint with Create Webhook and handles what arrives rather than pretending the shape is guaranteed.

Without FlowRunner

Purchase and access are separate chores Someone reads the order list and adds members to groups by hand, usually a day late

Three records for one person drift apart A buyer exists as a contact, a member, and a subscriber, each maintained in a different screen

Support access is improvised Helping a locked-out customer means resetting their password or asking them to read their screen out loud

With FlowRunner

Access follows the order Create Member runs off the order record with the groups the purchased product actually grants

One run maintains all three records Contact, member, and subscriber list stay consistent because a single flow writes them together

Support access is an approved, recorded act A sign-in link is minted only when a person authorizes it, and the request and the approval are both logged

Use Case Scenarios

A purchase that provisions itself

The fulfillment run reads List Orders for everything since the last pass. For each order the agent calls Search Contact By Email, then Create Or Update Contact so the buyer carries the right tags and lands on the right subscriber lists whether or not they existed before. It calls Get Product on each line item to establish which purchases are membership products and which member group each grants, then calls Create Member with those groups and no password so the platform sends its own welcome. The same order data flows to the accounting system in QuickBooks Online and to the fulfillment queue. Anything the agent cannot resolve, meaning a product with no group mapping or a buyer whose email bounced at checkout, becomes an automation exception with the order number attached rather than a half-provisioned member.

Funnel data that leaves the funnel

Simvoly captures form submissions and bookings on the site, and by default they stay there. On a scheduled run the agent reads List Form Submissions and List Bookings for the window since the last pass, matches each against existing contacts with Search Contact By Email, and routes them: a demo request goes to the CRM in HubSpot with the form fields intact, a booking goes to the calendar owner, and a support-shaped message goes to the queue rather than to sales. Alongside it, Get Website Stats pulls the traffic and referrer breakdown for the same window, so the weekly summary in Slack puts the submissions next to the traffic that produced them instead of in a separate report nobody opens.

Fulfillment status that customers can actually see

When a physical order ships, the tracking number arrives from the carrier or the warehouse. The agent calls Get Order to confirm the order is in the state it expects, then Update Order to mark it paid where payment has cleared, record the payment details, and attach the fulfillment tracking. Because Update Order changes what the customer sees on their order page, the flow is built to refuse ambiguity: an order whose current status does not match what the upstream system believes is not overwritten, it is reported. The failure mode this avoids is the quiet one, where a status write based on a stale read tells a customer their order shipped when it did not.

Human-in-Loop Highlight

Most of this connector is ordinary, and one action is not. Start Member Session generates a single sign-on URL for a member. Whoever holds that URL is that member: inside the paid area, seeing what they see, able to do what they can do. It is not a password reset and it is not a support view. It is a session, and unlike a password there is nothing the member can change to take it back. That is the most consequential thing an agent could do on a Simvoly site, and it is one call with one parameter.

So the flow is built so that no automated path can produce one. A support request that needs a look inside the member area goes to a named owner with the context assembled: "Ticket 4821. Jordan Ellis, [email protected], member since March, groups: Pro, Course Cohort 4. Reports the course library is empty. Get Member confirms both groups are assigned and the account is approved. Minting a sign-in link with Start Member Session will log the holder in as this member with full access to their account. Issue a link for this ticket?" The agent has already done the diagnosis that usually justifies the impersonation, which frequently means the link is not needed at all. When it is needed, a person authorized it, the ticket it belongs to is named, and both facts are in the run history. That is human-in-the-loop where the risk actually lives, rather than an approval step bolted onto something harmless.

Two more actions belong behind a person for their own reasons rather than by analogy. Delete Member and Delete Contact are permanent, and on a platform where the same person exists as both, a cleanup flow that deletes the contact and leaves the member, or the reverse, produces a customer who is half gone and impossible to reason about later. Delete Member Group is quieter and worse: retiring a group removes the tier itself, and every member who held it loses that access at once, which is a change that looks like a configuration tidy-up and lands like a mass revocation. A flow may propose any of these with the affected counts attached. It should not perform them on its own.

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

38 actions

Contacts

List Contacts Returns a paginated list of the site's contacts with optional creation date filters. The read behind reconciliation against a CRM and behind any report on how the list is growing.
Get Contact Retrieves a single contact by ID with its tags and custom properties. Used when a flow already holds an ID and needs the full record before deciding anything.
Search Contact By Email Looks up a contact by exact email address. The identity check that belongs before almost every write, because email is the key the upsert operates on.
Create Or Update Contact Upserts a contact keyed by email, including tags, custom properties, and subscriber list membership. The correct primitive for keeping the site list synchronized with a system of record without creating a second copy of the same person.
Update Contact Updates an existing contact by ID. Used when the record is already identified and only specific fields should change, rather than reasserting the whole contact.
Delete Contact Permanently deletes a contact by ID. Irreversible, and on a site where the same person is also a member it leaves a half-removed customer unless the member record is handled in the same decision.

Members and Member Groups

List Members Returns the site's membership roster. The read behind entitlement audits and behind any comparison of who has access against who is paying.
Get Member Retrieves a single member with their groups and approval state. The diagnostic call when a customer reports missing access, and usually the one that makes an impersonation unnecessary.
Search Member By Email Looks up a member by exact email. Used to establish whether a buyer already has paid access before creating a second account for them.
Create Member Creates a member with optional password, groups, and approval state. Omitting the password makes Simvoly send its own reset email, which keeps credentials out of the flow entirely and is the right default.
Update Member Updates an existing member, including their group assignments and approval state. The action behind upgrades, downgrades, and reinstatements.
Delete Member Permanently deletes a member. Irreversible, and it removes the paid-access identity rather than just the access, so a downgrade should be an Update Member call instead.
Start Member Session Generates a single sign-on URL that logs whoever holds it in as that member. This is impersonation, not a password reset, and it is the action on this connector that should never be reachable from an automatic path.
List Member Groups Lists the access tiers defined on the site. The vocabulary a provisioning flow assigns from, and the reference it should resolve against rather than carrying hard-coded group IDs.
Get Member Group Retrieves a single member group. Used to confirm a tier still exists and means what the flow assumes before assigning anyone to it.
Create Member Group Creates a new access tier. Used when a new product or cohort needs its own group rather than reusing an existing one.
Update Member Group Updates an existing access tier. Used to rename or reconfigure a tier without disturbing who holds it.
Delete Member Group Deletes an access tier. Everyone holding that group loses the access it granted at the same moment, which makes this a mass revocation wearing the clothes of a configuration change.

Products

List Products Lists products with filtering by category and title and with pagination. The read behind catalog synchronization and behind any check that a purchased item still exists.
List Product Categories Lists the product categories defined on the site. Used to place a new product correctly rather than leaving it uncategorized.
Get Product Retrieves a single product with its type, pricing, and configuration. The call that tells a provisioning flow whether a purchase is a membership product and what it grants.
Create Product Creates a physical, digital, service, or membership product with images. Used to push a catalog from a system of record into the store rather than rebuilding it by hand.
Update Product Updates an existing product. The action behind price changes, inventory updates, and description corrections driven from elsewhere.
Delete Product Deletes a product from the store. Worth pairing with a check on open orders, because removing a product that recent orders reference makes those orders harder to interpret later.

Orders

List Orders Lists orders with pagination and creation date filters. The read that opens every fulfillment run and every reconciliation against the accounting system.
Get Order Retrieves a single order with its line items and totals. Used to confirm current state before writing to it, so a status update is never based on a stale read.
Update Order Changes an order's status, marks it paid, records payment details, and adds fulfillment tracking. This is what the customer sees on their order page, which makes an incorrect write a customer-facing error rather than an internal one.

Forms and Bookings

List Form Submissions Lists form submissions with date range filters and pagination. A clean routing input, because it is read-only and carries the submitted fields as the visitor entered them.
List Bookings Lists bookings filtered by event and date range. Used to feed the calendar owner, to prepare for the day, and to reconcile appointments against orders.

Subscriber Lists

List Subscriber Lists Lists the email subscriber lists on the site. The vocabulary a contact upsert assigns from.
Get Subscriber List Retrieves a single subscriber list. Used to confirm a list exists before a flow starts adding people to it.
Create Subscriber List Creates a new subscriber list. Used when a campaign or a product launch needs its own audience rather than a tag on an existing one.
Update Subscriber List Updates an existing subscriber list. Used for renames and configuration changes that should not disturb the membership of the list.
Delete Subscriber List Deletes a subscriber list. The list membership goes with it, so this is worth treating as a data loss rather than a tidy-up.

Analytics

Get Website Stats Returns hourly, daily, referrer, device, browser, or usage metrics for a date range. Used to put traffic next to the submissions and orders it produced, in one report rather than three dashboards.

Webhooks

List Webhooks Lists the webhook subscriptions configured on the site. The audit read that answers which endpoints are currently receiving store and contact events.
Create Webhook Subscribes a target URL to store and contact events. Because Simvoly does not publish a fixed payload schema, a flow should treat what arrives as untrusted shape and validate it rather than assuming fields are present.
Delete Webhook Removes a webhook subscription. Deleting the wrong one silently stops a downstream flow from receiving anything, and nothing errors when it does.

Frequently Asked Questions

What can FlowRunner do with Simvoly?

FlowRunner agents can run List Contacts, Get Contact, and Search Contact By Email in Simvoly, plus 35 more actions.

Does connecting Simvoly to FlowRunner require OAuth?

No. Simvoly connects to FlowRunner with an API key, no OAuth flow required.

Can Simvoly trigger a FlowRunner workflow automatically?

Simvoly doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Simvoly

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us