Smokeball API integrations for Australian law firms

Quick answer: Smokeball does the core legal practice work — matter management, time tracking, document automation, trust accounting — with one of the more developer-friendly legal-software APIs we work with, in our experience. Where custom integration earns its place is around the firm, not inside it: structured website intake feeding matter creation, trust accounting reconciled with the firm’s general accounting platform, client communication orchestrated between matter milestones, and the cross-matter reporting partners want but Smokeball doesn’t produce natively. Five patterns cover most of what we build for Australian law firms running on Smokeball.

Smokeball has become a common choice in the Australian small-to-mid-firm legal market — sole practitioners, two-to-ten lawyer firms, regional practices, and a meaningful number of specialist commercial firms. The product fits practitioners who want a modern cloud interface, automatic time capture, deep document automation, and built-in trust accounting without paying for enterprise-tier features they don’t need.

Where it stops, like every legal PMS, is the operational layer around the firm. How prospects become matters. How matters connect to the firm’s general accounting. How clients are kept informed between milestones. How partners see across matters rather than into one at a time. Those are the integrations that pay back, and the API integration work that follows is well-supported by Smokeball’s API surface.

What Smokeball exposes

Worth being concrete about the integration surface:

• Public API with REST access covering matters, contacts, activities, billing entries, and most of what an integration needs to read or write
• Automatic time capture that records work events directly — less of an integration point and more of a value capture that’s already happening inside the platform
• Document automation with deep field merging, and document templates that integrations can trigger
• Trust accounting that Smokeball markets as designed to handle Australian state-by-state trust requirements — integrations read from it, but write access is constrained (correctly — trust accounting is regulated work)

The API access is well-documented and supports the integration patterns most firms eventually need. Compared to other Australian legal PMS products we work with, Smokeball’s integration surface is among the more accessible, in our experience.

Pattern 1 — Structured website intake to matter creation

The intake flow most firms have looks like this: enquiry comes in via the website, lands in an inbox, gets typed into Smokeball by a paralegal or the responsible lawyer, then becomes a matter (or doesn’t). The manual step costs hours per week and loses leads to typos and re-keying delays.

The integration that closes the gap:

• A structured enquiry form on the website with the matter-type-specific fields each practice area needs (different fields for family law, commercial, conveyancing, criminal defence, personal injury)
• A conflict check against existing Smokeball contacts before the enquiry is accepted
• A matter created automatically in Smokeball, with the enquirer as the client, the responsible lawyer assigned via practice-area routing rules, and the initial fee scope populated
• A confirmation email to the enquirer in the firm’s tone, not a generic auto-response
• A notification to the responsible lawyer formatted to read at-a-glance

What this gives the firm is a much tighter window between “person submitted enquiry” and “person engaged by a lawyer.” In high-velocity practice areas — family law, personal injury, traffic and criminal — that window is competitive.

Pattern 2 — Trust accounting reconciled with the firm’s books

Smokeball’s trust accounting is built to handle state-by-state Australian trust requirements. The reconciliation between trust accounting and the firm’s general accounting (typically Xero, sometimes MYOB) still involves bookkeeping work.

The integration:

• Daily import of trust transactions from Smokeball into Xero, properly categorised as trust receipts and disbursements
• Office account billing and disbursement entries flowing through alongside
• Bank-feed matching where the trust account’s real bank entries tie back to the Smokeball ledger automatically
• Month-end trust reconciliation reports compiled from both sides, not assembled manually from three reports

Trust accounting is one area where any integration has to be conservative. The cost of a wrong write to a trust account is regulatory, not just operational. The pattern that works: read-from-Smokeball, write-to-accounting; never the other direction. Trust adjustments stay inside Smokeball where the audit trail belongs.

Pattern 3 — Client communication between matter milestones

Smokeball’s built-in correspondence handles formal letters and matter-specific communication well. What it’s less suited to is the operational tier of client communication:

• Appointment confirmations and reminders for upcoming consultations or hearings
• Document-request reminders when a client is overdue with paperwork the matter needs
• Status updates on long-running matters (probate, immigration, complex commercial) where there’s nothing material to report but the client wants to know they’re still engaged
• Client onboarding for new matters — engagement letter, fee agreement, identity verification — orchestrated as a flow rather than sent manually

The integration shape: matter status changes in Smokeball trigger workflow steps in a separate orchestration service. Communications are logged back as Smokeball correspondence entries so the matter file stays complete. The patterns are the same as the ones we use for legal practice integration projects on Leap — the platform owns the matter, the integration owns the orchestration around it.

