Platform API Overview

Use this page when you need the public map of SyncReserve's integration surface rather than an internal implementation walkthrough.

What this section is for

SyncReserve exposes more than one machine-facing surface.

For a club evaluating the platform, or for an external agent deciding whether to integrate, the important point is that SyncReserve supports:

public discovery before authentication
authenticated tenant-scoped reads for profile and reporting data
automation patterns for events and webhooks
premium write actions for selected operational workflows
agent-oriented access through MCP

That is a different promise from the browser-based admin dashboard. Public docs in this section describe the external contract and the high-level admin AI controls that support automation. They do not document every internal route or workflow branch.

The four layers of access

1. Public discovery

Some surfaces can be read before any platform credential is issued.

llms.txt
public search and recommendation routes
public offering detail routes

These routes help agents, search systems, or external experiences understand what a club offers before they move into authenticated integration work.

2. Authenticated platform reads

The core platform contract exposes authenticated reads that are scoped to the tenant tied to the API key or OAuth installation.

tenant profile
analytics summary
export status
event feed access

This layer is what most dashboards, reporting tools, and external automations begin with.

3. Automation and event delivery

SyncReserve supports automation through both polling and push-based delivery.

event feed polling
webhook subscription management
delivery review and replay controls

That gives integrators a choice between event-feed consumers, webhook-driven workflows, or a mix of both.

4. Premium operational writes

Selected actions are available as premium platform writes.

booking-hold creation
check-in workflows

These are intentionally narrower than the full admin surface. SyncReserve exposes the actions that matter for automation while keeping the external contract more stable than UI-coupled internal routes.

How setup and runtime access fit together

The platform contract has both setup-time and runtime surfaces.

tenant admins bootstrap integrations from Settings > Developers
that workspace exposes app registration, API key lifecycle, webhook setup, usage, and docs handoff
platform apps are used to register external applications for a tenant
platform keys are used to create and manage credentials
OAuth is available for installable app patterns
runtime requests then use the scoped credential model that the tenant approved

This separation matters because it lets clubs control who can connect, what each integration can access, and whether the integration should run in test or live mode.

Where MCP fits

MCP is the interactive tool surface for external agents.

It sits on top of the same platform contract rather than replacing it. In practice that means:

public discovery can start with llms.txt
authenticated agent workflows move into MCP
stable read models should come before write actions
tenant and scope boundaries still apply to every tool call

What this page is not

This page is an external capability map.

It is not:

an exhaustive endpoint specification
a payload-by-payload contract reference
a replacement for internal admin implementation docs

/docs/reference/developers-workspace
/docs/platform-api/public-discovery-and-agent-entrypoints
/docs/platform-api/platform-auth-and-scopes
/docs/platform-api/webhooks-and-event-delivery
/docs/platform-api/mcp-tools-and-agent-workflows
/docs/ai-agents/ai-workspace