Quickstart
Provision an organization, generate a safe ingestion key, send a test transaction, and confirm the operational path.
Safe sandbox path
Use fictional or approved test data before production traffic touches WatchTower.
Decision validation
Confirm the source system handles allow, review, and block-style outcomes correctly.
Operational confirmation
Validate alerts, cases, notifications, reports, and analyst access after ingestion works.
What you will do
This quickstart gets a new WatchTower tenant from first access to a safe sandbox transaction test. The goal is not just a 200 response; the goal is to confirm the decision, alert, case, and notification paths are usable.
By the end, you should have
- first admin access confirmed
- an organization-scoped ingestion key generated
- a test transaction submitted with idempotency
- a decision response inspected
- alert and case workflows validated with safe test traffic
- notification routing checked where enabled
Before you begin
Have these ready
- organization name
- first admin email
- sandbox or staging environment
- one fictional or approved test transaction payload
- a backend-only place to store the ingestion key
- the operator who will review the result in WatchTower
Do not use
- live customer data
- production API keys in tickets or chat
- real invite links in screenshots
- client-side code for ingestion keys
Quickstart steps
- Create or confirm the organization and first admin
- Generate the organization ingestion API key
- Store the key server-side
- Prepare request headers with x-api-key and idempotency-key
- Send a controlled test transaction
- Inspect the response decision
- Confirm the transaction appears in WatchTower
- Trigger a controlled suspicious test if needed
- Review alerts, cases, notifications, and reports
Use one stable idempotency key per logical transaction event. Reuse it only when retrying the same event after a transport failure.
Expected response handling
Your client should treat the WatchTower response as a decision object, not just a transport success. A valid response should be mapped by your system into the correct allow, review, or block-style behavior.
What to validate after the first request
- the transaction is visible in the console
- the decision and risk context make sense for the payload
- duplicate retry does not create a second logical transaction
- a suspicious test can create an alert where expected
- a case can be opened, assigned, and resolved
- notification delivery works for assignment or mention flows where enabled