Skip to main content
get_company before writing anything about a company, so you add to the research rather than replacing it — update_company replaces the notes field it is passed. A company’s website is their own domain, not a job-board link. Nothing else depends on it, but it is what puts their logo on the pipeline, so it is worth setting whenever you learn it.
log_activity takes either an applicationId or a contactId, never both. With a contact id it becomes that person’s history — their page shows it and their “last touched” date moves. update_contact’s nextFollowUpAt is where “ping them in two weeks” lives, and due pings surface in list_follow_ups alongside due applications.
How companies and contacts work →
The descriptions below are quoted verbatim from what the server sends a connected assistant, which is why they address it rather than you. They are reproduced rather than rewritten so this page cannot drift from what your assistant actually receives.

list_companies

List companies Every company on file, with how many applications and contacts each one has, plus lastAppliedAt (when you last applied there) and openApplications (how many are still live). Reach for this to answer ‘who have I applied to’, to find a companyId before get_company, or to cut the list down to something specific before working through it. Every row carries its tags: industry, size, location and free tags, all as labels rather than the single strings they used to be. Everything below ANDs, so one call asks for ‘fintech, remote, never applied’. search matches the name, the website, your notes and any tag name. filter is one cut and only one. industryIds, sizeIds and locationIds each take tag ids of that kind from list_tags and match a company wearing ANY id in the group — so a group ORs inside itself and ANDs with the others. tagIds is the loose one: it matches a tag of any kind, which is what to use when you have an id and do not care which list it came from. missing finds the gaps worth fixing in one sitting, and those AND with each other. sort is name, applied, apps or people; every sort but name defaults to most-first, and companies you have never applied to sort last whichever way ‘applied’ points, because that is a question about the others. Ids only — call list_tags first to turn ‘fintech’ into an id; a name here would narrow nothing and hand you every company as if that were the answer. Archived companies are never returned; list_archive is where those are. Read-only: it saves nothing and creates no tags.

get_company

Get a company Everything on file for one company: website, industry, size, location, your research notes, every application you have with them, and every person on file who represents it — someone can represent more than one company, so a name here is not necessarily their day job. This is the tool to call before writing anything about a company, so you add to what is known rather than replacing it.

create_company

Create a company Add a company before you have applied to them — somewhere to keep research while you decide. Applications create their company automatically, so reach for this only when there is no application yet. Names are unique per person; creating one that already exists is an error rather than a silent merge.

update_company

Update a company Change what you know about a company. Only the fields you pass are touched, but each one REPLACES what was there — notes especially, so call get_company first and write back the whole thing if you are adding to research rather than replacing it. Industry, size, location and tags are lists of labels now rather than single strings: a company can be fintech AND developer tools, and in three offices. Each list replaces its own set and leaves the other three alone. Setting website is the single thing that makes their logo show in the pipeline; a job board URL is not their website. Overwrites or deletes.

delete_company

Archive a company Put a company in the archive. It leaves the CRM, every picker, every filter and the pipeline, and restore_records brings it back for a set number of days — 30 by default — before it is deleted for good. Nothing is destroyed here. Every application still pointing at it goes into the archive with it and comes back with it; this used to refuse while those existed and no longer needs to. The people who represent it are NOT archived: somebody is a founder at one company and an advisor at another, so they keep every other company and simply lose this one. Returns how many applications went with it. To fold a duplicate employer into the one you are keeping without archiving anything, use merge_companies. Overwrites or deletes.

preview_company_merge

Preview merging two companies What merging one company into another WOULD do, without doing any of it. Call this first, every time — merge_companies is irreversible and takes an argument order that is easy to get backwards. Returns how many applications and contacts would move, which of them by role title, which blank fields on the survivor would be filled from the duplicate, and whether the duplicate’s notes would be appended. Show that to the person before you merge. Read-only.

merge_companies

Merge one company into another Fix the same employer being on file twice — ‘Stripe’, ‘Stripe, Inc.’ and ‘stripe’ each holding a slice of the pipeline. Every application and contact on merge_id moves to keep_id, blank fields on keep_id are filled from the duplicate, the duplicate’s notes are APPENDED to the survivor’s under a line saying where they came from, and then the duplicate row is deleted. DESTRUCTIVE and IRREVERSIBLE: the company at merge_id ceases to exist, its page stops resolving, and nothing records afterwards which applications came from which side. Call preview_company_merge first and let the person confirm. The direction matters and is not guessable — keep_id is the name that lives on. Nothing is de-duplicated: two identical role titles on the survivor is the correct result, not a bug. Note that a later create_application naming the old spelling will simply create it again as an empty company. Overwrites or deletes.

