REST API
A versioned path, a key you mint on the keys screen and see exactly once, and the same role and profile model the interface runs on deciding what that key is allowed to touch.
One key, walked from the header to the rows it may read
key matched- api/
- v1/the version, in the path
- leadslist · read · create · update
- dealslist · read · create · update
- activitieslist · read · create
- webhooks/incoming/[slug]the push side, same prefix
- namethe one you typed at creation
- workspacethe only one it can reach
- roleits seat in the tree
- signature verification
- replay protection
- per-source rate limiting
- a full delivery log
Product figures from the platform’s own defaults - not customer averages
How it works.
One version, and it is in the address
Everything sits under a single versioned prefix, so a client written against it keeps working while the interface behind it changes. The inbound webhook receiver lives under that same prefix, which is why a push and a read share one base address.
A key is minted once and kept as an identity
The keys screen takes a name and hands the value back a single time. The row left behind carries the name, the workspace and the role rather than anything you could put on a request, so the useful question about a key is never what it says but what it is permitted to be.
It inherits the permission model, rather than inventing one
A key resolves to a workspace, then to a role in the tree, then to a permission profile. That is the identical chain a signed-in session walks, so a key can never reach further than a person holding the same profile would.
Created, rotated and revoked are all written down
Each of the three is an audit event carrying who did it and when. A key that stops working therefore has a row explaining why, which is the difference between a rotation and an outage nobody can account for.
Two moments in every run.
Every run passes through the same seven. REST API is the lit ones, and everything either side of it is a different page in this category.
- 01Trigger
the thing that happened first
- 02Enrol
how somebody gets onto it
- 03Wait
the pause, and what governs its length
- 04Branch
the fork, and which side is taken
- 05Act
the mail, the text, the task that goes out
- 06Measure
what counts as it having worked
- 07Exit
how somebody comes off it
The specifics.
8 facts- Pagination
- Fifty rows unless you ask for more and a hundred at the ceiling, addressed by page or by offset
- Authentication
- The key on the request. The signed browser cookie is the interface's own credential and is never what a client sends
- Keys
- Named at creation, shown once, hashed at rest, and rotated rather than recovered
- Scope
- The workspace the key belongs to, then its role and profile, enforced the way the record screens are
- Audit
- Created, rotated and revoked, each stamped with the person and the moment
- Rate limiting
- Counted per key over a rolling minute. A refusal carries the wait in a header and holds the connection open
- On the inbound side
- Signature verification, replay protection, per-source limiting and a full delivery log
- Not the same as
- This reads and writes records from outside. A sender pushing an event at you is Inbound Webhooks
What starts this, and what it starts.
Automation is only ever a middle. These are the things that set it running and the things that run because of it.
More in Automation & Flows
14 capabilitiesSequences, dispositions and webhooks that act without being asked.
Thirteen node kinds on a canvas: send, wait, branch on behaviour, split, call task, tag, goal. Publish a version and in-flight leads keep their own place.
Enrol a lead once and the sequence carries them: sends, waits, branches and exits, with a ledger that makes a duplicate send structurally impossible.
Branch on whether they opened, clicked or replied, and on how the last call was dispositioned - so the next step answers what actually happened.
Weighted splits assigned by a deterministic hash of the enrolment, so a lead always takes the same arm no matter how often that step is run again.
Hold a lead for minutes or days between steps, clamped to the sending window you set, so that an overnight wait never lands at four in the morning.
Set the hours a sequence may send inside, as a fixed offset you enter yourself, and every wait is pushed forward into them before it is stored.
One do-not-contact roll per workspace, checked when a lead is enrolled and again inside the send, straight after that send has taken its own claim.
New leads enrol themselves the moment they are created, and the four guards that can refuse an add are read on every single route into a cadence.
Drop a call step into a sequence and it raises an assigned task on the lead's owner, with the outcome the rep logs coming back as a branchable answer.
Name a linked deal as the outcome that means the sequence worked. Reaching it stamps goal met on the run and takes the branch you wired behind it.
Twenty-six behaviours attach to wrap-up codes, and twenty codes ship already pointing at one, so ending a call the right way books the follow-up.
Six event types a CRM rule fires from: stage change, field update, new record, reassignment, schedule and inactivity, agreed in four places at once.
Eight comparison operators guarding each action, combined with AND and only AND, so a rule meaning either of two things is built twice, as two rules.
A text is a step on the same canvas as the email and the call task, written into the real thread and carried out by the number it is going out from.
The rest of the platform.
Five more categories, all on the same record and the same bill. Each card names three of its capabilities, so you can tell from here whether it is worth opening.
Automation & Flows
See rest api on your own floor.
Thirty minutes, your numbers and your data. We will set rest api up live and you can decide from the thing itself rather than from this page.
14-day trial · no card · migration included