Pulling a firm's TaxDome client records into its own systems

Every TaxDome client account carries a working file: tax organizers and their answers, the documents a client scanned in and the documents the firm shared back, signed engagement letters, an invoice list with payment history, message threads, and a checklist of open tasks. The portal is where an accounting firm and its clients meet, so the data behind it is the firm's own client record — it just lives in someone else's UI. A firm that wants those records inside its tax software, document system or general ledger needs a consented way to read the portal account and keep reading it. That is the job this page scopes.

What the portal holds, surface by surface

These are the surfaces the app actually exposes to a logged-in account, named the way TaxDome names them.

Routes in

Three routes genuinely apply here. They differ in how much structured detail comes back and in how much setup the build needs.

Authorized interface integration of the portal session

The portal renders every surface above for an authenticated account. Working from the session and token chain that the app itself uses, the integration reads organizer responses, walks the document folders, lists invoices and payments, and follows message threads. Effort is moderate — the session establishment, the second-factor handling, and folder pagination are the real work. We set up the authorized session with the firm during onboarding. This route returns the structured detail, so it is the one we would build the connector around.

Firm- or client-consented account access

Where the model is "mirror this client's data with their explicit consent," we operate the portal as the consented account and scope the pull to exactly that account's surfaces. Same data, narrower blast radius, per-account consent records. This pairs well with the route above for firms that onboard clients one consent at a time.

Native export as backfill

TaxDome's own tooling exports accounts and contacts to CSV and lets clients download documents from the viewer or list; its documentation also describes Zapier and TaxDome Drive paths for moving documents. That covers a bulk seed of contacts and files. It does not return organizer answers or invoice detail at the field level, so we treat it as a one-time backfill rather than the live connector.

What lands at the end of the build

The deliverable is a working integration for the surfaces a given firm needs, not a report. Concretely, for TaxDome that is:

• An OpenAPI/Swagger specification for the normalized surfaces — organizers, documents, engagement acceptances, invoices and payments, messages and tasks, account roster.
• A protocol and auth-flow report: the invite-link session, the token and cookie chain, and how TOTP two-factor or biometric login is handled in session setup.
• Runnable source in Python or Node.js for the key endpoints — organizer-response pull, document-tree walk with download, invoice and payment fetch, message and task read.
• Automated tests run against a consenting account or a firm-provided sandbox.
• Interface documentation a firm's own engineers can maintain.
• Data-retention and consent guidance keyed to §7216, the FTC Safeguards Rule and GDPR, so the data flow stays inside what the firm's client engagement already permits.

A token refresh and a documents pull, sketched

Illustrative only — exact field names and the second-factor handshake are confirmed during the build against a consenting account, not asserted here.

# 1. Establish the authorized session (firm- or client-consented)
POST /api/auth/session
  { "email": "...", "password": "...", "device_id": "obs-connector" }
-> 200 { "access_token": "...", "refresh_token": "...", "expires_in": 1800 }
-> 401 { "mfa_required": "totp" }      # if 2FA is on, supply the
                                        # firm-authorized TOTP code, then retry

# 2. Walk the two document roots, preserving folder paths
GET /api/documents?folder=client_uploaded&page=1&per_page=100
GET /api/documents?folder=firm_shared&page=1&per_page=100
-> 200 { "items": [ { "id", "name", "path", "size", "uploaded_at" } ],
         "next_page": 2 }

# 3. Refresh before expiry so a scheduled sync does not drop the session
POST /api/auth/refresh   { "refresh_token": "..." }
-> 200 { "access_token": "...", "expires_in": 1800 }

# Errors we handle explicitly:
#   401 mfa_required  -> resupply second factor, do not loop
#   429 rate limited  -> backoff, resume pagination from next_page
#   409 account_switch-> re-scope to the selected linked account id
      

The regulated bit is the tax-return information

TaxDome holds tax-return information on behalf of accounting and tax firms, and that specific category is governed. IRC §7216 makes it a criminal matter for a tax-return preparer to disclose or use a client's return information without the client's prior written consent — consent that cannot be retroactive, with the exceptions set out in Treasury Regulation §301.7216-2 (for example, disclosure within the US to process or e-file the return). The practical effect on an integration: the data flow has to sit inside consent the firm already holds from its client, or inside scoped written consent obtained for it, and disclosures get logged. We build to that.

Tax-prep firms are also "financial institutions" under the FTC Safeguards Rule, so the connector is delivered with encryption in transit and at rest, access controls, MFA-aware sessions and the access logging a written information security program expects; the FTC's published civil-penalty figure for violations was about $51,744 per violation per day as of 2024, which is why the logging is not optional. EU client data is handled under GDPR using the Standard Contractual Clauses TaxDome documents in its Data Processing Addendum. Where a firm requires it, the work runs under NDA, with access minimized to the fields actually needed.