list_contacts

List contacts Recruiters, hiring managers, referrals and the friend who might put in a word. Reach for this to find a contactId before get_contact or update_contact, to see who you already know somewhere before an interview, or to build the list you are about to work through. Returns each person with companies — a list, because someone can be a founder at one place and an advisor at another — their tags, their next ping date, the application they are attached to, and their most recent logged activity. Everything below ANDs. search matches name, title, relationship, email, notes, employer names and tag names. filter is one cut and only one. companyIds matches anyone linked to ANY of those companies — linked, not employed by, so an advisor at one of them counts; companyId is the single-company shorthand for the same thing. tagIds takes CONTACT tag ids from list_tags. quietDays is the networking question: everyone you have logged nothing against for at least that many days, counting from the day you added somebody you have never logged anything against at all, so people you filed and forgot come back rather than hiding behind a blank. missing finds the gaps: ‘email’ means nobody you can write to, ‘tags’ means filed under nothing so no tag filter will ever find them. sort is name, company (people with nobody on file last), ping (soonest first, no date last) or touch (longest since you logged anything, first). log_activity with a contactId is what moves the last-touch date; update_contact’s nextFollowUpAt is what schedules the next ping. Archived people are never returned; list_archive is where those are. Read-only; it saves nothing.

get_contact

Get a contact One person in full, with every company they represent (companies) and the application they belong to. Call this before update_contact so you know what you are about to overwrite. Also returns their timeline — every call, coffee and reply logged with log_activity, newest first — so ‘when did I last talk to them’ is answered from here.

update_contact

Update a contact Change a person’s details. Only the fields you pass are touched, and each REPLACES what was there — read first with get_contact if you are adding to notes, otherLinks, companies or tags rather than replacing them. A person can represent several companies at once, so companies is a list and REPLACES the whole set: to add one, read the current list, append, and pass it all back. An empty list detaches them from every company. tags behaves the same way. applicationId works the same way too, with an empty string to detach. Overwrites or deletes.

delete_contact

Archive a contact Put a person in the archive with their whole timeline — every call, coffee and reply logged against them. Nothing is destroyed, and restore_records brings all of it back for a set number of days, 30 by default. The companies they represent and the application they were attached to are untouched; they simply stop appearing on either. To take somebody off one application without archiving them, use update_contact with an empty applicationId. Overwrites or deletes.

create_contact

Create a contact Save a person: recruiter, hiring manager, referral, friend at the company. Record every way you can reach them — linkedin, twitter, instagram, github, website, and otherLinks for anything else — because the one that matters is whichever they actually answer on, and a name with no way to contact it is a dead row. Pass companies for everywhere they represent, not just their day job: an angel who also advises two of your targets is three links, and each one is created if it does not exist yet. tags files them alongside everyone else you have labelled the same way.

tag_companies

Tag companies in bulk Add or remove tags across a set of companies in one act — ‘these nine are all fintech’, ‘take Dream list off these four’. ADD and REMOVE, never replace: a bulk write that replaced the set would mean tagging nine companies as fintech quietly stripping the size, location and everything else off every one of them. Ids only, from list_tags, and each must be a tag of kind INDUSTRY, SIZE, LOCATION or COMPANY — a tag of any other kind is refused rather than attached, because nothing in the app renders an application tag on a company and no picker could ever take it back off. Ids that are not this person’s, or are in the archive, are skipped rather than failing the call. Returns which companies changed and which were skipped. Use update_company when you are setting one company’s lists deliberately; this is for a selection.

tag_contacts

Tag people in bulk Add or remove CONTACT tags across a set of people in one act — ‘these six are all referrals’. ADD and REMOVE, never replace, for the same reason tag_companies does not replace: a bulk overwrite loses every other label somebody already carries. Ids only, from list_tags with kind CONTACT; a tag of any other kind is refused. Ids that are not this person’s, or are in the archive, are skipped rather than failing the call. Use update_contact when you are setting one person’s tags deliberately.

schedule_contact_pings

Put people on the chase list Set one next-ping date across a set of people — ‘chase everyone I met at the conference in two weeks’. Takes an ISO date; an empty string clears the date instead, taking all of them off the chase list. A date it cannot read is REFUSED rather than treated as empty, so a vague ‘next Tuesday’ fails loudly instead of silently unscheduling everybody in the batch. Due pings surface in list_follow_ups and list_schedule alongside due applications. Ids that are not this person’s, or are in the archive, are skipped. Use update_contact’s nextFollowUpAt for one person.