Webhooks and Event Delivery

Use this page when you need the automation model for SyncReserve rather than a general API overview.

What this capability is for

SyncReserve supports event-driven integrations in two complementary ways:

polling through GET /api/v1/platform/events/feed
push delivery through the /api/v1/platform/webhooks family

That matters because not every integration wants the same operating model. Some teams want a feed they can control and checkpoint themselves. Others want SyncReserve to push notifications as events happen.

When to use the event feed

The event feed is the better fit when an integration needs:

its own polling cadence
a cursor-based reader model
a simpler first integration before webhook infrastructure is in place
controlled consumption in test environments

This pattern is often attractive for analytics mirrors, internal automations, or agent systems that prefer reading from a stable stream rather than receiving inbound HTTP calls.

When to use webhooks

Webhooks are the better fit when an integration needs:

immediate push delivery
app-specific subscriptions
operational notifications into external systems
delivery observability and replay

The platform supports:

subscription management
delivery review
replay-oriented recovery

How webhook setup usually works

At a high level, a club connects an app, grants the right management scope, chooses the event families it cares about, and then uses logs or replay when delivery issues need attention.

Public docs stop at that boundary. They describe the workflow shape without turning the page into a payload-level implementation guide.

Live and test behavior

Webhook behavior can differ between live and test operation.

For clubs and partners, the key idea is that SyncReserve supports safer pre-production automation work instead of forcing every integration to start in live mode.

Operational confidence

The webhook surface is stronger because it includes operational follow-through, not only registration.

delivery logs support review
replay support helps recover from failed downstream handling

That is important for real integrations because the automation story is not complete if the platform cannot help a partner inspect and recover failed deliveries.

What this page is not

This page is a capability guide.

It is not:

a full event schema reference
a signature-verification tutorial
a detailed internal eventing design document

/docs/platform-api/platform-api-overview
/docs/platform-api/platform-auth-and-scopes
/docs/platform-api/mcp-tools-and-agent-workflows