Stood CRM

Connect AI agents to Stood CRM, a lightweight composable CRM from Hway Digital. Agents create accounts, contacts, and deals, log activities and posts, and organize records into folders and sub-collections.

35 actions API key available

A scheduled poll of an inbound source, a signed document, or a project kickoff starts the run

List Accounts with a search term resolves whether the company already exists in the team

Create Account and Create Contact write the buyer and the person behind it

Create Deal opens the opportunity, and Create Deal Folder attaches the external document link

List Deals reads the current stage code on every related deal in the pipeline

The pipeline owner is shown which deals the run would advance and to which stage code

A person confirms what the target stage code means in this team before Update Deal writes it

What This Integration Enables

Stood CRM is a composable CRM rather than a fixed one, and that shows up in the shape of this connector. Alongside the expected accounts, contacts, and deals, it exposes deal folders and custom sub-collections, which means a Stood team can define its own record types under a deal and an agent can write into them without waiting for anyone to build a new integration. Create Sub-Collection Item and Update Sub-Collection Item address whatever collection names your team's data model defines under the deal object. That is the practical argument for connecting agents to a product like this: the shape of your pipeline is yours, so the automation has to follow your model rather than a vendor's idea of one.

There are three operational facts worth knowing before designing a flow. First, the API host is per deployment. Stood runs on Firebase Cloud Functions and the base URL is assembled from your Firebase Region and Firebase Project ID, both found in the Firebase Console under Build then Functions. Second, authentication sends two headers on every request: X-Team-ID for the team and Authorization: Bearer {webFormKey} for the Web Form API Key, and that key grants full read and write access to team data, so it belongs in configuration and never in client-side code. Third, this connector ships no triggers, and the reason matters. Stood does emit outbound webhooks for deal.created, deal.stage_changed, and deal.contact_added, but they are configured per stage in the Stood admin console rather than through a webhook subscription API, so FlowRunner cannot register or manage them programmatically and does not receive them. Change detection here is a scheduled read: List Deals and List Accounts accept a search term, an optional filters object for exact-match filtering, and limit with offset paging, where the limit defaults to 100 and caps at 1000. Large offsets are inefficient, so narrow with search or filters rather than paging deep. Every response carries a { "success": true, "data": ... } envelope, with list responses adding count and total, and this connector throws on any non-success body. Deal stages travel as the fixed wire codes s0 through s4. Activity status is one of open, done, or cancelled, keeping Stood's British spelling. Delete actions are permanent, and there is no users list endpoint, so owner and author fields take a user ID you supply directly.

Without FlowRunner

Records arrive without their paperwork The deal exists in the CRM and the signed brief lives in a Drive folder nobody has linked

Stage codes are set from memory A deal is written to a stage whose meaning the writer assumed rather than checked

Line items live outside the deal Orders and service requests sit in a spreadsheet and the deal shows only a total

With FlowRunner

The deal opens with its evidence attached Create Deal and Create Deal Folder run in the same pass, so the document link arrives with the opportunity

Stage writes are confirmed, not assumed The run reports the target code and the labels behind it are settled by a person before anything moves

Structure goes where the deal is Create Sub-Collection Item pushes orders and service requests into the deal's own data model

Use Case Scenarios

A signed brief that opens the deal and brings its document with it

A proposal is signed in DocuSign or a project brief lands in a shared folder. The agent calls List Accounts with the client name as the search term to see whether this company is already a Stood account, since creating a second account for an existing client is the failure that quietly splits a pipeline in two. Where nothing matches, Create Account writes the company and Create Contact writes the signer. Create Deal then opens the opportunity against that account with the amount taken from the signed document rather than from the sales rep's estimate. Create Deal Folder attaches the link to the signed brief so the evidence sits on the deal instead of in an inbox, and Create Post records what the agreement actually said. The deal opens at its initial stage code, and any advance beyond that is left to the gate described below.

Order lines pushed into the deal's own data model

A confirmed order arrives from an e-commerce platform or an ERP. Because Stood lets a team define custom sub-collections under the deal object, the agent does not have to flatten the order into a note. It resolves the deal through List Deals with a filters object matching the account, then calls Create Sub-Collection Item once per line, writing each item into the sub-collection your team named for it. Where a line is later corrected upstream, Update Sub-Collection Item revises it in place and Get Sub-Collection Item reads it back to confirm. This is the case where the composable model earns its keep: the same flow shape works for service requests, invoice lines, or site visits, because the collection name is configuration rather than code.

A weekly forecast read that writes nothing

On a schedule the agent calls List Deals with filters narrowing to the later stage codes and pages with limit and offset, reading total from the response envelope so a first page is never mistaken for the whole set. For each deal it calls Get Deal for the amount and owner, Get Account for the company behind it, and List Activities to see whether anything is actually scheduled against the opportunity. The joined view appends to Google Sheets as the working forecast and a summary posts to Slack, separating deals that are progressing from deals that are simply old. Nothing in this run writes, which is what makes it safe to run every Monday morning before anyone has had coffee.

