The ActionStep webhook architecture most Australian law firms don't realise is supported

Quick answer: ActionStep supports REST hooks (webhooks) for 22 event types, including step changes, action updates, file note creation, data collection record updates, and participant changes. This is documented in the official ActionStep developer documentation but is repeatedly mis-stated by partner consultancies as “not supported” or “not real-time.” The architecture for a custom client portal that uses these webhooks to surface live matter status to brokers, mortgage managers, conveyancing clients, or developer-clients is straightforward and runs at sub-second latency. This piece walks through the supported events, the integration patterns we deploy, and where a custom portal compares favourably to the bundled ActionStep client portal. For law firm portal projects where the bundled portal isn’t enough.

ActionStep is one of the two dominant practice management platforms in the Australian legal market (Leap being the other) and the platform of choice for many conveyancing, family law, and commercial property firms because of its workflow customisation depth. The platform ships with a client portal — usable for the simplest case where the firm wants to give clients a basic view of their matter — but the bundled portal hits its ceiling quickly. Firms with multi-party matters (brokers + mortgage managers + developer-clients on a single transaction), domain-based access requirements, custom branding, real-time status visibility, or party-specific data views consistently outgrow it.

What we’ve found repeatedly across recent ActionStep portal projects is that firms have been told by their ActionStep partner consultancy that real-time data isn’t available from the platform — that any custom portal would be limited to polling the API every few minutes, with the inevitable lag between something happening in ActionStep and the client portal reflecting it. This is incorrect. The ActionStep API supports REST hooks for 22 distinct event types, documented publicly, with sub-second event delivery to a subscribed endpoint.

The implication matters. A custom portal built on the webhook architecture surfaces step changes, document availability, file note publication, and participant updates to clients in real time. The bundled ActionStep portal doesn’t. The competitive position of the firm’s service offering — particularly in conveyancing where mortgage managers and brokers expect modern client-portal experiences — benefits materially from being able to say “our portal updates the moment something changes.”

This piece walks through the architecture we use, the event types worth subscribing to, and the patterns that turn a webhook subscription into a production-grade client portal.

What the ActionStep webhook system actually supports

Per the published documentation, the ActionStep REST hooks API supports 22 events. The ones that matter for client-portal use cases are:

• ActionCreated, ActionUpdated — a new matter is opened, or an existing matter’s details change. The webhook fires the moment the change is committed in ActionStep.
• StepChanged — the matter moves from one workflow step to another. For a conveyancing client wanting to know “are we ready to settle yet?” this is the headline event.
• ActionDocumentCreated, ActionDocumentUpdated, ActionDocumentDeleted — documents are added to a matter, modified, or removed. For client portals that surface document availability (or downloadable documents for developer-clients), these events drive the document UI in real time.
• ActionParticipantAdded, ActionParticipantDeleted — the parties on a matter change. A new mortgage manager is added; a broker is removed; the developer-client’s accountant is added as an additional party. The portal’s access scopes update accordingly.
• DataCollectionRecordUpdated, DataCollectionRecordDeleted, DataCollectionRecordValueUpdated — the structured data captured on the matter changes. ActionStep’s data collection model is where firms typically store the matter-specific information that’s most useful to surface in a client portal (special conditions, settlement requirements, outstanding items). When those fields update, the portal reflects the change.
• DisbursementCreated, DisbursementUpdated — matter disbursements are recorded. Useful for client-facing billing visibility.
• FileNoteCreated, FileNoteUpdated — file notes are added to the matter. Many firms use a convention where file notes with a specific prefix (e.g. “PORTAL: ”) are surfaced to the client portal; the webhook fires the moment the file note is saved.
• ParticipantCreated, ParticipantUpdated — the contact records that underpin the participant assignments change. Less commonly used in portal flows but available.
• TaskCreated, TaskUpdated, TimeEntryCreated, TimeEntryUpdated — the operational layer of the matter. Useful for internal admin views; less commonly exposed to clients.

The event payload includes the action ID, the event ID, and the relevant entity data. The webhook is a POST to the subscribed callback URL with a JSON body.

The subscription model is per-user and per-event: a user account in ActionStep registers a REST hook against an event type with a target URL. Most production deployments use a service user (a dedicated ActionStep user account with appropriate scoped access) as the webhook subscriber, with the firm’s broader user accounts unaffected.

The architecture for a client portal that uses these events

The pattern we deploy when building a custom ActionStep client portal:

