Integrations
LiveCRM operates the tools you already pay for. It does not resell CRM seats, provider credits or model access, and it does not sit between you and your own contracts.
The gap this closes. A tool that touches your CRM usually wants a key and a subscription of its own. Then your records live in their system, your provider credits sit on their contract, and the model reading your pipeline is billed to an account you cannot see and cannot audit.
There are four things LiveCRM connects to, and the same rule holds for all of them: you own the account, you hold the contract, and you can disconnect it without asking us.
Credentials are yours and are never shown back to you. Each one is held per tenant in a vault, referenced rather than copied, and rotated by replacing it. Removing one is a single action and takes effect immediately.
Disconnecting does not reset your posture. The settings that govern how a connection behaves survive its removal, which matters most for the one below that can fail closed.
What connects
Two CRMs, both first class. One data provider. One place people already work. One model, optionally your own.
The mirror
Which is why asking questions costs nothing and never counts against an API limit.
LiveCRM keeps its own mirror of the records it operates on, kept current by the change feed rather than by polling. Every read answers from there: counting a scope, reading the field catalog, previewing what a run would change, checking what is duplicated or thin or pointed at the wrong owner.
That has three consequences worth stating plainly. Your agent can ask anything, as often as it likes, without spending your API quota. A preview can size a real operation against real records before anything is written. And the one thing that does reach your CRM, a write, is the one thing held behind a permission and an audit trail.
Fail closed
The setting that matters is not whether you can supply a key. It is what the product does when that key stops working.
Connect your own Anthropic key and every reasoning call bills to your account. You then choose the posture. Fall back means that if your key is missing or failing, reasoning continues on ours and the work gets done. Fail closed means it does not: the call raises rather than quietly running on somebody else's account, because for some organisations "our data was processed under a contract we did not sign" is the outcome to prevent even at the cost of the feature.
That choice is stored apart from the key itself, so it survives the key being removed. A tenant that chose fail closed stays fail closed after a rotation, an expiry or a mistake. It is the persistence that makes the promise real, rather than a checkbox that resets the moment the thing it governs disappears.
The key is never written to a log and never returned by any route, including the one that tells you whether it is connected.
Both CRMs
The difference shows up in what a connection is allowed to assume about itself.
Anything keyed to a connection works from that connection's own field catalog, its own picklists and its own object names. A rule you author is built against the fields your org actually has rather than a generic schema with a mapping layer on top, which is the arrangement that makes a second CRM feel like a translation of the first.
The practical test is whether a HubSpot connection reaches every page with its rules seeded and its catalog populated, the same way a Salesforce one does. That is the standard this product holds itself to.
The rest of it
Connecting takes minutes
Connect it read only, run the readiness scan, and decide what to do about what it finds.