FigsFlow API and webhooks for UK accounting firms
Read the same clients, jobs and documents your team opens every morning — and receive a signed webhook the second one of them moves. No overnight export. No staging spreadsheet. No second copy of the truth quietly disagreeing with the record a partner is reading in a client meeting.
{
"event": "engagement_letter.signed",
"occurred_at": "2026‑08‑25T09:14:02Z",
"data": {
"engagement_id": "eng_…",
"client_id": "cli_…"
}
}
Built for the stack a UK practice 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.
Register data, filing deadlines and ID verification status.
Signed, retried, replayable. Subscribe to what matters.
Cursor-paged collections, machine-readable errors.
No certified connector. Reachable as a generic HTTP call.
No published app. Wire it yourself against the endpoints.
The tax calendar, including the MTD for Income Tax cycle.
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 straightforward half. The difficult half is knowing something changed, proving it arrived, and being able to say who read what — which is where most API integrations for accounting firms quietly fail.
Subscribe to the change, not the schedule
A webhook fires when a letter is signed, a job moves stage, a risk score is set 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.
A credential per integration
Scoped least-privilege, revocable on its own, and attributed on every call — so “which system read this client?” has an answer during a file review.
A delivery log a partner can read
Integration health lives in the product, not in a developer’s 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
Metadata and a pointer into your own SharePoint — never a second copy of a client file to secure and retain under your UK GDPR policy. The audit trail stays authoritative.
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 portal 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 Teams 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 by a client.
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 operations manager checks. An integration nobody watches is an integration nobody trusts.
Against the things UK firms usually do instead
A scheduled export is perfectly fine for a monthly board pack. The question is what happens when a client rings at three o’clock on a Tuesday — and whether anyone would notice if the answer were wrong.
Where a first-party connection already exists — Microsoft 365, email, Xero, QuickBooks Online, Stripe, GoCardless — 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 enquiry 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 engagement 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.
- Pairs with jobs, tasks and deadlines.
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 Ltd",
"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": "gocardless"
}
}The things developers ask first
A REST and JSON interface to your firm’s practice record — clients, engagements, jobs, documents, invoices and people — with signed webhooks that fire when any of them changes. It is built for UK accountants, bookkeepers and tax advisers who want their own dashboards, onboarding automations or internal tools reading live data instead of a stale export.
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 busy January.
Delivery is retried on an exponential backoff across several 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 under UK GDPR.
It should not. Where a first-party connection exists — Microsoft 365, email, Xero, QuickBooks Online, Stripe, GoCardless — 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.
Availability and any associated cost depend on your plan. Current plan detail sits on the FigsFlow UK pricing page, and if you tell us which integration you have in mind on a demo call we will say honestly whether the API is the right tool or whether an existing connection already covers it.
Stop reconciling a copy of your own data
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 is issued with your credentials.