Moskit CRM

Connect AI agents to Moskit CRM, a sales CRM for Brazilian small and medium businesses. Agents create companies, contacts, and deals, log activities and notes against them, and add products to the catalog those deals draw on.

27 actions API key available

Platform Documentation ↗

A form submission, a spreadsheet row, or a scheduled poll starts the run

Search Contacts posts a field, expression, and values condition on the email to find an exact existing match

Create Company writes the account with its responsible and creating user, both required on create

Create Contact attaches the person to that company so the pipeline can be read by customer

Create Deal opens the opportunity with a stage, a status of OPEN, and a value expressed in integer cents

The owner is told what was created, what was matched, and the value that was written

A person confirms the price and the unit before Create Product adds a catalogue entry that cannot be edited or removed

What This Integration Enables

Moskit CRM is a sales CRM built for Brazilian small and medium businesses, and the connector reflects a product that has decided what it is for. There is a pipeline, there are stages, there are lost reasons, and there is a deal movement history, and there is not a marketing automation engine or a case object. That focus is worth taking seriously when you design flows against it, because the highest value work here is not enriching contact records, it is keeping the funnel honest: getting a deal into the right stage with the right value at the moment the real-world event happens, and closing it with a lost reason a sales director can actually report on. List Deal Movements is the action that gives this away. A CRM that exposes stage movement history as a first-class read is a CRM that expects you to measure progression, not just current state.

Two mechanical facts govern almost every flow built here. Money is stored as integer cents, so 150000 means R$ 1.500,00, and every deal value and product price crosses that boundary. And references are numeric IDs which the connector wraps into the API's { "id": N } object for you, resolved through the users, pipelines, stages, lost reasons, activity types, and teams dictionaries, with dictionary search performed client side because the list endpoints carry no text query parameter, so the dictionaries fetch up to 200 records and filter by name locally. Beyond that: creates carry real required fields, since contacts and companies need a responsible user and a creating user, deals additionally need a stage and status, activities need a title, due date, and activity type, and products need a name, price, active flag, and creating user. Deal status offers Open, Won, and Lost, mapping to the wire values OPEN, WON, and LOST, and closing as lost should carry a lost reason ID. Paging works either by start and quantity offsets or by a nextPageToken cursor that arrives in the X-Moskit-Listing-Next-Page-Token response header, and the two cannot be combined, with listing totals returned in the X-Moskit-Listing-* headers. Search Contacts and Search Deals take an array of conditions, each with a field, an expression, and a values array whose length depends on the expression. Delete Contact, Delete Company, Delete Deal, and Delete Activity are permanent and cannot be undone. There are no triggers on this connector, so nothing here listens for Moskit events: List Deals, List Activities, and List Deal Movements are polled on a schedule for near realtime workflows.

Without FlowRunner

Leads reach the CRM late The enquiry sits in a mailbox or a sheet until a rep has time to key it in

Money is entered by hand Values are typed into a field that stores cents, and a stray factor of a hundred reaches the funnel report

Stage history is anecdotal Nobody can say when a deal moved or how long it sat, so the funnel report describes today only

With FlowRunner

Leads reach the CRM at arrival Contact, company, and deal exist together, with the responsible user set at creation

Money is converted once, in the flow The source value is converted to integer cents in one place and checked before it is written

Stage history is a record List Deal Movements is read on a schedule, so progression and time in stage are reportable facts

Use Case Scenarios

A lead that lands as a company, a person, and a deal in one pass

An enquiry arrives from a website form or a row in Airtable. The agent runs Search Contacts with a condition on the email address, using an explicit expression rather than a loose match, and List Companies to resolve the organisation. Where the company is new it calls Create Company, supplying the responsible user and creating user that Moskit requires on create, both resolved from the users dictionary and wrapped as numeric ID objects. Create Contact then attaches the person, and Create Deal opens the opportunity in the correct pipeline stage with a status of OPEN and an expected close date. The deal value is converted to integer cents in one place in the flow, deliberately, so there is a single line to inspect when a number looks wrong rather than a conversion scattered across three steps. Create Deal Note records the enquiry text so the first stage of the funnel carries evidence.

A funnel report built from movement rather than from current state

On a schedule the agent calls List Deals with the nextPageToken cursor, reading the token out of the X-Moskit-Listing-Next-Page-Token header rather than mixing it with a start offset, which the API does not allow. For each deal it calls List Deal Movements to pull the stage progression history, which turns "twelve deals in negotiation" into "twelve deals in negotiation, four of which have been there over sixty days". List Users resolves the owners and the output lands in a sheet in Google Sheets with time-in-stage per deal and per rep. Where a deal has clearly closed in a signing or billing system, Update Deal sets the status to WON, or to LOST with a lost reason ID resolved from the dictionary, because a lost deal without a reason is a row that will never appear in an analysis anyone acts on.

Follow-up that exists because the deal does

When a deal is created or moves stage, the agent calls Create Activity with a title, a due date, and an activity type resolved from the dictionary, tied to the contact, deal, or company it belongs to. As the work happens, Update Activity records progress and Create Contact Note or Create Deal Note captures what was actually said on the call, which is the part a colleague picking up the account next quarter will read. List Activities is polled to find follow-ups that passed their due date without being updated, and those are surfaced to their owners individually rather than as a report. Delete Activity exists for genuine mistakes, and it is permanent, so it runs against a specific ID a person named rather than against a filter an agent computed.

