Webhooks

Receive real-time notifications about events in your Kravata Stack integration.

Kravata can call an endpoint on your server whenever a business event occurs, such as a user being created or an operation changing status. You register one webhook endpoint per event.

Register an endpoint

Use Register Webhook Endpoint:

curl -X POST https://test-api-kore.kravata.co/api/v1/integration-endpoints \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "operation.status_updated",
    "direction": "OUTBOUND",
    "url": "https://your-server.example.com/webhooks/kravata",
    "httpMethod": "POST",
    "authType": "NONE",
    "triggerEvent": "operation.status_updated",
    "timeoutMs": 30000,
    "retryConfig": { "max_attempts": 3, "initial_delay_ms": 1000, "multiplier": 4 }
  }'

Check your registrations with List Webhook Endpoints.

Events

Event	When it fires
user.created	A user is registered.
user.updated	A user’s data or status changes.
user.canceled	A user is canceled.
user.accepted_terms	A user accepts the Terms and Conditions.
auth.otp_requested	A one-time password is requested for a user.
wallet.created	A wallet is created.
operation.created	An operation (deposit, withdrawal, ramp) is created.
operation.status_updated	An operation changes status.
operation.transfer.created	A wallet transfer is created.
operation.transfer.status_updated	A wallet transfer changes status.
fiat.payin.completed	A pay-in is completed.
fiat.payin.rejected	A pay-in is rejected.
fiat.payout.completed	A payout is completed.
fiat.payout.rejected	A payout is rejected.
fiat.payment.completed	A payment is completed.

Delivery

• Kravata sends the event data as the JSON body, using the httpMethod you configured.
• A delivery is successful when your endpoint answers with a 2xx status within timeoutMs.
• Failed deliveries are retried up to max_attempts times with exponential backoff: the wait before retry n is initial_delay_ms × multiplier^(n-1) (1 s, 4 s, 16 s with the defaults).

Best practices

Respond quickly

Return a 2xx as soon as you receive the event and process it asynchronously. Slow responses count as failures once timeoutMs is exceeded.

Make your handler idempotent

Retries can deliver the same event more than once. Use the resource id and status to ignore duplicates.

Confirm with the API

Before acting on a critical event (for example, releasing goods after a payment), confirm the current state of the resource with the corresponding GET endpoint.