Skip to content
Adoptiv

REST API

A key you create on the keys screen and see exactly once. What it may touch is decided by a role and a profile, the same two things that decide what a person on your floor may touch, so a key never reaches further than they would.

See pricing

One key, walked from the header to the rows it may read

key matched
The request
GET /api/v1/leads?limit=50&page=2
Authorization: Bearer ...
The surface it arrives at
  • 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
The key is an identity, not a password
What the row holds
  • namethe one you typed at creation
  • workspacethe only one it can reach
  • roleits seat in the tree
Shown once, then rotated rather than recovered
The creation response carries the value and no screen shows it again, so a key somebody mislaid is replaced rather than looked up.
On the push side, under the same prefix
  • signature verification
  • replay protection
  • per-source rate limiting
  • a full delivery log
The keys screen takes a name and hands the value back a single time. The row that stays behind holds the name, the workspace and the role, so the interesting question about a key is never what it says but what it is allowed to be.
0
version in the address, so a client keeps working
0
moments in a key's life that leave a row behind
0
route files behind the interface

Product figures from the platform’s own defaults - not customer averages

The mechanism

How it works.

01

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.

02

You see the key once and never again

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.

03

A key cannot reach further than the person it stands in for

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 person walks, so a key can never reach further than a person holding the same profile would.

04

A key that stops working has a row saying why

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.

Where it sits

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.

  1. 01
    Trigger

    the thing that happened first

  2. 02
    Enrol

    how somebody gets onto it

  3. 03
    Wait

    the pause, and what governs its length

  4. 04
    Branch

    the fork, and which side is taken

  5. 05
    Act

    the mail, the text, the task that goes out

  6. 06
    Measure

    what counts as it having worked

  7. 07
    Exit

    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

More in Automation & Flows

14 capabilities

Sequences, dispositions and outside triggers that act without being asked.

Sequence Builder

What you draw is the thing that runs, not a picture somebody then has to build. Thirteen kinds of step, and publishing never moves a lead off their own place.

Email Sequences

Enroll a lead once and the cadence carries them at their own pace. Nobody loses their place when the platform updates, and nobody is sent one message twice.

Branch Logic

The next step answers something the person actually did, not something your floor guessed. Opened, clicked, replied, or how the last call was dispositioned.

A/B Split Testing

Two versions of one cadence, side by side. Nobody lands on both and nobody switches halfway, because the side is decided by arithmetic on their own record.

Wait & Timing

Park a lead for minutes or days between steps. The delay you type is a floor rather than an appointment, so the sending hours can push it later, not earlier.

Sending Windows

Nobody gets a message at ten past three in the morning. A pause coming due outside the hours you set is pushed forward before the time is ever written down.

Suppression Lists

One do-not-contact list per workspace, read on enrollment and read again inside the send, so an address added mid-cadence still stops the next message.

Auto-Enrollment

Nobody builds the list by hand. New leads enroll themselves as they are created, and the four checks that can refuse one run on every route into a cadence.

Call Tasks in Sequences

The phone, in the middle of a mail cadence. A rep gets a call task with their name on it, and whatever they log at hang-up decides where that lead goes next.

Goal Tracking

Stop writing to somebody who already bought. Name the deal state that means the cadence worked, and reaching it stamps the run and takes the branch behind it.

Disposition Behaviors

The do-not-call mark, the callback and the task happen because a rep picked the code, not because they remembered. Twenty-six behaviors, twenty codes shipped.

Workflow Triggers

Six things set a CRM rule off: stage change, field update, new record, reassignment, schedule, inactivity. A filter stops it waking for everything that moves.

Conditional Logic

The check between a rule firing and an action actually running. Eight comparisons, every one an AND, so a rule covering either of two things gets built twice.

SMS in Sequences

A text step on the same canvas as the mail and the call. It lands in the thread the SMS inbox reads, so the cadence and whoever answers see one conversation.

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.

See pricing

14-day trial · no card · migration included