Webhooks

Use polling in v1; outgoing reward webhooks are not part of the contract.

Outgoing webhooks are not available in the v1 partner payout contract. Use the authenticated read API to track reward status.

There is no webhook registration endpoint, signing-secret configuration, event-delivery schema, or retry schedule to integrate against in this release. Do not implement a listener based on illustrative webhook payloads previously shown on the site.

Track a reward instead#

Persist the reward ID when your backend receives acceptance, then refresh its resource from a scheduled job:

const reward = await slices.rewards.get(savedRewardId);

// Persist the current projection in your own application.
const projection = {
  id: reward.id,
  status: reward.status,
  statusReason: reward.statusReason,
  transactionHash: reward.deliveryEvidence?.transactionHash ?? null,
  checkedAt: reward.deliveryEvidence?.checkedAt ?? null,
  updatedAt: reward.updatedAt,
};

savedRewardId comes from your durable business-event record. This is a single refresh operation, not a tight polling loop. Keep the Slices key on your server.

You can also use List rewards for filtered periodic scans. Lists are not a delivery event stream and do not expose an updatedSince filter in v1.

Notify your own application#

After reading a changed reward, your backend may update its database and notify its own frontend through your existing infrastructure. That is your application's internal notification flow, not an outgoing Slices webhook.

Derive user-facing language from the actual fields. API acceptance is not delivery, a sent transfer is not a confirmed one, and old evidence should remain visible with its checkedAt.

About earlier examples#

The current contract does not use a webhook payload with type: reward.delivered, value_usd, a demo flag, or the old verified → funded → pending → delivered state sequence, nor the accepted → batched → published → claimable → delivered sequence of the batch-and-claim model retired on 2026-09-28.

Do not include those fields in issuance requests. They are not alternate names for the documented resource.

Future event delivery#

A later webhook capability would need a published schema, signature-verification procedure, retry and replay behavior, and explicit ordering/deduplication guidance before you depend on it. No release date or backward-compatible event format is committed here.

For v1, treat authenticated reads as the supported integration mechanism. The presence of this navigation page is not a signal to build a webhook dependency.

Next: Track rewards, Reward states, and Rate limits and retries.