Billing and trust data flowing out automatically
A matter's billing or trust fields update in Litify, and that change reaches your firm's accounting or trust ledger without a report getting exported and re-typed in by hand.
Litify doesn't run a separate API of its own. Everything it exposes for integration runs through standard Salesforce REST, Bulk, Composite, and Platform Events APIs, inside your firm's org, the same way any Salesforce integration works. n-frames builds on that layer: mapping Litify's own matter, intake, and billing objects, which Litify doesn't document publicly, and connecting them to whatever your firm runs outside Litify.
Because Litify is a managed package running inside Salesforce, you don't connect to a separate Litify API the way you would with most legal practice management tools. You connect to the same Salesforce REST, SOAP, Bulk, and Composite APIs Salesforce exposes to any licensed org, plus Platform Events for near-real-time triggers.
Access isn't automatic. You need the right Litify SKUs enabled, a Connected App configured in your org, and enough of Salesforce's per-org daily API capacity to cover what you're building. Authentication runs through Salesforce OAuth plus an integrator key Litify issues on top of it. None of that is unusual for Salesforce work, but it does mean integration planning starts before any code gets written.
The documentation gap is Litify's custom objects, not Salesforce's. Salesforce's own API is thoroughly documented. Litify's specific matter, intake, referral, and billing object structure isn't published anywhere, so every integration starts with figuring out how a given firm's Litify instance actually models its own data, since customizations vary from org to org.
That's where the real work is. We've mapped object relationships on plain Salesforce orgs for years. Doing the same thing against Litify's legal-specific layer is the same skill, applied to a schema nobody publishes a map for.
A matter's billing or trust fields update in Litify, and that change reaches your firm's accounting or trust ledger without a report getting exported and re-typed in by hand.
A new referral or intake record lands in Litify, and the relevant fields push out to wherever they're needed next, a CRM, a notification, a client-facing portal, instead of sitting in Litify until someone opens it.
Every firm's Litify instance models its objects a little differently. Tell us what you're trying to connect it to, and we'll scope what's actually reachable through the API before any build starts.
Most delays on a Litify integration come from figuring out how your firm's own instance models matters, intake, and referrals, since Litify doesn't publish that part. We'll do that mapping and build the connection on top of it. If the real bottleneck is a different piece of software entirely, we build automation wherever the manual work actually is, not just on top of Litify.
Let's talk →No. Litify is a managed package that runs inside Salesforce, so there's no separate Litify API to call. Any integration goes through the same Salesforce REST, SOAP, Bulk, or Platform Events APIs your org already has access to, scoped by whatever Litify licenses and permissions your firm holds.
The APIs themselves aren't harder, Salesforce's are well documented. What's missing is documentation for Litify's own custom objects: how a given firm's matters, intake records, and referrals are actually structured. Litify doesn't publish that, so every integration starts with figuring out the specific org's data model before any connection gets built.
Litify has started shipping its own AI tools directly into the platform, including a damages-assessment assistant for personal injury matters. We don't build or sell those features; they're Litify's own product. Where we come in is afterward, getting whatever those tools produce out of Litify and into the rest of your firm's workflow automatically.
There's no flat answer. It depends on your Litify licensing tier, how customized your org's objects are, and what you're connecting it to. Expect any serious integration to start with scoping the actual data model before a cost estimate means much.