LivingMetrics

Connect AI agents to LivingMetrics, an SMB CRM and marketing data platform. Agents submit leads, create contacts and deals, move and transfer products between holders, assign tasks, and read the history of form submissions, visits, and email opens behind a record.

35 actions API key available

Platform Documentation ↗

A form submission, a signup, or a scheduled poll starts the run

List Contact Fields returns the field keys and IDs this account defines, since custom fields are account-specific

List Contacts filters on email to see whether this person is already known

Submit Lead records the inbound lead, or Create Contact writes the person where a lead is not the right shape

Create Deal opens the opportunity in the correct funnel and stage, and Create Task schedules the follow-up

The owner is told what was created and which existing contact it was matched against

A person approves the unit before Move Out Product or Transfer Product changes who holds it

What This Integration Enables

LivingMetrics is a white-label instance of the ActiveDEMAND platform, and the giveaway that it is not a generic sales CRM is sitting in the Products group. Alongside the usual create, update, and delete, this connector exposes Move Out Product and Transfer Product. Those verbs do not belong to a catalogue of things you sell. They belong to a catalogue of things you assign: rental units, equipment, licensed assets, anything with an occupant and a handover. That single detail tells you who this platform is for, and it should shape what you automate. The contact and deal surface here is worth wiring for the obvious reasons, but the operation that earns its keep is keeping a unit's assignment truthful without a person retyping it out of an operational system.

The rest of the surface is straightforward and well behaved. Contacts, deals, products, and tasks all accept custom fields two ways, either as a custom_fields array of name and value pairs, or as a direct custom_{id} key through Additional Fields, and List Contact Fields and List Deal Fields exist so a flow can discover those keys and IDs rather than assume them. Deal funnel, stage, and status, product status, and task type, status, and outcome are all account-defined and resolved by ID. Delete Deal and Delete Product are soft deletes, so the record is marked deleted rather than permanently removed, while Delete Task actually removes the task. Two things need stating precisely because their names suggest more than they do. First, the Activity surface here is read-only: Get Histories returns a contact's form submissions, site visits, and email opens, and there is no action on this connector that writes an activity record. Where a flow needs to leave a trail on a contact, it does so with a task carrying an outcome, not with a logged activity. Second, Subscribe To Webhook and Unsubscribe From Webhook are actions, not connectors listening for events. A subscription registers a target URL of your choosing against a single contact's update events and returns a subscription ID. Because the subscription is scoped per contact rather than to an account-wide stream, no FlowRunner realtime trigger is provided, and this connector ships zero triggers. Change detection is a scheduled poll on List Contacts or List Deals with the Order parameter, and a target URL that returns HTTP 410 is unsubscribed by LivingMetrics automatically.

Without FlowRunner

Field keys are guessed Custom fields are hardcoded from one account and silently miss on the next

Follow-up depends on memory A task is created when someone remembers, and closed without an outcome anyone can report on

Unit changes happen in two places A move-out is recorded in an operational system and reaches the CRM whenever someone gets to it

With FlowRunner

Field keys are discovered List Contact Fields and List Deal Fields resolve the account's own keys and IDs before a payload is composed

Follow-up is created with the record The task exists with a type and a due date the moment the deal does, and closes with a recorded outcome

Unit changes are proposed, then approved The flow computes the move-out or transfer and a person confirms it before possession changes

Use Case Scenarios

An inbound lead that arrives with its own account's field keys

A form submission lands from a website or a landing page. Before writing anything, the agent calls List Contact Fields to resolve the keys this account actually defines, because a source or campaign field configured by the marketing team is addressed as custom_{id} and an ID borrowed from another account writes into nothing. It then calls List Contacts filtered on the email to see whether this person is already known. A new person goes through Submit Lead, which is the purpose-built inbound path. A returning one goes through Update Contact so the record is enriched rather than duplicated, and Add Contact Relationship links them to the household, company, or referring contact the form implied. Get Contact Count on the same filter gives the flow a cheap sanity check that the segment it thinks it is working against is the size it expected.

A pipeline that reports itself instead of being reported on

On a schedule, the agent calls List Deals with the Order parameter set to descending and pages the open opportunities, using Get Deals Count first so it can size the job before it starts. For each deal it calls Get Contact to resolve the person and Get Histories to pull that contact's recent form submissions, site visits, and email opens. The joined view goes into a sheet in Google Sheets that the revenue team reads on Monday, with a flag on any deal whose contact has gone quiet in the history stream while the deal itself has not moved stage. Where a deal has clearly progressed in another system, Update Deal moves it and Create Task schedules the next action with a type and due date resolved from the account's own dictionaries, so the follow-up exists before anyone opens the CRM. Nothing about the unit assignment is touched in this run.

A unit handover that stays truthful across two systems

An operational system, a property manager, or a signed document flow reports that an occupant is leaving or moving to a different unit. The agent calls List Products with a status filter and Get Product Statuses to resolve what this account calls occupied, available, and reserved, then Get Product to read the unit's current state and confirm it matches what the upstream system believes. Where the two disagree, that disagreement is the finding and the flow reports it rather than resolving it, because a CRM that thinks a unit is empty and a building that has someone living in it is a problem no automated write should paper over. Where they agree, the agent assembles the Move Out Product or Transfer Product call, attaches the evidence, and stops at the gate below. Update Product handles the parts that are genuinely safe to write unattended, such as a description or a custom field the marketing team owns.

Human-in-Loop Highlight

