--- title: "Livespace Integration" description: "Connect AI agents to Livespace, a Polish sales CRM with a structured sales process. Agents create people and companies, move deals through defined stages, assign tasks, and search across the full record set." url: https://flowrunner.ai/integrations/livespace-crm date_modified: 2026-08-11T09:36:14-07:00 --- # Livespace [CRM](https://flowrunner.ai/integrations/category/crm-sales) Connect AI agents to Livespace, a Polish sales CRM with a structured sales process. Agents create people and companies, move deals through defined stages, assign tasks, and search across the full record set. 29 actions · Custom auth · available [Platform Documentation](https://api-docs.livespace.io) · Capability data verified 2026-08-11 1. An inbound inquiry, a form batch, or a scheduled poll starts the run 2. Get Custom Fields returns the dataset and option IDs this account uses, because custom fields are referenced by ID 3. Search runs across objects to find an existing person or company before anything is created 4. Add Company then Add Person writes the records only where no match was found 5. Add Deal opens the opportunity in its sales process, and Add Deal Note records where it came from 6. The owner is told what was created, what was matched, and which deals were opened 7. A person confirms which catalogue entries are discontinued before Delete Product removes them permanently ## What This Integration Enables Livespace is a Polish sales CRM organised around a structured sales process rather than a free-form pipeline, and that structure is the reason to choose it. A deal here is not a card someone drags. It sits in a defined sales process with stages, and it carries the statuses open, won, lost, and outdated. The connector reflects that: persons, companies, deals, tasks, and products get the read and write coverage you would expect, and on top of that sit the things a structured process needs to be honest, which are Add Person Note, Add Company Note, Add Deal Note, and Log Person Call. An agent working here is not just moving records, it is leaving the trail that makes a stage change defensible when a sales manager asks why a deal moved. Four properties are worth internalising before building. Authentication is not a static bearer token: every call first requests a short-lived auth token and session ID, then signs the operation with `_api_sha = SHA1(API Key + Auth Token + API Secret)`, so one flow call becomes two HTTP requests and the API Secret is used only to compute the control sum and is never transmitted. The credentials belong to a specific Livespace user, so every operation runs at that user's permission level and result code 540 means the credentialed user lacks access rather than that the record is missing. The API always answers HTTP 200 and reports success or failure inside the envelope `{ data, error, result, status }`, so this connector inspects the envelope and raises when `status` is false, which is how 420 validation, 561 incorrect parameters, and 562 incorrect key surface as real errors instead of quiet passes. And external API IDs are only returned and accepted when they are enabled in Account settings, with custom fields referenced by ID rather than by name, which makes Get Custom Fields the first call in any flow that writes to a field a rep configured. A few wire names keep the vendor's exact spelling, including the deal list filter for related companies sent as `comapnies` and the deal note wrapper key capitalised as `Deal`, and Polish tax fields such as NIP and REGON are preserved as-is. Livespace ships no triggers to FlowRunner, so agents poll: List Persons and List Companies return all records unless a limit is set, while List Tasks caps at 50 per page unless Get Whole List is enabled and then pages. Delete Person, Delete Company, Delete Deal, and Delete Product are permanent and cannot be undone. ### Without FlowRunner **Every account has its own field IDs**: Custom fields are hardcoded from one tenant and silently miss on another **Duplicates are created then merged**: The same company is added by two systems and reconciled later by hand **Failures look like successes**: The API answers HTTP 200 on a logical error, so a flow that reads the status code believes a write landed ### With FlowRunner **Field IDs are discovered per account**: Get Custom Fields resolves the dataset and option IDs before any write is composed **Duplicates are prevented at the source**: Search runs first, so a match becomes an edit and only a genuine miss becomes an add **Failures surface as failures**: The response envelope is inspected and a \`status\` of false is raised with its result code ## Use Case Scenarios ### Inbound inquiries that reach the CRM without a duplicate company behind them An inquiry arrives in a shared mailbox monitored through [Gmail](https://flowrunner.ai/integrations/gmail-service). The agent extracts the sender, their domain, and whatever they said they wanted, then calls Search across objects to check for an existing person and an existing company in one pass rather than guessing which one to look for first. Where the company already exists it calls Add Person against it. Where neither exists it calls Add Company first and Add Person second, so the person is never created orphaned and the pipeline stays readable by customer. It calls Get Custom Fields before composing either payload, because a sales team that added a source or segment field references it by dataset ID and a hardcoded ID from another tenant writes into nothing. Add Deal then opens the opportunity in the correct sales process, and Add Deal Note records the inquiry text so the first stage of the process has evidence attached to it rather than a title. ### A call log that survives the person who made the call A rep finishes a call and the outcome is captured in a telephony system or typed into a channel. The agent resolves the person with Get Person or Search, then calls Log Person Call with the outcome and Add Person Note with the substance of the conversation, which are separate actions in Livespace for a reason: the call is the event and the note is the content, and reporting on activity volume needs the first while a colleague picking the account up next quarter needs the second. Where the conversation moved the opportunity, Edit Deal changes the status to won, lost, or outdated, and Add Deal Note explains it. Where it produced a commitment, Add Task assigns the follow-up with a type, status, and priority, and Edit Task closes it out when the flow that owns the work reports back. ### A catalogue and a forecast that stay in step with the system that owns them A product catalogue lives in an ERP or a pricing system, and Livespace holds the subset reps quote from. On a schedule the agent calls List Products, pulls the authoritative catalogue from the source system, and computes three sets: products that are new, products whose detail has drifted, and products that no longer exist upstream. New ones become Add Product. Drifted ones are reported rather than silently rewritten, because this connector offers Add Product and Delete Product without an edit path, so changing a product means removing and re-adding it. The third set, the discontinued ones, goes to the gate below. In the same run the agent calls List Deals with the related company filter, which is sent on the wire as `comapnies`, joins each deal to its company with Get Company and its owner with Get Current User context, and writes a forecast view into a sheet the sales lead reads. ## Human-in-Loop Highlight Delete Product is the action here that reaches furthest past the record it names. Livespace deletes are permanent, and that alone would earn a gate, but a person or a company deleted in error is a record one team lost. A product deleted in error is a line item every open deal in the account might be quoting from. The catalogue is shared infrastructure: reps build quotes against it, and this connector exposes Add Product and Delete Product with no edit action between them, which means the natural way for an agent to reconcile a price change is to delete and re-add. That is exactly the operation that should never run unattended, because the window between the delete and the add is a window where a rep opens a deal and finds the line gone, and if the add fails on a validation error, which the API reports inside a 200 response with result code 420 rather than as an HTTP failure, the window does not close. So the agent does the comparison and stops. It calls List Products, diffs against the upstream catalogue, and posts to the sales operations owner in [Slack](https://flowrunner.ai/integrations/slack): "The ERP catalogue no longer contains 14 of the 226 products in Livespace. Nine have not appeared on a deal in the last two years. Five are referenced by open deals, listed here with the deal name, the owner, and the value. Livespace deletes are permanent and there is no edit action, so removing a product means the reps quoting it lose the line. Delete the nine unused, delete all 14, or hold the five and ask their owners first?" The owner replies once, and only the approved list becomes Delete Product calls, each one checked against the response envelope rather than the HTTP status. This is the [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) moment that a shared catalogue demands, and it exists because the agent can see which products are unused but cannot see which deal a rep is about to send this afternoon. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via Slack Human decides Agent resumes with decision ## Agent Capabilities 29 actions ### Persons 7 - **Get Person** Retrieves a single person by ID. Used to confirm current state and ownership before an edit is composed. - **List Persons** Returns persons, defaulting to all records unless a limit is set. Used for coverage sweeps and scheduled change detection. - **Add Person** Creates a person, optionally against an existing company so the record is never orphaned. Custom fields are referenced by their dataset ID. - **Edit Person** Updates a person. Used to enrich a record from another system without disturbing fields a rep owns. - **Delete Person** Deletes a person permanently. There is no undo, so this runs only on a set someone has reviewed. - **Add Person Note** Appends a note to a person's profile. This is where the substance of a conversation lives, as distinct from the fact that it happened. - **Log Person Call** Records a call against a person. Separate from a note because activity reporting needs the event and a colleague picking up the account needs the content. ### Companies 6 - **Get Company** Retrieves a single company by ID, including Polish tax fields such as NIP and REGON which are preserved as sent. - **List Companies** Returns companies, defaulting to all records unless a limit is set. Used to resolve accounts in bulk before a join. - **Add Company** Creates a company. Called before Add Person on a new account so the person attaches to something real. - **Edit Company** Updates a company. Used to keep account data aligned with a billing or ERP source of truth. - **Delete Company** Deletes a company permanently, leaving its related records without their anchor. Held behind human review. - **Add Company Note** Appends a note to a company profile. Used to record account-level context that does not belong on one person. ### Deals 6 - **Get Deal** Retrieves a single deal with its sales process stage and status. Used to confirm state before proposing a move. - **List Deals** Returns deals with filters including the related company filter, which Livespace sends on the wire as \`comapnies\`. Used for forecast sweeps and stalled deal detection. - **Add Deal** Creates a deal inside a defined sales process. Used when a qualified opportunity opens. - **Edit Deal** Updates a deal, including moving it between the open, won, lost, and outdated statuses. Used to reflect an outcome decided in a conversation. - **Delete Deal** Deletes a deal permanently, taking its notes with it. Reserved for reviewed cleanup. - **Add Deal Note** Appends a note to a deal. The wrapper key is capitalised as \`Deal\` on the wire, which this connector handles. Used to explain why a stage or status changed. ### Tasks 4 - **Get Task** Retrieves a single task with its type, status, and priority. Used to confirm assignment before acting. - **List Tasks** Returns tasks capped at 50 per page unless Get Whole List is enabled, then pages with the Page parameter. Used for overdue and unassigned sweeps. - **Add Task** Creates a task assigned to a user with a type, status, and priority. Used to make a follow-up concrete inside the run that identified it. - **Edit Task** Updates a task, including reassignment and completion. Used to close out follow-ups the flow itself satisfied. ### Products 3 - **List Products** Returns the product catalogue reps quote from. Used as the read side of a catalogue reconciliation against an upstream system. - **Add Product** Adds a product to the catalogue. Because there is no edit action, a price correction is expressed as a delete followed by an add. - **Delete Product** Deletes a product permanently. Open deals quote from this catalogue, so removals run only on a set a person has approved. ### Search and Account Data 3 - **Search** Searches across CRM objects in one call. This is the deduplication primitive: it answers whether this person or this company already exists before anything is created. - **Get Current User** Returns the user the credentials belong to. Because every operation runs at that user's permission level, this is the preflight check that explains a 540 no permission result. - **Get Custom Fields** Returns the custom field and option IDs defined for an object type. External API IDs must be enabled in Account settings, and custom fields are referenced by ID, so this is the first call in any flow that writes to a field a rep configured. ## Frequently Asked Questions ### What can FlowRunner do with Livespace? FlowRunner agents can run Get Person, List Persons, and Add Person in Livespace, plus 26 more actions. ### Does connecting Livespace to FlowRunner require OAuth? Livespace uses a custom authentication method to connect to FlowRunner. ### Can Livespace trigger a FlowRunner workflow automatically? Livespace doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Livespace?** This integration exposes Livespace 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/livespace-crm. Site index: https://flowrunner.ai/llms.txt