API release notes: version 2

Release date: November 12, 2026. Version 2 is a new API platform that runs beside the existing version 1 APIs. You can keep current integrations running and adopt version 2 when you are ready. For changes to version 1, go to the API release notes: version 1 changes.

• Overview

• Key highlights

• What's new

• Improvements and enhancements

• Changes for existing integrations

• Getting started

• Known limitations

Overview

This release introduces version 2 of the IRIS Firm Management API. It gives integration partners and in-house developers one predictable way to work with the records that run a practice: clients and contacts, jobs, people, time and expenses, billing and cash, and the reference data those records depend on.

Version 2 does not replace version 1. Existing version 1 integrations continue to work. Version 2 uses its own address prefix, /v2, and its own request and response contract. You choose which new work moves to version 2, and when.

The benefit is consistency. List, read, create, and update follow the same patterns across business areas. Errors come back in the same shape. You can guard updates so two integrations do not overwrite each other. You can page large sets of records, and you can query or watch several areas for change instead of copying them in full.

Key highlights

• Version 2 runs beside version 1. You do not need to rebuild an existing integration.

• You can create, read, and update clients, jobs, and staff through one flat, predictable contract, including the fields your firm marks as required.

• You can automate time, expenses, billing, and cash collection through the same platform, from recording work to processing a cash batch.

• Lists are paged. For clients and jobs, you can also ask for rows that changed after a marker you store, which keeps synchronization smaller.

• A query interface is available for reporting-style reads, and you can manage webhook subscriptions in version 2.

What's new

Clients and contacts

What's new. You can maintain clients and contacts, link contacts to a client, and keep notes against a client. Related lists such as client groups, types, and statuses are available in the same style.

Why it matters. Onboarding a client no longer needs a different pattern for the client, the people who belong to it, and the notes on the relationship.

What you can do. Create a client, attach the billing contact, and record an onboarding note. Before you send the create, ask version 2 which fields that firm requires. The payload then matches the firm's own form rather than a guessed list.

Jobs

What's new. You can maintain jobs, their budgets, notes, and the lists that classify them, such as job type and status. You can limit a job list to jobs that are ready for billing.

Why it matters. Opening work, checking a budget, and finding what is ready to bill can sit in one integration instead of a mix of exports and manual checks.

What you can do. Open a job for a client, set the fee and the target end date, then later list only the jobs that are ready to bill. You can read due dates and tracking steps to show progress. Those tracking reads do not update the schedule.

People and the practice

What's new. You can maintain staff and the structure around them: offices, departments, partners, managers, supervisors, and jurisdictions. Staff notes are available, as are dated charge rates for a person.

Why it matters. An integration that provisions people, or that needs the right rate for a piece of work, can read that from the API instead of a separate extract.

What you can do. Add a member of staff, record a note, and look up the charge rates that apply to them. Charge rates are read-only in this release.

Time and expenses

What's new. You can read time recorded against work, and you can record and maintain expenses. Expense types and charge accounts are available as supporting lists.

Why it matters. Time capture systems and expense tools can exchange records with the product without a bespoke file for each firm.

What you can do. Pull time transactions for a period, or post an expense against a job. Time transactions are read-only in this release. Version 2 does not create time entries.

Billing and cash

What's new. You can work with draft bills, cash batches, the items and allocations on a batch, and the history of how receipts were applied. Commission tracking is included.

Why it matters. A finance integration can follow a receipt from the batch through to allocation, and can look up the bills those amounts relate to. It uses the same error and paging patterns as the rest of version 2.

What you can do. Open a cash batch, add items, and ask the API to process or approve the batch. You can also read how a receipt was allocated, and retrieve bill documents and allocations where you need them for a downstream ledger A ledger is a book or collection of accounts in which account transactions are recorded. Each account has an opening or carry-forward balance, and would record each transaction as either a debit or credit in separate columns, and the ending or closing balance..

Reference data

