Fluid CRM

Imports up to 50 contacts in one call using Fluid's duplicate matching: a row whose email, or name within its company, already exists is reported as matched and not created. A company named in a row is matched or created and linked automatically. A row with no name is skipped and listed in row_reports (reason missing_name); the valid rows still import. Retrying the same rows is always safe. name is required per row. For more than 50 rows, split into chunks and call once per chunk. Records created here cannot be deleted through this API: confirm with the user before importing a large list. Returns counts (received, created, skipped_invalid, matched_existing, duplicates_in_batch, failed, companies_created, companies_matched), created_contacts[{id,name,email}] and row_reports[{row_idx,reason}], numbered by your rows counting from 1 (row_idx 1 is your first row).

contacts_bulk_create

Imports up to 50 deals in one call with Fluid's duplicate matching: companies by website then name, contacts by email or by name within the company, duplicate rows in the batch collapsed, and a row whose contact already has a deal of that name reported as matched, not created. A row with no contact_name is skipped and listed in row_reports (missing_name); the rest still import. pipeline_id is required; each row needs contact_name and deal_name. A row may carry label ('Hot|Warm' attaches both; a new name joins the catalog), reminder_date (YYYY-MM-DD, creates a reminder at 09:00 UTC that day), expected_close_date (YYYY-MM-DD) and custom_fields by name; a custom_fields value that does not fit its field type is left blank and reported (cf_type_mismatch with field and expected), the row still imports. Retrying the same rows is safe with on_existing skip, the default. Over 50 rows: split into chunks. Records created here cannot be deleted through this API: confirm before importing a large list. Returns counts (received, created, skipped_existing, skipped_invalid, duplicates_in_batch, contacts_new, contacts_reused, reminders_created), created_deals[{row_idx,id}], matched_existing[] and row_reports[{row_idx,reason}] numbered by your rows counting from 1 (row_idx 1 is your first row); reason is matched_existing, existing_deal_found (created again under on_existing create), within_batch_duplicate, missing_name or cf_type_mismatch.

deals_bulk_create

Lists timeline activities, newest first. Filter by deal_id, contact_id or activity_type, or fetch one by id. Descriptions are returned in full, so this is the tool for reading what a lead actually said on a call or in a meeting. Results also include status_change entries that Fluid writes automatically when a deal is won, lost or moved between stages; filter activity_type = status_change to see only those (they cannot be created or edited). Returns { items[], next_cursor, has_more }.

activities_list

Returns the user's open reminders with the deal name and the deal's contact name and email already attached. Use it for 'what is due today', 'what is overdue' and 'what is due this week'. Always pass tz as the user's own timezone in IANA form; it defaults to UTC, which shifts every bucket. due filters by the reminder's date in that timezone: today, overdue, week (today through Sunday), future (after today), or all. Sorted by reminder_at ascending. Each returned row carries its exact bucket in due (today, overdue, week = later this week, future = after this week), and the filter of the same name always includes that row, so a value read from a row can be passed straight back. There is no cursor: raise limit (max 500) if truncated is true.

reminders_list

Lists the Fluid workspaces the signed-in user belongs to. Use it first when a call fails asking for workspace_id, or when the user mentions a specific workspace. Returns id, name and the user's role for each. When there is exactly one, it is the default for every other tool.

workspaces_list

Logs an activity on a deal, a contact, or both. activity_type (note, call, email, meeting or task) and title are required. description, activity_date, deal_id and contact_id are optional. Put the substance in description rather than title: it is returned in full by activities_list and is what a later conversation will read back, so a well written note is what makes the CRM useful as memory. activity_date takes an ISO 8601 timestamp with offset, e.g. 2026-11-15T10:00:00+02:00; leave it out to default to now, which is usually correct. Creates a new entry every time. Returns the created activity.

activities_create

Edits one activity by id. Partial: only the fields you pass change. activity_date takes an ISO 8601 timestamp with offset. Safe to retry. Returns the updated activity.

activities_update

Updates one company by id. Partial: only the fields you pass change. custom_fields sets values by field name, and null clears a value. label replaces the company's whole label set ('Partner|Key Account' attaches both, a new name is added to the catalog, empty string or null removes all); omit it to leave labels untouched. Safe to retry. Returns the updated company.

companies_update

Updates one contact by id. Partial: only the fields you pass change. label attaches or replaces a label, custom_fields sets values by field name (null clears a value), organization_id links a company. expected_close_date takes YYYY-MM-DD. Safe to retry. Returns the updated contact.

contacts_update

Updates one deal by id. Partial: only the fields you pass change. stage_id moves it, status wins, loses or reopens it, label attaches or replaces its label, custom_fields sets values by field name (null clears). Closing (status won or lost) keeps the deal's reminders, and reopening keeps them too. expected_close_date takes YYYY-MM-DD. value must be 0 or more and below 10 billion, and also writes the same number onto the linked contact. A deal's pipeline is its stage's pipeline, so a stage_id from another pipeline moves the deal there; custom field values of the old pipeline are kept, hidden until it moves back. Unlike the app, this does not check the new pipeline's required fields: check workspace_schema for fields marked required and fill them first. A workspace automation may forward a deal from a trigger stage, so read stage_id back from the result. Safe to retry. Returns the updated deal.

deals_update

Updates one reminder by id: a new reminder_at snoozes it, and note and deal_id can also change. There is no 'done' state for reminders in Fluid; when the user has handled a follow-up, either snooze it or leave it, and tell them reminders are cleared in the app. reminder_at takes an absolute ISO 8601 timestamp with the user's offset; a bare YYYY-MM-DD plus tz is stored at local midday. Reminders can exist on won and lost deals. Safe to retry. Returns the updated reminder.

reminders_update