• Webhook receiver service with endpoints for each subscribed event type. Each endpoint verifies the request, persists the event payload to a queue, and returns 200 immediately. This is the pattern described in webhook patterns that don’t fall over — receipt and processing are separated.
• Event processor worker that pulls events from the queue and updates the portal’s database with the relevant matter state. For a StepChanged event, the worker looks up the matter in the portal’s database, updates the current step field, and triggers any downstream notifications.
• Portal database that holds a read-optimised view of the data the portal renders. The portal doesn’t query the ActionStep API on every page load — it reads from its own database, which the webhook processor keeps current. This makes the portal fast (no per-page-load API call) and resilient (the portal keeps working even if ActionStep is briefly unreachable).
• Reconciliation job that runs nightly (or on a faster cadence for high-volume firms), queries ActionStep’s API for matter state changes since the last run, and processes any events the webhook layer missed. Webhooks are reliable but not 100% — the reconciliation job is the safety net.
• Client portal application — the buyer-facing surface that brokers, mortgage managers, conveyancing clients, or developer-clients log into. The portal reads from its own database, which is kept current by the webhook layer.

The flow on a step change:

1. A paralegal updates a matter step in ActionStep
2. ActionStep fires a StepChanged webhook to the portal’s endpoint within seconds
3. The webhook receiver verifies, persists the event, returns 200
4. The event processor reads the event, fetches the matter’s current state from ActionStep’s API (the webhook payload is a notification; the API call gets the current full state), updates the portal database
5. Any client currently viewing that matter sees the update on their next page refresh, or via a server-sent event / WebSocket push for live screens

End-to-end latency from paralegal action to client visibility is typically sub-second on the webhook path. The bundled ActionStep portal, by comparison, is generally slower — particularly if the firm hasn’t configured it actively. Even a one-second client-visibility win matters for a firm pitching against larger competitors on client-experience grounds.

The party-scoping model that the bundled portal can’t express cleanly

For firms with multi-party matters — conveyancing is the canonical case, but commercial property and family law have similar shapes — the most important capability of a custom portal is the party-scoping model.

ActionStep’s data model has a clean primitive for this: each matter has a list of participants, each with a role (client, party, additional party). The webhook layer keeps the portal’s database current as participants are added or removed. The portal application uses this to scope what each logged-in user can see.

The pattern that’s genuinely useful:

• Brokers logged into the portal see only the matters they are a party to. Their dashboard shows their active matters, with the current step, settlement date, and outstanding items per matter.
• Mortgage managers see only the matters their firm is a party to. Domain-based access (the firm logs in via shared email domain) means a new mortgage manager from a known firm gets immediate visibility into the firm’s matters without per-user setup.
• Developer-clients see only the matters where they are the client. Their view emphasises documents and settlement progress rather than detailed step-by-step status.
• Internal staff (paralegals, partners) see the firm-wide view, with reporting across matters and parties.

The bundled ActionStep portal supports a basic version of this but with limited customisation of the per-party experience. The custom portal can render genuinely different UIs for each party type, with the depth of information appropriate to their role in the matter.

Where the bundled ActionStep portal is still the right answer

We’re not arguing that every firm needs a custom portal. The bundled ActionStep client portal is the right answer when:

• The firm has a single primary client per matter and the portal’s job is to give that client a view of their own matter. Conveyancing firms with single-party matters (own-home purchases) often don’t need the multi-party complexity.
• Brand and UX are not differentiators in the firm’s competitive position. For some firms (sole practitioners, regional firms where the relationship is the value), the basic bundled portal serves the function without the custom build.
• The data the firm needs to surface is fully covered by the bundled portal’s out-of-the-box capability. If matter status, document download, and basic communication is enough, the custom portal is over-investment.
• The firm doesn’t have the internal operational scale to justify the build cost. A four-person firm doing twenty matters a month is unlikely to recover the cost of a custom portal against the marginal value over the bundled one.

The honest test is whether the bundled portal’s limitations are blocking specific commercial outcomes — competitive wins, paralegal time savings, client experience differentiation. If yes, the custom build pays back. If no, the bundled portal is the right answer.

What the build looks like in practice

A custom ActionStep client portal for an Australian firm running brokers, mortgage managers, and conveyancing clients typically lands in the $25,000–$45,000 range for a V1 build, depending on the number of party types, the depth of the data being surfaced, and the integration scope.

V1 typically includes:

