Your practice data, the moment it changes
Read the same clients, jobs and documents your firm works from — and get a signed webhook the second one moves. No overnight export. No staging spreadsheet. No second copy of the truth quietly disagreeing with the record your partners are reading.
{
"event": "engagement_letter.signed",
"occurred_at": "2026‑08‑25T09:14:02Z",
"data": {
"engagement_id": "eng_…",
"client_id": "cli_…"
}
}
Built for the stack an accounting firm already runs
Entra ID SSO, Outlook, Teams, SharePoint and Graph.
Documents stay in your tenant. The API returns pointers.
The ledger stays where it is; billing runs through it.
Collection rails you choose. Payment events hit the record.
For practices that do not run on Microsoft 365.
Signed, retried, replayable. Subscribe to what matters.
Cursor-paged collections, machine-readable errors.
No built-in connector. Reachable as a generic HTTP call.
No published app. Wire it yourself against the endpoints.
Drake, Lacerte, ProSeries and CCH Axcess do not connect.
Figures describe intended behaviour of the API as designed. Exact limits are confirmed in the published reference.
Everything an integration needs, and nothing it has to work around
Reading data is the easy half. The hard half is knowing something changed, proving it arrived, and being able to say who read what — which is where most practice integrations quietly fail.
Subscribe to the change, not the schedule
A webhook fires when a letter is signed, a job moves stage or an invoice settles. Every payload is signed so you can verify the sender, carries an id you can de-duplicate on, and is retried on a backoff if your server has a bad minute.
Credentials per integration
Scoped least-privilege, revocable on their own, and attributed on every call — so “which system read this client?” has an answer.
A delivery log a partner can read
Integration health lives in the product, not in your logging stack. When something is behind, the firm sees it without asking the person who built it — and can replay a failed delivery without waiting for the next retry.
Documents by reference
You get metadata and a pointer into your own SharePoint — never a second copy of a client file to secure and retain.
Cursor pagination
Collections page on a cursor rather than an offset, so a list cannot shift underneath you mid-read.
Errors you can branch on
A machine-readable code plus a human sentence. A 429 tells you exactly how long to wait instead of making you guess.
Versioned, with notice
Breaking changes ship behind a version. You are told before anything you depend on is retired.
From a signature in the office to a job in your system
Five stops, no copies. The change happens on the record, the event carries it, and whatever your system does next is visible back inside FigsFlow rather than buried in a log only you can read.
Something changes
A client signs an engagement letter in the portal. A real action, on the record the firm works from.
The event is raised
Recorded once, with an id to de-duplicate on and a timestamp to order by — whether or not anyone is listening yet.
+12msYour endpoint is called
Signed so you can verify it. Retried on a backoff if you are down, and logged either way, so failure is never silent.
+840msYour system acts
Creates the folder set, updates the warehouse, posts to a channel — and reads back anything else over the same API.
+1.2sThe firm sees it landed
Delivery health is a screen in the product, so “the automation is behind” is noticed rather than reported.
liveTwo people, one console, different halves
A developer wants the request, the response and the reason it failed. A partner wants to know whether the thing that was supposed to happen happened. Both open the same screen.
Delivery health
Every attempt, its response code and how long it took. Replay a failed delivery by hand without waiting for the next retry.
Request explorer
Send a real call against your sandbox and read the response beside it — no local setup to get a first result.
Traffic and limits
Where your calls go, which resources are busiest, and how close a credential is running to its ceiling.
Access & scopes
Which integrations exist, what each can reach, when it was last used, and one button to revoke it.
# illustrative — shapes confirmed in the published reference curl "https://api.example/v1/jobs?stage=in_review" \ -H "Authorization: Bearer <token>"
{
"data": [
{ "id": "job_…", "stage": "in_review" }
],
"has_more": false,
"next_cursor": "cur_…"
}
What integrating actually looks like
Not a six-month programme. Most firms are live on one useful job inside a fortnight, because the first integration should be small enough to prove and boring enough to trust.
Issue a credential
Scoped to exactly what the job needs. Sandbox first — nothing touches live client data while you are still reading the shapes.
Read something real
One GET against your own sandbox, in the explorer. If the shape does not fit what you are building, better to find out now than in week six.
Subscribe to one event
Pick the single step people forget. Make the handler idempotent, point it at staging, and watch the delivery log until it is dull.
Hand it to the firm
Put connection health on a screen an ops manager checks. An integration nobody watches is an integration nobody trusts.
Against the three things firms usually do instead
A scheduled export is genuinely fine for a monthly board pack. The question is what happens when somebody asks at 3pm on a Tuesday — and whether anyone would notice if the answer were wrong.
Where a first-party integration already exists — Microsoft 365, Xero, QuickBooks Online, Stripe — use it instead. It is supported, maintained, and better than anything you would build against the API.
What you can read, write and listen for
Six core resources, each scoped separately for read and write. Pick one to see what it carries and which events it raises.
Clients
The party record every other object hangs from — the same one your team opens in the product, with contacts nested rather than split across a second endpoint.
- Read and write. Create a client from your own onboarding form without anyone re-keying it.
- Events: created, updated.
- Filterable by owner, status and last activity.
Engagements
Scope and fee, linked to the letter that evidences them. Read-only on purpose: an engagement should be created by the process that prices and signs it.
- Read only. Writes happen through proposals and letters, where approval applies.
- Events: created, signed.
- Links to the signed document and the jobs it released.
Jobs
Work in progress, with the stage the firm actually uses. The busiest resource for most integrations, and the one worth subscribing to first.
- Read and write. Move a stage from your own tooling if that is where the work happens.
- Events: opened, stage_changed, closed.
- Filterable by stage, owner, deadline and client.
Documents
Metadata and a pointer into your own SharePoint — deliberately not file content. The API should not become a second place your client files live.
- Read only. Bytes stay in the tenant your firm already governs.
- Events: filed.
- Returns the SharePoint location, not a copy of the file.
Invoices
Raised and settled, as the firm sees them. The ledger stays in Xero or QuickBooks — this is the practice-side view, not a replacement for your accounts system.
- Read only. Billing runs through your connected ledger.
- Events: raised, paid.
- Useful for WIP dashboards and collection chasing.
{
"data": [{
"id": "cli_…",
"name": "Ridgeline Foods Inc.",
"owner": "usr_…",
"contacts": [{ "role": "primary" }]
}],
"has_more": false
}{
"event": "engagement.signed",
"data": {
"engagement_id": "eng_…",
"released_jobs": ["job_…"]
}
}# move a job from your own tooling { "stage": "in_review", "note": "prepared, awaiting partner" }
{
"id": "doc_…",
"kind": "engagement_letter",
"location": {
"provider": "sharepoint",
"path": "/Clients/…/2026"
}
}{
"event": "invoice.paid",
"data": {
"invoice_id": "inv_…",
"settled_via": "stripe"
}
}The things developers ask first
No, and you should design for that. Deliveries are retried independently, so a retry of an earlier event can land after a later one. Sort on occurred_at and make your handler idempotent using the event id. We would rather state this plainly than let you discover it during a close.
Delivery is retried on an exponential backoff across six attempts before the event is marked failed. Nothing is discarded while attempts continue, every attempt is written to the delivery log, and you can replay any failed delivery by hand rather than waiting for the schedule.
No — by design. Documents return metadata and a pointer into your own SharePoint. Your firm already governs retention and access there, and duplicating client files into a second store would mean securing, retaining and eventually disposing of them twice.
It should not. Where a first-party connection exists — Microsoft 365, Xero, QuickBooks Online, Stripe, GoCardless, Gmail — it is maintained by us and will not drift when either side changes a field. The API is for the part no supported integration covers.
Not today. There is no published app or certified connector for either. Both can call the API as a generic HTTP request, but you are wiring and maintaining that yourself — so treat it as a custom integration rather than a supported one.
No. There is no app marketplace, partner directory or distribution mechanism. Credentials are issued to a firm, and what you build runs against your own firm’s data.
Breaking changes ship behind a version, and anything you depend on is announced before it is retired. Decide who in your firm watches for deprecation notices before you have forty integrations, not after.
Stop reconciling a copy of your own data
API access is opening with our founding-customer group. Tell us the one job you would automate first, and we will tell you honestly whether the API is the right tool for it — or whether a built-in connection already covers it.
Full reference documentation publishes with general availability.
Start Smarter. Grow Faster.
From proposals to pricing, streamline every step with automation designed particularly for accountants, bookkeepers and tax advisers.