The seals.deals API

Introduction

Everything you can see in seals.deals, your integrations can reach over HTTP.

The API is organised around the objects you already work with — contacts, companies, deals, products, activities and quotes, and the machinery behind them: forms and their fields, sequences and their steps, email templates, automations, and the record of everything that was sent and opened. It speaks JSON, uses standard HTTP verbs, and returns predictable status codes. Every request runs inside the workspace that issued the key and is bounded by that key’s permissions, so a key can never see or touch more than its creator can.

• Base URL — all endpoints live under https://crm.seals.deals/api/v1.
• JSON everywhere — send Content-Type: application/json; every response is JSON.
• Envelope — responses are wrapped as { "object": "…", "data": … }.
• Identifiers are UUIDs; timestamps are ISO 8601 (UTC); money uses ISO 4217 currency codes.

What’s different here

Five things worth knowing before you start building against it.

Quickstart

From zero to your first record in three steps.

curl https://crm.seals.deals/api/v1/contacts?limit=3 \
  -H "Authorization: Bearer YOUR_API_KEY"

const res = await fetch("https://crm.seals.deals/api/v1/contacts?limit=3", {
  headers: { "Authorization": `Bearer ${process.env.SEALS_API_KEY}` },
});
const { data } = await res.json();
console.log(data);

import requests

r = requests.get(
    "https://crm.seals.deals/api/v1/contacts",
    headers={"Authorization": f"Bearer {API_KEY}"},
    params={"limit": 3},
)
r.raise_for_status()
contacts = r.json()["data"]

Authentication

One bearer token per integration, scoped and revocable.

Every request must carry an API key as a bearer token:

Authorization: Bearer YOUR_API_KEY

Keys are created in Settings → API keys and hashed at rest — we never store the raw key, so copy it when it’s shown. Requests without a valid, unrevoked key get 401.

Scopes

A key carries one or more scopes. A request that needs a scope the key lacks returns 403.

Requests & responses

Predictable shapes in, predictable shapes out.

Send JSON bodies with Content-Type: application/json. Successful responses are wrapped in an envelope naming the object and carrying the payload in data — an array for lists, a single object for one record.

{
  "object": "contacts",
  "data": [
    {
      "id": "b1e2c3d4-5f6a-4b8c-9d0e-1f2a3b4c5d6e",
      "first_name": "Ada",
      "last_name": "Lovelace",
      "email": "ada@analytical.co",
      "lifecycle_stage": "lead",
      "created_at": "2026-07-09T08:15:00Z"
    }
  ]
}

{
  "object": "deals",
  "data": {
    "id": "f0b85efc-4e15-4d1d-93c0-ca8bb5450889",
    "name": "VEEWER Premium — Acme",
    "amount": 12000,
    "currency": "USD",
    "stage_id": "248c5509-b5a6-40a8-ad9e-020ac722989b"
  }
}

Pagination & search

List endpoints take four query parameters.

# Page 2 of companies matching "acme", 25 per page
curl "https://crm.seals.deals/api/v1/companies?q=acme&limit=25&offset=25" \
  -H "Authorization: Bearer YOUR_API_KEY"

const params = new URLSearchParams({ q: "acme", limit: "25", offset: "25" });
const res = await fetch(`https://crm.seals.deals/api/v1/companies?${params}`, {
  headers: { "Authorization": `Bearer ${key}` },
});

Errors

Standard HTTP status codes; a JSON body with an error message.

{ "error": "API key is missing the delete scope" }

Fair use

Not metered, not sold by the call — so please be reasonable with it.

There is no request budget attached to your plan, no per-seat allowance, and nothing to buy back when an import runs long. What we ask instead is that you page with limit/offset rather than firing many small calls in parallel, and that scheduled jobs run on a schedule rather than in a loop.

Handle 429 anyway. We may apply a per-key limit if a single integration starts affecting everyone else’s workspace, and a client that already backs off exponentially will not notice the day that happens.

Objects

What you can read, create, update, and delete.

Field reference

Writable fields for the create/update objects. Related ids (company_id, owner_id…) must belong to your workspace.

contacts

deals

products

activities

quotes & quote_items

email_templates

form_fields

sequence_steps

sequence_enrollments

List records

Returns an array of records the key is allowed to see, newest first. Combine with limit, offset and q.

Records in the recycle bin are left out — someone deleted them in the app, and they can be restored there for 90 days. So are a binned quote’s items and emails, and activities whose linked records are all in the bin.

Objects that are an ordered list rather than a history come back in their own order instead: form_fields and sequence_steps are returned by position, ascending, so the first row is the first question on the form and the first step of the sequence.

curl "https://crm.seals.deals/api/v1/deals?limit=20" \
  -H "Authorization: Bearer YOUR_API_KEY"

const res = await fetch("https://crm.seals.deals/api/v1/deals?limit=20", {
  headers: { "Authorization": `Bearer ${key}` },
});
const { data: deals } = await res.json();

r = requests.get(
    "https://crm.seals.deals/api/v1/deals",
    headers={"Authorization": f"Bearer {API_KEY}"},
    params={"limit": 20},
)
deals = r.json()["data"]