• ActionStep API integration with read access scoped to the portal’s use case
• Webhook subscriptions for the events that drive the portal’s UI (StepChanged, ActionDocumentCreated/Updated, FileNoteCreated/Updated, DataCollectionRecordValueUpdated, ActionParticipantAdded/Deleted)
• Custom authentication, including domain-based access for shared-domain firms (mortgage manager companies)
• Party-scoped matter views per user type
• Document download surfacing (using the ActionDocumentCreated/Updated events to keep the available-document list current)
• Email digest notifications with per-user opt-in (daily, weekly, or per-event cadence)
• Mobile-first responsive design and PWA install
• Hosting, deployment, monitoring, and ongoing maintenance

V2 commonly adds upload flows (mortgage manager document uploads, with file-type validation and audit logging), additional party types, integration with the firm’s accounting layer, or internal admin reporting beyond what ActionStep’s built-in reporting covers.

The build timeline for V1 is typically 12–16 weeks from engagement, with the longest single workstream being the design phase and the firm-side data alignment (confirming the step taxonomy, the data collection fields to surface, and the document-visibility rules per party type).

The Vallada question

The recurring framing we’ve heard from firms is that their ActionStep partner consultancy has told them real-time data isn’t available. Per the published documentation, this is incorrect. The 22-event REST hook system is documented, supported, and used in production by ActionStep partners (Perfect Portal being one publicly-listed example on ActionStep’s own integrations directory).

The most charitable reading is that the partner consultancy is referring to a different product capability — perhaps the internal real-time reporting features rather than the webhook API. In any case, the architecture we deploy is built on the REST hook events documented at docs.actionstep.com/webhooks and the production behaviour matches the documented event types, payloads, and delivery semantics.

If a firm has been told their custom portal would be limited to polling-based status updates, the architecture in this piece is the counter-evidence. The webhook-driven pattern is supported, documented, and production-grade.

Common questions

Are the ActionStep webhooks reliable enough for a production portal? Webhooks are reliable enough to depend on as the fast path, not reliable enough to depend on as the only path. The robust architecture combines webhooks (sub-second event delivery) with a slower reconciliation job (nightly poll of changed records as the safety net). This is the same pattern we describe in webhook patterns that don’t fall over.

How do I subscribe to ActionStep webhooks? The subscription is via the /api/rest/resthooks endpoint, POSTing the event name and target URL. The subscription is per-user and per-event; most production deployments create a dedicated service user with appropriate scoped access and register hooks against that account. The published documentation at docs.actionstep.com/webhooks walks through the registration flow.

What’s the difference between this custom portal and the bundled ActionStep client portal? The bundled portal is a generic UI over the same data, with a basic per-client view. The custom portal lets you build a party-specific experience (different UI for brokers, mortgage managers, developer-clients), domain-based firm access, real-time status updates via webhooks, custom branding, and integration with the rest of the firm’s stack (accounting, internal admin tooling). The bundled portal is the right answer for simple cases; the custom portal earns its place when the bundled one’s limitations are blocking specific commercial outcomes.

Can I use the ActionStep API access ActionStep gives partners? ActionStep maintains an API approval process for new integrations. For a single-firm internal portal (the firm builds the integration for their own use), the approval is typically straightforward with a few-business-day turnaround. For a multi-tenant product (an integrator builds the portal to resell to many firms), the approval process is more involved and includes a review of the integration architecture. The published documentation at docs.actionstep.com covers the request process.

What about LEAP, Smokeball, or Clio? LEAP, Smokeball, and Clio each have their own API and webhook stories — we’ve written about LEAP integration patterns and Smokeball integrations separately. The high-level architecture (webhook-driven portal with reconciliation safety net) is similar across the platforms; the specific event types and subscription mechanics differ. The principle — build the portal’s data layer to be kept current by the practice-management platform’s real-time events — applies to all four.

Is the ActionStep webhook setup an additional ActionStep cost? No additional licence cost from ActionStep for the webhook subscription itself. The standard ActionStep API access fees apply if your account doesn’t already include them; this is typically a one-time setup charge plus included API usage for most professional plans. The published ActionStep pricing covers the current terms.

What about ongoing maintenance after the V1 build? Plan for ongoing maintenance covering ActionStep API change monitoring, hosting and security updates, light support for user account help, and any feature iteration the firm wants to add. Typical retainer pricing for a portal of this scope is $500–$1,500/month depending on the firm’s usage volume and the breadth of the integration. The retainer is more than the bundled portal’s incremental cost but generally far less than the operational time savings from real-time client visibility.

If you’re an Australian law firm running ActionStep and the bundled client portal isn’t serving your multi-party matters or your competitive positioning, start a project and we’ll walk through the architecture against your firm’s specific party structure and workflow.