Move Out Product and Transfer Product are the two actions on this connector that describe something happening in the physical world. Every other write here changes what a system believes. These change who holds a unit, and the system of record they change is the one a billing run, an access list, and a lease renewal all read from. A move-out recorded against the wrong unit does not produce a wrong field on a record, it produces an invoice that stops, a resident who shows as departed, and a unit offered to somebody else. A transfer executed against the wrong occupant does the same thing in both directions at once. And the connector's own delete semantics make the asymmetry plain: Delete Deal and Delete Product are soft deletes that can be reasoned about after the fact, while a move-out is a state transition with downstream consequences that no undo action on this surface reverses. So the agent does the reconciliation, which is genuinely hard and genuinely worth automating, and it stops before the transition. It calls Get Product Statuses and Get Product to establish the current state, compares it against the upstream operational system, and posts to the property operations owner: "The lease system reports 7 move-outs effective this week. Six match a LivingMetrics unit currently in an occupied status and are ready to move out. One, unit 214, is already marked available here while the lease system shows an active occupant, so the two systems disagree and I have not touched it. Separately, 2 transfers are proposed, both between units in this building, listed with the current and destination unit and the contact on each. Move-out changes billing and access downstream. Approve the six, approve the six and the two transfers, or hold?" The owner replies once, and only the approved set becomes Move Out Product and Transfer Product calls. This is the human-in-the-loop moment that a platform with an assignment model requires, because the agent can see two systems and a person can see the building.

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

35 actions

Contacts

List Contacts Returns contacts with an Order parameter of ascending or descending. Used for scheduled sweeps and as the dedup check before a create.
Get Contact Count Returns a count for a filter without pulling the rows. Used to size a job and to sanity check that a segment is the size the flow expected.
Get Contact Retrieves a single contact with its full field set. Used to confirm current state before an update is composed.
List Contact Fields Returns the contact field keys and IDs this account defines. Because custom fields are addressed as `custom_{id}` or as name and value pairs, this is the first call in any flow that writes a configured field.
Create Contact Creates a contact, accepting custom fields either as a `custom_fields` array or as direct `custom_{id}` keys through Additional Fields.
Update Contact Updates a contact. Used to enrich a known person rather than create a second record for them.
Add Contact Relationship Links a contact to another contact. Used to record the household, company, or referral relationship a form submission implied.

Leads

Submit Lead Records an inbound lead through the platform's purpose-built lead path. This is the right entry point for a form submission, as distinct from creating a contact directly.

Deals

List Deals Returns deals with an Order parameter. Used for scheduled pipeline sweeps and stalled deal detection.
Get Deal Retrieves a single deal with its funnel, stage, and status. Used to confirm state before a move.
Create Deal Creates a deal in a funnel and stage, both of which are account-defined and resolved by ID.
Update Deal Updates a deal, including its funnel, stage, and status. Used to reflect progress that happened in another system.
Delete Deal Soft deletes a deal, marking it deleted rather than permanently removing it.
Get Deals Count Returns a count of deals for a filter. Used to size a paging job before it starts.
List Deal Fields Returns the deal field keys and IDs this account defines. Used the same way as List Contact Fields, before any write to a configured field.

Products

List Products Returns the product or unit catalogue, filterable by status. Used to reconcile assignment state against an operational system.
Get Product Retrieves a single unit with its current status. Used to confirm the unit's state matches what the upstream system believes before any transition.
Create Product Creates a unit, accepting custom fields as a `custom_fields` array using `custom_field_type_id` and value pairs, or as direct keys.
Update Product Updates a unit's attributes. Used for the parts that are safe to write unattended, such as descriptions and marketing-owned custom fields.
Delete Product Soft deletes a unit, marking it deleted rather than permanently removing it.
Get Product Statuses Returns the account-defined product statuses. This is how a flow learns what this account calls occupied, available, and reserved before it reasons about a transition.
Move Out Product Records a unit move-out, ending the current assignment. Because billing, access, and availability read from this state, it runs only on an approved set.
Transfer Product Transfers a unit assignment. It changes possession in two places at once, so it is held to the same approval as a move-out.

Tasks

List Tasks Returns tasks, with flags including Include Completed and User Only. Used for overdue and coverage sweeps.
List Contact Tasks Returns the tasks attached to a single contact. Used to check what follow-up already exists before adding more.
Get Task Retrieves a single task with its type, status, and outcome. Used to confirm assignment before acting.
Create Task Creates a task against a contact with an account-defined type. Used to make a follow-up concrete inside the run that identified it.
Update Task Updates a task, including closing it with an outcome. Because there is no action here that writes an activity record, a task carrying an outcome is how a flow leaves a reportable trail.
Delete Task Removes a task. Unlike deals and products, this is not a soft delete.
Get Task Outcomes Returns the account-defined task outcomes. Used to close a task with a value the account's reporting recognises.
Get Task Types Returns the account-defined task types. Used to create a task that sorts correctly in the platform's own views.
Get Task Statuses Returns the account-defined task statuses. Used to set a status the account actually has rather than a guessed label.

Activity

Get Histories Returns a contact's activity history, including form submissions, site visits, and email opens, with an Order parameter. This surface is read-only: it reports engagement, and nothing on this connector writes an activity record.

Webhooks

Subscribe To Webhook Registers a target URL of your choosing against a single contact's update events and returns a subscription ID. This subscribes an external endpoint and does not create a FlowRunner trigger. A target URL that returns HTTP 410 is unsubscribed by LivingMetrics automatically.
Unsubscribe From Webhook Removes a subscription, accepting either the subscription ID or the target URL plus the contact ID.

Frequently Asked Questions

What can FlowRunner do with LivingMetrics?

FlowRunner agents can run List Contacts, Get Contact Count, and Get Contact in LivingMetrics, plus 32 more actions.

Does connecting LivingMetrics to FlowRunner require OAuth?

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

Can LivingMetrics trigger a FlowRunner workflow automatically?

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

Start building with LivingMetrics

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

Start Building Free Talk to us