Pattern 4 — Cross-matter reporting partners actually want

Smokeball’s native reports cover matter-level views well — how a single matter is tracking, what’s billable on it, what’s outstanding. Partners typically want firm-level views that don’t map cleanly to matter-by-matter reporting:

• Profitability by practice area, accounting for partner time properly
• Lead-source attribution — which intake channels produce the matters that actually close
• Matter velocity — time from intake to first billable event, time from open to close, by matter type
• Client lifetime value where the “client” is the same person across multiple unrelated matters

The integration: nightly extract from Smokeball into a small reporting store, with cross-matter joins and partner-time apportionment logic done in the reporting layer. Dashboards consumed by the partners directly, refreshed independent of who’s in the office on month-end.

This is the integration that converts “the practice manager spends three days a month compiling reports” into “the practice manager spends three days a month on something more valuable.”

Pattern 5 — Document workflows that start outside Smokeball

Smokeball’s document automation is one of its strengths — the field merging, the template library, the precedent management is solid for matter documents. What it doesn’t cover is the document workflows that start outside Smokeball and have to end there:

• E-signature flows that begin in the website intake form and end with an executed engagement letter filed against the matter
• AML/CTF identity verification where the verification result needs to land in the matter as a recoverable record
• Discovery and disclosure where documents uploaded by the client via a portal have to be filed correctly against the matter
• Court-form e-filing where the form gets prepared inside Smokeball but the lodgement happens through CourtSA, NSW Online Registry or similar

The integration sits outside Smokeball and writes back via the API. This is typically a custom build because the orchestration logic is firm-specific — which evidence requirements apply to which matter types, which jurisdictions need which forms, which AML risk tier triggers what verification.

When custom integration isn’t the right call

A few cases where Smokeball out-of-the-box is the right answer:

• Sole practitioners and very small firms. The matter volume isn’t there to repay integration cost.
• Firms in their first six months on Smokeball. Operational rhythm is still settling; build nothing against a moving target.
• Firms about to switch platforms. Smokeball has real competitors in the Australian legal market (Leap, ActionStep, Affinity); if a switch is being considered, hold the integration work until the platform decision is settled.

The threshold where custom integration work earns its place is usually 4-5 fee earners, regular new matter flow across more than one practice area, and a practice manager who’s feeling the cost of the manual operational layer.

Where we start when Smokeball comes up

Most Smokeball integration projects we take on begin with a half-day audit: where the firm’s operational layer is doing manual work that could be automated, which practice areas have the highest matter velocity (and would benefit most from intake automation), where partner reporting is consuming month-end time. The plan stages intake first (highest competitive value), then partner reporting (highest leadership value), then client communication and document orchestration as appetite allows. Trust accounting integration is staged carefully because of the regulatory weight involved.

Running Smokeball across an Australian law firm and the patterns above describe the friction you’re feeling? That’s usually the prompt to have the conversation.

What a Smokeball integration typically costs

A first Smokeball integration typically lands in the $20,000–$45,000 range (ex GST) for a V1 build, depending on how many of the patterns above are in scope and their depth. A single workflow — website intake to matter creation, say — sits at the lighter end; cross-matter partner reporting or a client-facing portal pulling live matter data sits at the heavier end. Build timelines are usually 8–16 weeks from engagement, with the design phase and firm-side data alignment (matter types, the fields to surface, document-visibility rules) being the longest single workstream. Plan for an ongoing maintenance retainer — typically $500–$1,500/month — covering API change monitoring, hosting, security and light support.

Common questions

Do we need to leave Smokeball to do this? No. A custom integration works alongside Smokeball, which stays the source of truth for matters, time and trust accounting. The integration reads from and writes to Smokeball through its API; it does not replace it.

Is anything to do with trust accounting safe to automate? Trust-accounting touchpoints carry real regulatory weight, so they are approached last and with care — typically read-only reconciliation surfaces rather than anything that moves money. The integration is built to support the firm in meeting its own trust-accounting and confidentiality obligations, not to take them on.

How is client and matter data protected? Australian data residency, least-privilege access scoped to only the data the integration needs, and audit logging — so a client-facing portal exposes exactly what the firm intends and nothing more.

Will it break when Smokeball updates? APIs change, so the maintenance retainer covers monitoring Smokeball API changes and keeping the integration current. The build itself uses idempotent, retry-safe patterns, so a transient failure does not corrupt matter data.

What size firm does this make sense for? Usually around 4–5 fee earners, a regular flow of new matters across more than one practice area, and a practice manager already feeling the cost of the manual operational layer. Below that, the volume rarely repays the build.