me query resolved as a
WorkspaceUser, so you must authenticate with a workspaceToken (see
Authentication). All requests go to:
There is no top-level
clients query. Clients belong to a workspace, so you read
them through me { ... on WorkspaceUser { workspace { clients(...) } } }. The
workspaceToken already identifies which workspace, so you never pass a
workspace ID.The Client type
The client’s unique identifier.
The client’s display name.
Your own identifier for the client (for example the ID from your practice
management system). Unique within the workspace.
active or archived.The tax return form:
F1040, F1041, F1065, F1120, F1120S, or F990.The tax year, for example
2025.When the client was created.
The workspace users assigned to this client.
Background tasks for this client (binder ingestion, tax prep, and so on). See the
tasks API. Narrow with the
type, status, triggeredBy, and
limit arguments.Client type exposes more fields (binder, documents, conversations, and
others) than are listed here. This page covers the fields needed to create,
list, fetch, and add documents to clients.
Create a client
createClient creates a client and, optionally, kicks off binder ingestion for
any documents you have already staged (see Uploading
documents).
Input: CreateClientInput
The client’s display name.
Your identifier for the client. Must be unique within the workspace.
One of
F1040, F1041, F1065, F1120, F1120S, F990.The tax year, for example
2025.Optional. Upload IDs from the upload endpoint. If
provided, Filed ingests these documents into the new client’s binder and returns
a
taskId you can track.Returns: CreateClientResult
The created client.
The binder ingestion task ID, present only when
uploadIds were
supplied. null when the client was created without documents.List clients
Readworkspace.clients to list clients. Filter, page, and sort with the
arguments below.
Arguments
Return only clients with these IDs. This is how you fetch a single
client.
Return only clients in these statuses (
active, archived).Free-text search over client name and external ID.
Return only clients assigned to these workspace users.
When
true, return only clients assigned to the authenticated user.Number of clients to skip, for pagination.
Maximum number of clients to return.
Sort order, for example
{ "field": "createdAt", "order": "DESC" }.Fetch a single client
There is noclient(id:) query. Fetch one client by passing its ID in
filters.ids and reading the first element.
An empty
clients array means no client with that ID exists in this workspace.
Handle it as a not-found result.Add documents to a client
addClientDocuments attaches already-staged uploads to an existing client and
ingests them into the client’s binder. Stage the files first with the upload
endpoint.
Input: AddClientDocumentsInput
The client to add documents to.
One or more upload IDs from the upload
endpoint.
Returns: AddClientDocumentsResult
The binder ingestion task ID. Poll it until
status is
COMPLETED to know the documents are filed in the binder.Re-run binder ingestion
retriggerIngestion re-runs binder ingestion for a client using the documents
already attached to it, without requiring you to re-upload any files. Use it when
a prior ingestion task finished with status: FAILED (or otherwise did not file
the documents into the binder) and the original files have not changed. When the
files themselves have changed, re-upload them and call
addClientDocuments with the new upload IDs
instead.
Input: RetriggerIngestionInput
The client whose binder ingestion you want to re-run.
Returns: RetriggerIngestionResult
The new binder ingestion task ID. Nullable: when the client has
no documents to ingest, or ingestion could not be started, the field is
null.
Poll it with the same pattern as
addClientDocuments: list the client’s tasks
narrowed to type: BINDER and wait for status to leave RUNNING.Manage clients
Beyond create, list, and fetch, the API exposes a set of mutations for the rest of the client lifecycle: rename, archive, restore, permanently delete, and assign or unassign workspace users. All of them take a singleinput argument
identified by clientId, return either the updated Client
or a Boolean, and require a workspaceToken (see
Authentication).
Update a client
updateClient renames a client. Only the name is mutable through this
mutation.
Input: UpdateClientInput
The ID of the client to rename.
The new display name for the client.
Returns: Client!
The updated Client.
Archive a client
archiveClient sets the client’s status to archived. Archived clients are
excluded from default lists but kept on disk and can be restored.
Input: ArchiveClientInput
The ID of the client to archive.
Returns: Client!
The archived Client with status set to archived.
Restore a client
restoreClient sets an archived client’s status back to active.
Input: RestoreClientInput
The ID of the archived client to restore.
Returns: Client!
The restored Client with status set to active.
Delete a client
deleteClient permanently removes a client and its binder. It cannot be undone.
Input: DeleteClientInput
The ID of the client to permanently delete.
Returns: Boolean!
true when the client was deleted.
Assign a user to a client
assignUserToClient assigns a workspace user to a client and returns the
created ClientAssignee.
Input: AssignUserToClientInput
The ID of the client to assign the user to.
The ID of the workspace user to assign. Use the
userId of a
WorkspaceUserShortDetails from the workspace’s members, or the id returned
by me.Returns: ClientAssignee!
The assignment record ID.
The client the user was assigned to.
The workspace user who was assigned. See
WorkspaceUserShortDetails under
assignees for the field shape.The workspace user who performed the assignment (the authenticated caller).
When the assignment was created.
Unassign a user from a client
unassignUserFromClient removes a workspace user’s assignment from a client.
Input: UnassignUserFromClientInput
The ID of the client to remove the assignment from.
The ID of the workspace user to unassign.
Returns: Boolean!
true when the assignment was removed.