Filevine

List, read, create and update Filevine projects, contacts, notes, tasks and documents — all against a connected Filevine org.

Connecting

Filevine connections are made from Account Manager inside Filevine, not from an OAuth consent screen. You need three things:

• a personal access token (PAT),
• a client ID,
• a client secret.

Enter all three when adding the connection. Lido trades the PAT for a short-lived access token and reuses that token until Filevine rejects it, then mints a new one — no expiry is tracked, so a rejected token is how expiry is discovered. The PAT is the only long-lived secret stored, and no refresh token is kept. Disconnecting deletes Lido's copy — to revoke access outright, revoke the PAT in Filevine.

Choosing an org

Every request carries an org, and Filevine shows org IDs on no screen — its own authentication flow fetches them from the API. So the node offers an Org dropdown listing the orgs your token can reach, labelled Name (id) because firms often run several orgs with near-identical names.

Actions and objects

The node asks two questions: an Action — List, Get, Create or Update — and then the Object it applies to. Only the objects that action supports are offered, and only the fields that pair needs are shown.

	List	Get	Create	Update
Project	✓	✓	✓	✓
Contact	✓	✓	✓	✓
Note	✓		✓
Task	✓		✓
Document	✓		✓ (upload)
Custom section data		✓	✓	✓
Form (static section)		✓		✓

Get on a custom section reads the whole section; Create and Update act on one item within it.

Custom request is a fifth action rather than an object, because it picks no object at all — see Anything not listed above.

Listing is filtered rather than paged through by hand: projects by name, number, phase, incident date, activity dates and hashtags; contacts by name, phone, email and person type; documents by filename, folder, note or upload date.

Each returned record is emitted as one item, so a list operation fans out into the rest of the workflow.

Filters

Filevine documents nine to sixteen query filters per list. They are added as rows rather than shown as a wall of empty fields: press Add, choose the filter, fill in its value. Each row's editor matches the filter it names — a date filter gives a date picker, a boolean gives a checkbox, Sort by gives its documented options.

A list operation therefore opens with only the fields worth seeing: the search box, the pickers that operation needs, Filters, Fields and Limit.

Filters that belong to another operation are dropped rather than sent. Filevine ignores a query parameter it does not recognise without complaining, so an unrecognised name has to be caught here rather than looking like it filtered.

Choosing which fields come back

Every read operation has a Fields selector. Leave it empty to get the whole record; tick fields to keep only those.

The options are learned from a real record. Filevine has no schema endpoint for projects, contacts, notes, tasks or documents, so the node fetches one record and offers the paths it actually contains. Two consequences worth knowing:

• A field missing from the sampled record will not be offered, and cannot be added by hand — a key that is present but null still is offered. If a field you need never appears, pick a sample record that has it set.
• Fields are the record's top-level keys, and a selected value comes back whole. Filevine wraps every identifier as { native, partner }, so selecting projectId gives you both halves rather than two separate options — and passing that straight into another Filevine node works, since a record ID is unwrapped wherever one is consumed.

Unlike Salesforce's SOQL, this selection is applied after the fetch — it trims each record for readability rather than reducing what Filevine sends.

Anything not listed above

Custom request reaches any documented Filevine endpoint through the same credential, org header, rate-limit handling and re-authentication as the named operations. Give it a method, a path relative to the API (/v2/folders), optional query parameters as name/value rows, and a body for writes.

The named operations exist because they carry real pickers, typed fields and validation. This one exists so nothing is unreachable — folders, deadlines, billing, the task lifecycle. It is deliberately the only place JSON is the right answer: a raw request has no schema to render against.

The path is checked before it is sent: it must start with /, cannot contain .. segments, and cannot carry a query string. That last pair matters — the API host cannot be changed, but an unchecked .. could climb out of the API prefix and reach a different service on the same host carrying your token.

A write goes down the same un-retried path as every other write, since a lost response on a POST must not become a second write.

Record IDs come from upstream

Project, Contact and every other record ID are expression fields, because that is where their values come from: one node lists or creates a record, the next acts on it. A workflow that pulls a project from a spreadsheet, adds a note to it, then opens a task on it is the point of the node, and none of those IDs are typed by hand.

There is deliberately no dropdown of projects or contacts. One existed briefly and was removed: Filevine has no typeahead endpoint, so offering a list meant fetching hundreds of records every time a panel opened, to fill a picker for a value that almost always arrived from an earlier node.

Configuration is the opposite case and does keep its pickers — Org, Project type, Phase and Section are chosen once by the author, and none is something anyone types from memory.

Phase is narrowed to one project type, because Filevine lists phases per project type and has no org-wide phase endpoint. On Create → Project the phase list follows the project type you are creating under; on Update → Project there is a Project type field whose only job is to narrow that list, and it is never sent to Filevine.

Custom section data

Custom sections are the one part of Filevine that can describe itself, and they come in two shapes: collections, which hold a list of items, and forms (static sections), which hold one set of fields per project.

Both walk the same three steps:

1. pick a Project type,
2. pick a Section within it,
3. pick the Fields of that section.

Writing one is field/value rows against the section's own field list, so there is no JSON to hand-write for the one part of Filevine that is entirely per-firm. Values are read as you would expect: true and false become booleans, a number becomes a number, and null clears the field. Anything else stays text — including a padded reference like 007, which keeps its zeros. A value from an expression keeps whatever type the expression produced.

Changing the project type does not clear a section already chosen, so the node sends the project type with the request and the server refuses a section that no longer belongs to it, rather than reading or writing whatever the stale selector points at.

Project types and sections are cached per credential and refresh automatically when the credential is reconnected. Project and contact lists are cached only briefly, since a project created a minute ago has to be pickable now.

Limits and pagination

List operations paginate automatically. 20,000 records is both what a blank Limit returns and the most any limit can ask for, so a broad list cannot silently walk an entire firm's caseload; set a lower limit to bound it further.

If Filevine rate-limits a request, the node fails with how long Filevine asked you to wait, rather than holding the run open and retrying — a retry left waiting keeps counting against the same quota, which pushes the next run's limit out too. If the access token is rejected, it mints a fresh one from the PAT and retries once — a second rejection means the PAT was revoked or the client secret rotated, and the connection needs reconnecting.

Uploading documents

Create → Document takes a file from an upstream node and stores it against a project. Leave File name blank to keep the source file's own name, or set it to rename the upload.

Permissions

Operations run as the Filevine user behind the PAT. If a read or write fails with a permission error, check that user's access in Filevine — it is separate from whether the connection itself is valid.