Skip to main content
After a client’s documents have been ingested, the binder is the place to browse what Filed filed: the uploaded files (subdocuments), the missing-item checklist the run produced, and a search surface across bookmarks, annotations, and document contents. This recipe walks through the real call sequence a reviewer-facing integration uses to browse a client’s binder. Every operation here is documented on the Binder reference page; this recipe sequences them rather than re-documenting the types. Everything uses a workspaceToken (see Authentication) and goes to the single GraphQL endpoint:
The binder belongs to a client, so there is no top-level binder query. Reach it through me { ... on WorkspaceUser { workspace { clients(filters: { ids: [$clientId] }) { binder { ... } } } } }. The workspaceToken already identifies the workspace, so you never pass a workspace ID to read the binder.

1. List the files in the binder

Read binder.subdocuments to list the files Filed filed for the client. This is the most common read against the binder and backs the binder’s Documents screen. Pass a SubDocumentsFilter to narrow to unreviewed, flagged, or files under one parent document; pass null to list everything. See List the files in a binder for the full SubDocumentsFilter arguments.
Save each subdocument’s id. It is the value you pass as documentPath when creating a document message or signing off on a file later.

2. Check the missing-item checklist

Read binder.missingItems to list the missing-document checklist the run produced: forms the run expected to find but did not. Each item carries a severity (CRITICAL, MEDIUM, LOW), a status (OPEN, IGNORED, RESOLVED), and a reason. Filter by status to read only the open items, which is what a reviewer-facing UI shows first. See List missing items for the full BinderMissingItemsFilter argument. binder.openMissingItemsCount gives you the open count without fetching the list, which is the cheap query for a badge.

3. Ignore or restore a missing item

When a reviewer dismisses a missing item, move it from OPEN to IGNORED with ignoreBinderMissingItem. When they change their mind, move it back to OPEN with restoreBinderMissingItem. Both mutations take the missing-item id (from step 2) and a workspaceId: String!, and return the updated BinderMissingItem with its new status.
Unlike the binder read fields, these two mutations take the workspaceId explicitly. Use the same workspace ID the workspaceToken was issued for.
To undo, call restoreBinderMissingItem with the same id and workspaceId; the item’s status returns to OPEN.
After either mutation, refetch the List missing items query so the open count and the list agree. The web app optimistically updates openMissingItemsCount in its cache, then refetches to confirm.

4. Search the binder

Read binder.search to search across bookmarks (subdocuments by file name, issuer, type, or category), annotations, marks, and document contents in one call. Pass the clientId, the query string, and an optional limit (defaults to 20). See Search the binder for the full BinderSearchResults shape. The web app debounces the input and requires at least two characters before firing the query; mirror that to avoid noisy partial queries.

Next steps

From here you can go deeper on the binder’s related surfaces:
  • Annotations and sign-offs: when search surfaces an annotation you want to reply to, or you want to leave a new note on a file, use the Document messages API. Sign-offs on a leadsheet sheet or row use the same createDocumentMessage mutation with type: "activity", markType: "signoff"; see Sign off on a sheet or row.
  • Leadsheets and review: the binder also carries a leadsheets field that returns the leadsheets tree for a TAX_PREP or TAX_REVIEW run. See Read a client’s leadsheets for that flow.
  • Badge counts: for a quick badge without fetching the full missing-items list, read binder.messageCounts via Read message counts.
  • Full reference: every binder field, type, and mutation is documented on Binder.