Integration plan
This is a typical path for one engineer and one compliance lead. Most teams get a first decision back the day they start, and go live in about two weeks.
The plan
| When | Step | Done when |
|---|---|---|
| Day 1 | Local | Sentinel running on a laptop; an event returns a decision and raises an alert |
| Day 1–2 | Install | Running in staging from the Docker image; /healthz green; a key per person and service |
| Day 2–3 | Entities | Customers, accounts and wallets synced with your own IDs |
| Day 3–5 | Shadow | Every money movement sent in sync mode, but your payment flow ignores the decision; compliance tunes rules |
| Week 2 | On the hot path | Payment service acts on decisions; fallback agreed and tested |
| Week 2 | Go live | Production database with backups, keys issued, first alerts worked and closed |
Step notes
Local. Follow the quickstart.
Install. Deploy the Docker image to staging with a PostgreSQL database. See Installation. Use the bootstrap key to sign in once, create real keys, then revoke it.
Entities. Send customers, accounts and wallets with POST /v1/entities. Use the IDs you already have, so you never need a mapping table.
Shadow. Send every money movement with mode=sync and a source.entity_id, and log the decision without acting on it. Alerts still appear. Your compliance lead watches the volume, backtests changes with the rules API, and has a second person approve each one. Async mode won't do here: it only stores events.
On the hot path. Start acting on review and block. Agree the fallback for when Sentinel can't be reached, and test it by taking Sentinel away in staging.
Go live. Point at the production database, issue keys, and work the first real alerts together.
Before you go live
- Every event carries an idempotency key, and retries reuse it.
- Every money event carries
source.entity_id. - Your service handles
allow,reviewandblock, and you've agreed whatreviewmeans: hold, or allow and watch. - You've decided what happens when Sentinel can't be reached, and tested it.
- Customer-facing errors never say why a payment was stopped.
- Each service and person has their own key, and the bootstrap key is revoked.
- At least two people can approve, so four-eyes works.
- The rules match your own reporting thresholds, not the built-in placeholders.
- PostgreSQL backups are running and a restore has been tested.