The concepts matter more than the signatures
SentryFlow's integration surface is built around four ideas: a connector holds the narrowest credential that does its job, a step can require a named human, every run writes an append-only record, and anything that moves money is idempotent on an external reference. Those are the parts worth understanding before any endpoint signature.
Integration model
Each of these is a design decision with a consequence attached. Read them as the constraints any integration works inside, because they are the parts that do not change per endpoint.
The concepts below are the real execution model — connectors, approval gates, the audit record, idempotency. Endpoint signatures, SDK packages, and sandbox credentials are not published yet, so this page describes the design rather than inventing a reference to code against.
Connectors declare scope, per workflow
A connector is a credential plus the set of operations a workflow is allowed to perform with it. Scope is declared by the workflow that uses it rather than granted once at the account level, so two workflows sharing an integration do not share its permissions. Adding a step that needs a wider scope produces a consent request naming the specific addition, which is what makes scope creep a visible event instead of a silent upgrade.
- Granularity
- Per workflow, not per account
- Widening scope
- Requires fresh consent naming the addition
- Revocation
- Kills one workflow, not every workflow
Approval gates are per step, with bands
Any step can carry a gate with its own threshold and approver policy. Inside the band a run proceeds and is logged; outside it the run parks and waits for a named person. This is per step rather than per workflow because a workflow-level gate stops everything, which produces a queue so uniform that reviewers approve in bulk without reading — a control that yields a signature rather than a decision.
- Scope
- Per step
- Dual approval
- Can require two distinct named users
- Denial
- Reason from a fixed list, not free text
- Default thresholds
- None shipped, deliberately
The audit record is append-only and hash-chained
Every run, edit, approval, and denial is written with actor, resource, and outcome. Each entry includes a digest of its predecessor, so altering or deleting one breaks verification at that point and the check reports the first broken link rather than a bare pass or fail. This does not make tampering impossible; it makes it detectable, which is the achievable property and the one that carries weight in a review.
- Mutability
- Append-only
- Integrity
- Digest of predecessor per entry
- Recorded fields
- Actor, resource, outcome, timestamp
- Verification output
- First broken link, not pass/fail
Money movement keys on an external reference
Payout steps derive their idempotency key from the external reference — the order line, settlement id, or invoice number — never from the run id. A replayed run therefore resolves to the original settlement instead of creating a second one. Automatic retries on payment steps are off by default: a failed payout parks with its full input payload and waits for an operator to replay it deliberately.
- Key source
- External reference
- Payment retries
- Off by default
- On failure
- Parks with full input payload
- Second ceiling
- Credential cap below the approval threshold
AI steps redact before the call, and name their region
Redaction runs before the prompt is assembled, replacing identifiers and credential-shaped strings with typed placeholders. The mapping stays in your tenancy, so a response can be rehydrated without the model ever receiving the original value. Each step names its model and processing region in the workflow definition, which means region is not an account default that a settings change elsewhere can move.
- Redaction point
- Before prompt assembly
- Placeholder style
- Typed, not opaque tokens
- Mapping location
- Your tenancy
- Region
- Declared per workflow
A run is inspectable, and so is the decision behind it
Each run records the rule version that selected its input, the payload at each step, the gate outcomes, and the approver. The reason this matters more than a status feed: the question a review actually asks is narrow — this record was touched on the 14th, under which rule, approved by whom — and a dashboard that can show ten thousand events but not reconstruct one chain does not answer it.
- Retained per run
- Rule version, payloads, gates, approver
- Replay
- Operator-initiated, from parked payload
- Export
- Streams with a row count in the manifest
What is not here
If you followed a link expecting one of these, here is the honest position on each. A reference table with made-up endpoint paths would read as authoritative, and somebody would write a client against it.
REST API reference
Endpoint paths, request and response schemas, status codes.
Not published yet. Two route handlers are live today (a demo request and a newsletter signup); the execution API is not, so there is no endpoint table here. Publishing one before it answers would read as authoritative and someone would write a client against it.
Webhooks and retry semantics
Event payloads, signature verification, delivery and retry behaviour.
Not published, though the retry design is described above and is the part worth knowing: payment-adjacent steps do not retry automatically, and replay resolves to the original settlement rather than issuing a second one.
TypeScript SDK
Installation, client construction, typed method signatures.
No package is published. The site's own types live in `content/types.ts` and describe the shapes the interface renders, which is the closest thing to a public contract this build has.
Connector SDK
How to build a custom connector, and the scope declaration format.
Not published. The scope model it would implement is described under Connectors above: scope is declared per workflow, widening it requires fresh consent naming the addition, and revocation is scoped to a single workflow.
Sandbox keys
Test credentials to call the API against.
There are no credentials to issue, because there is no API to call. Nothing on this site requires authentication, and no key you could be given here would grant access to anything.
Rate limits and quotas
Requests per second, burst behaviour, quota headers.
No limits are documented because no metered endpoint exists. The per-plan run quotas shown on the pricing page are the only usage figures on this site, and they describe workflow runs rather than API calls.
If you are evaluating SentryFlow and need the detail that would normally live in a reference — auth model, error semantics, delivery guarantees — the fastest route is a conversation with an engineer rather than a document. We would rather answer the questionnaire you actually have to complete, including the questions where the answer is that a control does not exist yet.