"Can it connect?" is never the question. "Which system is right when they disagree?" is.

In practice, anything that can integrate with Salesforce — because Litify is a managed package on the Salesforce platform rather than a standalone system. That means the standard REST and Bulk APIs, AppExchange connectors, Platform Events and ordinary middleware, not a proprietary gateway. Partner connectors exist for accounting systems including QuickBooks, Accounting Seed and Sage Intacct; DocuSign and Adobe Sign cover e-signature; iManage and NetDocuments cover document management. Court and litigation service providers, call tracking, marketing platforms and referral networks all connect through the same surface.

Litify, for client details, matter data, time entries and expenses — it is where intake creates the record and where the matter team works daily. Accounting should be master for invoices once posted and for payments and receipts, because that is the system of record an auditor will ask about. Documents depend on whether you have a DMS: where one exists it should be the repository and Litify the index. The one rule that never bends is that no field has two masters — that is what produces a sync overwriting in whichever direction ran last.

This page is about which systems connect and what the business consequence is: master data, direction, and what the firm gets. The API page is the engineering underneath — choosing between REST, Bulk and Composite, Platform Events versus polling, governor limits, auth models, idempotency and retry design. If you are deciding whether to connect your accounting system and how that changes month-end, you are on the right page. If you are scoping a custom integration and need to know how it will behave under a 50,000-record load, that is the API page.

Usually, and the fix is often not where firms expect. Most law firm integrations were built without retry logic, error alerting or reconciliation, so what looks like "keeps breaking" is frequently one transient failure that nobody caught, followed by weeks of drift. We start by looking at the error logs and running a reconciliation between the two systems to find out how far apart they actually are. Sometimes the answer is a rebuild; more often it is adding the failure handling that was never built in the first place.

Below roughly three integrations, middleware is usually overhead — a direct build or a packaged connector is simpler and has one less system to license and own. Above that, or where you need transformation, routing between several systems, or retry and monitoring the endpoints do not provide, middleware earns its place. The honest caveat is that middleware is a system in its own right: it needs an owner, a runbook and a licence line in the budget. We will tell you which side of that line you are on rather than defaulting to the bigger answer.

Integrations built against the Salesforce API surface are generally unaffected, because they use platform APIs rather than the package's internals. The risk is concentrated in two places: custom code that references Litify objects or fields directly, which we write defensively for that reason, and packaged connectors, whose own upgrade path you should understand before installing. We check integration behaviour against Litify releases as part of ongoing support, and we build so that a vendor upgrade is a routine event rather than a project.

You should not have to take anyone's word for it, which is why we build three things into every integration. Error alerting that reaches a named person rather than a log nobody reads. A retry and dead-letter path so a transient failure is recovered rather than lost. And a reconciliation report — run at a cadence that suits the data — that compares both sides and surfaces any drift. If an integration cannot tell you it is healthy, it is not finished.