Human-in-Loop Highlight

Look at what the Products group on this connector actually contains: Create Product and List Products. There is no update, and there is no delete. That is the whole gate, and it is unusually clean. Every other risky write here has a repair path, since a wrong contact can be updated, a wrong deal can be moved back, and a genuinely bad record can be deleted, permanently but deliberately. A product created through this connector has none of those. Once it exists in the catalogue, this connector cannot correct its price and cannot remove it, and somebody has to open Moskit and fix it by hand. Now put that next to the other fact about this API: money is integer cents, so 150000 is R$ 1.500,00. A price pulled from an ERP, a spreadsheet, or a supplier feed almost never arrives in cents. It arrives in reais, and a conversion that is missed writes a product at one hundredth of its price, while a conversion applied twice writes it at a hundred times. Both look plausible in a JSON payload and neither fails validation, because Moskit requires a name, a price, an active flag, and a creating user, and a wrong number satisfies all four. The rep who quotes from that entry finds out when the customer accepts. So the agent prepares the catalogue sync and stops. It calls List Products, diffs against the upstream source, and posts to the sales operations owner: "The supplier feed has 23 products not yet in Moskit. Here they are with the source value, the converted integer cents value, and the reais figure that converted value represents, side by side. Four of them convert to a figure more than ten times the median price already in the catalogue, flagged below. This connector has no update and no delete for products, so anything I create here can only be corrected inside Moskit by a person. Create all 23, create the 19 that are not flagged, or hold?" The owner answers once and only the approved rows become Create Product calls. This is the human-in-the-loop moment that the capability list itself dictates, because an agent should stop hardest at the one write it has no way to take back.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

27 actions

Contacts

List Contacts Returns contacts using either `start` and `quantity` offsets or a `nextPageToken` cursor, which cannot be combined. Listing totals arrive in the `X-Moskit-Listing-*` response headers.
Get Contact Retrieves a single contact. Used to confirm current state and ownership before an update.
Create Contact Creates a contact. Moskit requires a responsible user and a creating user, both supplied as numeric IDs that the connector wraps into the API's `{ "id": N }` object.
Update Contact Updates a contact. Used to enrich a known person rather than create a second record for them.
Delete Contact Deletes a contact permanently with no recovery. Reserved for a specific record a person named.
Search Contacts Takes an array of conditions, each with a `field`, an `expression`, and a `values` array whose length depends on the expression. This is the deduplication check before any create.
Create Contact Note Appends a note to a contact. Used to record what was actually said, which is what a colleague picking the account up will read.

Companies

List Companies Returns companies with offset or cursor paging. Used to resolve accounts before attaching people and deals to them.
Get Company Retrieves a single company. Used to load account context before routing or reporting.
Create Company Creates a company, requiring a responsible user and a creating user. Called before Create Contact on a new account so the person is never created orphaned.
Update Company Updates a company. Used to keep account data aligned with a billing or ERP source of truth.
Delete Company Deletes a company permanently, leaving its related records without their anchor.

Deals

List Deals Returns deals with offset or cursor paging. This is the scheduled poll that stands in for a trigger, since this connector listens for no events.
Get Deal Retrieves a single deal with its stage, status, and value in integer cents. Used to confirm state before a move.
Create Deal Creates a deal, requiring a stage and a status which defaults to Open. The value is an integer in cents, so `150000` is R$ 1.500,00.
Update Deal Updates a deal, including moving it between the Open, Won, and Lost statuses that map to `OPEN`, `WON`, and `LOST`. Closing as lost should carry a lost reason ID.
Delete Deal Deletes a deal permanently, taking its notes and movement history with it.
Search Deals Takes the same condition array shape as Search Contacts, with a `field`, an `expression`, and a `values` array. Used to select a working set at the source rather than in a downstream filter.
List Deal Movements Returns the stage movement history for deals. This is what turns a snapshot of the funnel into a measurement of progression and time in stage.
Create Deal Note Appends a note to a deal. Used to explain why a stage or status changed, where a sales director will later look for it.

Activities

List Activities Returns activities with offset or cursor paging. Polled to find follow-ups that passed their due date without being updated.
Create Activity Creates an activity requiring a title, a due date, and an activity type resolved from the dictionary, tied to a contact, deal, or company.
Update Activity Updates an activity, including rescheduling and completion. Used to close out work a flow finished.
Delete Activity Deletes an activity permanently. Reserved for genuine mistakes against a named ID.

Products

List Products Returns the product catalogue with prices as integers in cents. Used as the read side of a catalogue reconciliation against an upstream source.
Create Product Adds a product, requiring a name, a price in integer cents, an active flag, and a creating user. This connector exposes no update and no delete for products, so a wrong price can only be corrected inside Moskit by a person, which is why this action runs on an approved list.

Users

List Users Returns the users in the account. Used to resolve the responsible and creating user IDs that contacts, companies, deals, and products require on create.

Frequently Asked Questions

What can FlowRunner do with Moskit CRM?

FlowRunner agents can run List Contacts, Get Contact, and Create Contact in Moskit CRM, plus 24 more actions.

Does connecting Moskit CRM to FlowRunner require OAuth?

No. Moskit CRM connects to FlowRunner with an API key, no OAuth flow required.

Can Moskit CRM trigger a FlowRunner workflow automatically?

Moskit CRM doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Moskit CRM

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us