Two ways in. If you are setting up a workspace, start with setting up your workspace. If you are wiring SealDeal to something else in code, start with building an integration. None of these pages need an account to read.
In the order you will meet them. The click-by-click setup lives in the product itself, under Integrations, once you have signed in; these are the pages that answer the questions the product does not, and you can read them first.
What SealDeal connects to, which direction each connection moves data, what it costs, and where in the product you switch it on. Also an explicit list of what it does not connect to.
The rule every draft is held to: each claim cites a source or is labelled as inferred, and a sentence that can do neither is removed or restated as an inference before the draft reaches your queue. Worth reading before you approve the first one.
What a complaint-rate warning means, what the providers actually measure, and what to do about it. The penalty lands on your whole domain, so this is the page to read first if you are moving from a handful of sends to a list.
Run a slice of your own accounts without the AI and compare. What to randomize, which test, and how optional stopping is prevented, so the number you get is one you can defend.
Seats, outbound packs and the CRM connector, with an estimator that does the arithmetic. Outbound attaches to Core or Pro; Free includes a 50-email trial instead.
Hosting, encryption, retention and subprocessors, in enough detail to hand to whoever asks you for it.
Everything the product does through its own interface is available over a documented REST API with scoped bearer tokens, and everything that happens in it can be pushed to you over signed webhooks. Mint a key at Integrations, then call GET /api/v1/me to confirm your auth before wiring anything else.
All 63 operations with the scope each one needs, plus authentication, pagination and rate limits. 17 scopes, so a token can be narrowed to exactly what it needs. Generated from the OpenAPI schema, so it cannot fall behind the API.
The machine-readable spec, for Postman, code generators, or an agent that would rather read a schema than a page.
The envelope, how to verify the HMAC signature, the retry schedule, and all 56 subscribable events. Includes the 17 reserved names that do not fire yet, because a silent integration is worse than a missing one.
Push buying signals in from Clay, Common Room or your own tooling over a signed webhook, and have them become evidence the engine can cite. Includes the exact accounting of what the endpoint can and cannot do, which is a shorter list than you might expect.
One page per RFC 7807 problem type, 18 in total. These are the exact URLs the API puts in the "type" field of an error, and each says whether retrying can ever succeed.
The reference sections are generated from the same definitions the running code uses: the endpoint tables from the OpenAPI schema, the event lists from the dispatcher catalog, the retry schedule from the delivery worker, and the error pages from the problem types the API actually emits. Tests fail the build if any of them fall out of step. It is worth saying because documentation that quietly disagrees with the system it describes is worse than none: it costs you an afternoon before you stop believing it.
Questions the docs do not answer: hello@sealdeal.ai