What's new. The lists that other records point to are available in version 2. They include currencies, countries, offices, departments, industries, prefixes and suffixes, note types, contract types, and similar firm setup.

Why it matters. Integrations can resolve a code to the identifier the product expects, instead of hard-coding values that differ by firm.

What you can do. Load currencies and offices once, cache them, and use those identifiers when you create a client or a job.

Search, synchronization, and notifications

What's new. Most of these areas have a query feed for filtered, sorted reads. Clients and jobs also accept a since marker on the ordinary list, so you can ask for rows that changed after your last synchronization. You can register and maintain webhook subscriptions through version 2. You can read operational alerts, list the report catalog, and generate a report for the signed-in member of staff.

Why it matters. You can keep a local copy current without downloading the whole firm each night. You can also get notified of selected events instead of polling for them.

What you can do. Query open jobs for one client, store the latest change marker from a client list, and register a webhook subscription for an event your product already handles.

Improvements and enhancements

Version 2 uses one set of integration patterns, so a technique you build for clients also applies when you move on to jobs, staff, or cash.

• Safer updates. A read returns a version token. Send it back when you update or delete. If someone else has changed the record, the API rejects the write instead of saving over their change. A conditional read can also tell you the record is unchanged, so you do not need to download it again.

• The same errors everywhere. Failures return a code, a short description, and a support reference. Validation, missing records, conflicts, and stale updates each have their own outcome, so you can share retry and logging logic.

• Partial updates. Send only the fields you intend to change. A full replace remains available when you want to set every field explicitly. A replace clears omitted fields, so use a partial update unless you mean to replace the record.

• Several records in one call. You can send creates and updates as a batch on the same address as a single record. Each row comes back with its own success or failure, so one bad row does not hide the result of the others.

• Firm-specific required fields. For clients, jobs, and staff, you can ask which fields the firm requires before you build a create or replace. Those paths match the flat fields on the record itself.

Changes for existing integrations

Version 1 stays in place. This release does not withdraw it, and you do not need to move an existing caller to version 2.

Version 1 addresses are unchanged. A client integration that already calls the version 1 client routes can keep doing so. You reach version 2 only through addresses that start with /v2.

Version 2 is a new contract, not a renamed copy of version 1. Field names, batch behavior, and error bodies follow the version 2 rules above. Point new work at /v2. Leave existing version 1 calls where they are until you choose to change them.

Nothing in this release removes permission to call version 1. Version 2 operations have their own permissions. Access that already works for version 1 does not automatically include version 2. Confirm the permissions on the token you use for /v2.

Getting started

Version 2 is for developers, integration partners, and technical consultants who connect other systems to IRIS Firm Management.

You need an OAuth 2.0 access token for the firm, sent as a bearer token, and permission for the area you are calling. Health checks do not need a token. GET /v2/ping confirms the API is reachable, and GET /v2/status reports whether its dependencies are healthy.

Once you have a token, a first read is a paged client list:

GET /v2/clients?limit=25
Authorization: Bearer {access-token}

The version 2 OpenAPI document, published with the API, is the full request and response contract. Use it for field lists, permissions, and examples. For the link, go to IRIS Firm Management APIs. These notes describe what the release is for. They are not the field reference.

Known limitations

• Time transactions, staff charge rates, operational alerts, and resource-scheduling tracking are read-only. This release does not create time entries or edit those rates and tracking steps.

• A batch of creates or updates is limited to 50 records in a single request.

• List operations are paged. Where this pattern is used, the page size defaults to 25 and cannot exceed 2,000.

• Required fields for a client, job, or staff member depend on the firm's own form. A payload that worked for one firm can be rejected by another until you include that firm's required fields.

• General ledger export remains on the existing API. It is not part of the version 2 surface in this release.

• Webhook management in version 2 registers subscriptions with the same notification service as the existing webhooks API. It does not add a second, separate notification platform.

• Where a quota applies, the gateway can return 429 Too Many Requests. Treat that as a signal to slow down and retry, not as a fault in the record you sent.