Human-in-Loop Highlight

Update Deal is the operation to gate, and the reason is a detail most integrations would paper over. Stood stores deal stages as the fixed wire codes s0 through s4, and the human-readable stage names your team sees in the Stood interface are team-configurable and are not returned by these actions. So an agent can write s3 to a deal, and it can read s3 back, and at no point can it discover that your team relabelled s3 from Proposal Sent to Contract Out For Signature last quarter. The code is stable, the meaning is not, and the meaning is what the forecast, the commission sheet, and the Monday pipeline call all run on. The failure this produces is not an error. It is a deal that sits in a stage the agent believed meant one thing and the sales director reads as another, discovered at the end of the quarter when the numbers do not reconcile. The same gap makes Delete Deal Folder worth care, since a folder holds the external document links that connect a deal to the signed brief behind it, and deletes in Stood are permanent. So the agent proposes rather than advances. It calls List Deals filtered to the affected accounts, reads each deal's current code with Get Deal, and posts to the pipeline owner: "18 deals matched a confirmed order upstream. 11 currently sit at s1 and 7 at s2. I would move all 18 to s3. Stood does not return the label your team has attached to s3, so I cannot confirm what that stage is called or what it triggers in your admin console. Should I write s3 to all 18, only to the 11 at s1, or should someone confirm the label first?" The owner answers once, the agent applies that rule, and Update Deal runs only against the codes a person named. This is the human-in-the-loop moment on a CRM whose composability is its best feature, because the agent can prove exactly which deals moved and only a person can say what the stage they moved into actually means.

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

35 actions

Accounts

List Accounts Returns accounts with a `search` term matching the name field, an optional `filters` object for exact-match filtering, and `limit` with `offset` paging. This is the deduplication read that runs before any create.
Get Account Retrieves a single account with its details.
Create Account Creates an account for a company entering the pipeline.
Update Account Updates an account, used to keep the company record current from a system that genuinely owns the field.
Delete Account Permanently removes an account. Deletes in Stood cannot be undone.
List Contacts Returns contacts, with the `search` term matching firstName and lastName, plus `filters` and paging.
Get Contact Retrieves a single contact.
Create Contact Creates a contact. Owner and author fields take a user ID supplied directly, since the REST API exposes no users list endpoint.
Update Contact Updates a contact's details.
Delete Contact Permanently removes a contact and cannot be undone.

Deals

List Deals Returns deals with search, exact-match filters, and `limit` and `offset` paging, with `count` and `total` on the response. This is the scheduled read that substitutes for the events this connector does not receive.
Get Deal Retrieves a single deal with its amount, owner, and current stage code.
Create Deal Opens a deal against an account. Stages travel as the fixed wire codes `s0` through `s4`.
Update Deal Updates a deal, including moving it to a different stage code. The friendly stage names shown in the Stood interface are team-configurable and are not returned by these actions, which is why stage changes belong behind an approval.
Delete Deal Permanently removes a deal and cannot be undone.

Activities and posts

List Activities Returns activities logged against records, used to see whether an opportunity is actually being worked.
Get Activity Retrieves a single activity with its status.
Create Activity Logs an activity with a status of `open`, `done`, or `cancelled`, keeping Stood's British spelling on the wire.
Update Activity Updates an activity, including moving it to done or cancelled.
Delete Activity Permanently removes an activity and cannot be undone.
List Posts Returns posts recorded against records.
Get Post Retrieves a single post.
Create Post Writes a post, preserving the substance of a conversation where the next person will find it.
Update Post Updates an existing post.
Delete Post Permanently removes a post and cannot be undone.

Folders

List Deal Folders Returns the folders nested under a deal, which is where external document links live.
Get Folder By ID Retrieves a folder directly by its ID without knowing the parent deal.
Create Deal Folder Creates a folder under a deal, used to attach links to documents held in Dropbox, Google Drive, or a similar store.
Update Deal Folder Updates a folder's details.
Delete Deal Folder Permanently removes a folder along with the document links it carried, and cannot be undone.

Sub-collections

List Sub-Collection Items Returns items from a custom sub-collection under a deal. Collection names come from your team's own data model.
Get Sub-Collection Item Retrieves a single sub-collection item, used to read a line back after writing it.
Create Sub-Collection Item Writes a structured item such as an order line, invoice line, or service request into a deal's sub-collection.
Update Sub-Collection Item Revises a sub-collection item in place when the upstream source corrects it.
Delete Sub-Collection Item Permanently removes a sub-collection item and cannot be undone.

Frequently Asked Questions

What can FlowRunner do with Stood CRM?

FlowRunner agents can run List Accounts, Get Account, and Create Account in Stood CRM, plus 32 more actions.

Does connecting Stood CRM to FlowRunner require OAuth?

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

Can Stood CRM trigger a FlowRunner workflow automatically?

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

Start building with Stood CRM

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

Start Building Free Talk to us