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 APIs in the Australian legal software market. 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’s comprehensive and compliant with Australian state-by-state trust rules — 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, Smokeball’s integration surface is among the more accessible.

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

Trust accounting in Smokeball is comprehensive and handles 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.