Overview
Webacy Webhooks push risk events to your endpoint in real time. Instead of polling our API, you receive a signed HTTPPOST the moment something happens.
Common use cases
Webhooks fit any workflow that needs to react the moment a token’s risk changes. Pick the filters that match your job and you only receive the events you care about.
For a full build-along, see the Webhook integration tutorial. The Example workflow below wires one of these use cases end to end.
Available events
DEPEG_TIER_CHANGE
Fires when a stablecoin or RWA token’s depeg risk tier changes (for exampleok → warning or warning → critical). Tiers follow the Depeg Monitor ratings: ok, watch, warning, and critical, plus premium for tokens trading above peg.
Example delivered payload
Example delivered payload
Subscribe (self-serve)
Webhook subscriptions are managed with your standard API key (thex-api-key header). Create a subscription, pick your filters, and we start delivering.
201 response returns the subscription, including a secret_key used to verify signatures:
See the API reference for the full subscription and delivery endpoints (
GET/PATCH/DELETE /webhooks/subscriptions/{id}, POST /webhooks/subscriptions/{id}/test, rotate-secret, and GET /webhooks/deliveries).
What you receive
Each delivery is an HTTPPOST to your webhookUrl with this body:
Verify the signature
The signature isHMAC-SHA256 of the JSON-serialized event object (compact, no spaces), keyed by your subscription’s secret_key, hex-encoded. It is sent both as X-Webhook-Signature and as signature in the body. Always verify before trusting a payload.
Example workflow
A worked end-to-end scenario: auto-hedge when a holding hitscritical. It ties together the subscription, signature check, and your reaction logic.
1
Subscribe to critical tier changes
Create a subscription scoped to the tokens you hold and the
critical tier, so you’re only paged on the events that require action. Save the secret_key from the response.2
Verify, then act on the event
In your receiver, verify the signature (see Verify the signature), then branch on
new_tier. Return any 2xx to acknowledge so the delivery isn’t retried.3
Dry-run before going live
Fire a synthetic delivery so you can confirm the full path — signature check plus your hedging logic — without waiting for a real depeg:
Delivery & retries
- Respond with any 2xx to acknowledge. A non-2xx response or timeout is retried with backoff, up to 5 attempts.
- Inspect delivery history with
GET /webhooks/deliveries(filter bystatus/eventType, paginated). Statuses includepending,success,failed, andmax_retries_exceeded. - Re-send a failed delivery with
POST /webhooks/deliveries/{id}/retry(rate-limited to once per delivery per 5 minutes). webhookUrlmust be a public HTTPS endpoint; private/loopback hosts are rejected.- Each subscription API call and each delivery consumes 1 CU.
Additional event types (in development)
The following Solana real-time events are not yet generally available — contact us if your use case needs them:TOKEN_LAUNCH_ANALYSIS— risk analysis at token launchTOKEN_TRANSACTION— per-transaction buy/sell alerts on monitored tokensHOLDER_ANALYSIS_UPDATE— holder-distribution snapshots at post-launch checkpoints
Related resources
Webhook integration tutorial
Stand up a receiver, verify signatures, and subscribe — step by step
Depeg Monitor API
The tiers and risk ratings that drive
DEPEG_TIER_CHANGE eventsStablecoin depeg monitoring
Use-case guide for tracking stablecoin and RWA peg health
Trading bot risk engine
Wire real-time risk signals into automated trading decisions
Getting access
DEPEG_TIER_CHANGE webhooks work with your existing API key. Don’t have one yet? Sign up at developers.webacy.co. For help sizing volume, email info@webacy.com.