What this build has to get right

A few things about TaxDome specifically shape the engineering, and we account for each:

• Linked accounts. A single login can front several accounts — a couple, or a client running more than one business. We enumerate every linked account and key records by account id so two entities never collapse into one record set.
• The second factor. TOTP two-factor and Face ID or fingerprint are optional but common. We design session setup around the firm- or client-authorized second factor so a scheduled sync re-establishes the session without a person re-authenticating on every run.
• The folder split. Client-uploaded files and firm-shared files are different areas, and organizer attachments are different again. We carry that structure through rather than dumping everything into one folder, because the firm's filing depends on it.
• Front-end drift. Portal markup and endpoints change. We keep a check that flags when a surface shifts and refresh the mappings as part of ongoing maintenance, so a sync fails loud rather than silently returning stale data.
• Data region. TaxDome stores US and Canadian firm data in their respective countries. We keep the pull and any cache inside the firm's region and minimize what is read.

Where firms put this to work

• Mirror signed engagement letters and their acceptance timestamps into the firm's onboarding system as clients accept new work.
• Reconcile TaxDome invoices and payment history against the general ledger on a nightly pull.
• Move completed organizer responses straight into the tax-prep workflow so intake is not rekeyed.
• Archive the full document tree — client-uploaded and firm-shared — into the firm's document system with paths preserved and §7216 disclosure logging attached.

Interface evidence

Screenshots from the app listing, used to confirm the surfaces above. Tap to enlarge.

Where TaxDome sits among practice-management tools

Firms rarely run one tool, and a unified integration usually has to reach more than one. Same-category products an integrator runs into:

• Canopy — practice-management suite with a client portal, document handling and billing for accounting firms.
• Karbon — workflow and email-driven practice management with client collaboration across multi-step engagements.
• Financial Cents — lighter practice-management and client-portal tool aimed at small firms and solo preparers.
• Client Hub — bookkeeping-focused practice management with a client portal and QuickBooks and Xero ties.
• Jetpack Workflow — workflow standardization and recurring-task tracking for accounting teams.
• Uku — modular practice management with billing and client communication for accounting firms.
• Mango Practice Management — time, billing and document-exchange portal for accounting and CPA firms.
• Senta — workflow automation and a secure client portal for accountants and bookkeepers.

Questions firms ask before we start

The portal splits client-uploaded files from firm-shared files — are those separate surfaces you map?

Yes. TaxDome keeps client uploads and the firm-shared documents folder as distinct areas, alongside organizer responses and message attachments. We treat each as its own source so a sync mirrors the firm's folder structure instead of flattening everything into one pile.

Login is an invite link plus optional 2FA and Face ID — does that change how the integration runs?

The session is established with credentials the firm or client authorizes. Where TOTP two-factor or biometric login is enabled, the build accommodates the second factor during session setup, and we keep the access and consent records that the firm's security program expects.

We have EU clients as well as US tax clients — does the regulatory side differ per account?

It does. US tax-return information falls under IRC Section 7216 and the FTC Safeguards Rule; EU client data falls under GDPR with the Standard Contractual Clauses TaxDome documents in its DPA. We scope consent and data minimization to whichever applies to a given account and log disclosures accordingly.

Can invoices and payment history stay in sync, not just get pulled once?

Yes. A scheduled pull against the invoices and payments surface keeps a firm's external ledger current; we set the cadence inside the consent window so the connection does not lapse without warning. The first working build runs about one to two weeks.

Source-code delivery starts at $300 — runnable connectors for the TaxDome surfaces above, with the API specification, protocol report, automated tests and interface documentation, billed only after delivery once the firm has the working build in hand. The pay-per-call alternative is a hosted endpoint with no upfront fee, charged per request. Tell us the firm's setup and what you need out of the portal at /contact.html; a first working build runs about one to two weeks, and access and consent are arranged with you as part of the engagement.

What was checked, and against what

The surfaces here were read from TaxDome's own product and help pages and its App Store and Google Play listings; the regulatory frame from the IRS Section 7216 information center and the FTC's Safeguards Rule guidance; the security posture from TaxDome's published SOC 2 policy (TaxDome also reported completing a SOC 2 Type I examination in 2024, per CPA Practice Advisor). Checked May 2026.

• IRS — Section 7216 information center
• FTC — Safeguards Rule: what your business needs to know
• TaxDome — SOC 2 policy
• TaxDome Client Portal — App Store listing

OpenBanking Studio · integration desk. Interface mapping reviewed 2026-05-19.