Retrieve one record

Fetch a single record by id. Returns data as an array with zero or one element. A record in the recycle bin comes back as zero elements, the same as an id that does not exist.

curl "https://crm.seals.deals/api/v1/companies?id=3f2a…" \
  -H "Authorization: Bearer YOUR_API_KEY"

Create a record

Send a JSON object of writable fields. Returns 201 with the created record. Requires the write scope. A link to a record in the recycle bin — a contact_id of a deleted contact, say — is refused with 400; restore the record first.

curl -X POST https://crm.seals.deals/api/v1/deals \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "VEEWER Premium — Acme",
    "amount": 12000,
    "currency": "USD",
    "company_id": "3f2a…",
    "pipeline_id": "c74d…",
    "stage_id": "248c…"
  }'

const res = await fetch("https://crm.seals.deals/api/v1/deals", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${key}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    name: "VEEWER Premium — Acme",
    amount: 12000,
    currency: "USD",
    company_id: companyId,
    pipeline_id: pipelineId,
    stage_id: stageId,
  }),
});
const { data: deal } = await res.json();

r = requests.post(
    "https://crm.seals.deals/api/v1/deals",
    headers={"Authorization": f"Bearer {API_KEY}"},
    json={
        "name": "VEEWER Premium — Acme",
        "amount": 12000,
        "currency": "USD",
        "company_id": company_id,
    },
)
deal = r.json()["data"]

Update a record

Partial update — send only the fields you want to change; everything else is left untouched. Requires the write scope. A record in the recycle bin returns 404, and a link to one returns 400.

curl -X PATCH "https://crm.seals.deals/api/v1/deals?id=f0b8…" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "amount": 15000, "stage_id": "9a1d…" }'

await fetch(`https://crm.seals.deals/api/v1/deals?id=${dealId}`, {
  method: "PATCH",
  headers: {
    "Authorization": `Bearer ${key}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ amount: 15000, stage_id: wonStageId }),
});

Delete a record

Deletes the record. Requires the delete scope — keys without it get 403.

Contacts, companies, deals and quotes go to the recycle bin, exactly as a delete in the app does: gone from the API at once, restorable in the app for 90 days, then purged. The response says which happened — {"deleted": true, "id": "…", "recycle_bin": true, "restorable_until": "…"}.

curl -X DELETE "https://crm.seals.deals/api/v1/contacts?id=b1e2…" \
  -H "Authorization: Bearer YOUR_API_KEY"

# → 200 { "object": "contacts", "data": { "deleted": true, "id": "b1e2…" } }

Run an automation

Enrols records in an enabled automation right now, by hand — the only way an automation whose trigger is “only when someone runs it by hand” ever runs, and a way to (re)run any other automation on records you choose. Requires the write scope.

The body names the records, or asks for every record that currently matches the automation’s conditions:

Every record goes through the same guards a triggered enrolment gets: the automation’s conditions, its re-enrolment rule, one live run per record, and at most 5 enrolments per record per day. Records outside the key creator’s edit scope are skipped, not enrolled. Instant steps (set a property, create a task, notify) happen inside the call; emails and delayed steps are queued and go out with the next scheduled run, usually within 15 minutes.

# Two specific contacts
curl -X POST "https://crm.seals.deals/api/v1/automations/161f…/enroll" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"record_ids":["b1e2…","c3d4…"]}'

# → 200 { "object": "automations", "data": { "automation_id": "161f…", "requested": 2, "enrolled": 1, "skipped": 1,
#          "reasons": { "not_found": 0, "no_access": 0, "filters": 1, "already_enrolled": 0, "active": 0, "cap": 0 } } }

# Every record that matches the automation's conditions
curl -X POST "https://crm.seals.deals/api/v1/automations/161f…/enroll" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"all":true}'

# → 200 { "object": "automations", "data": { …, "matching": 5, "requested": 5, "enrolled": 5, "skipped": 0, "truncated": false } }

Webhooks

Get notified when records change, instead of polling.

Register an endpoint under Settings → API & webhooks and subscribe to events. When a record is created, updated, or deleted, seals.deals sends a signed POST to your URL — so your systems stay in sync in real time without polling.

Events are <object>.created, <object>.updated, and <object>.deleted (e.g. deal.updated, contact.created).

Records that go to the recycle bin follow one rule. Going into it — deleted in the app or with DELETE — sends <object>.deleted; restoring it sends <object>.updated with the whole record. Nothing is sent while it sits in the bin, or when it is purged 90 days later. An activity whose linked records are all in the bin goes, and comes back, with them.

{
  "id": "d3f1…",                 // unique delivery id
  "event": "deal.updated",
  "data": { /* the full record */ },
  "sent_at": "2026-07-10T09:00:00Z"
}

X-Seals-Event:     deal.updated
X-Seals-Delivery:  d3f1…                 # matches payload.id
X-Seals-Timestamp: 1783934400
X-Seals-Signature: sha256=<hex>         # HMAC-SHA256 of the raw body,
                                        # keyed with your webhook secret