API Access And Webhooks Capabilities Guide

`api_access` and `webhooks` are product-level capabilities layered on top of the API, integrations, and webhook platform infrastructure.

2 min read

api_access and webhooks are product-level capabilities layered on top of the API, integrations, and webhook platform infrastructure.

What `api_access` enables

When enabled, Tov+ allows planner-facing external API and integration flows for an occasion, including:

viewing the external integration catalog in a product context
creating and updating occasion-scoped integration connections
managing external credentials and partner connection state from the planner workspace

When enabled, Tov+ allows occasion-scoped outbound webhook subscription management for external consumers, including:

creating webhook subscriptions for an occasion
updating occasion-scoped webhook endpoints, secrets, and event subscriptions
treating occasion-owned outbound webhook configuration as a customer-facing product power

Without the capabilities, the underlying platform still exists:

internal HTTP APIs still power frontend, worker, admin, and integration infrastructure
inbound integration callbacks still use the server-side interface and security layer
outbound webhook infrastructure, event storage, signing, retries, and delivery state still exist
platform-admin operational visibility remains available

What disappears is the entitled product-facing ability to configure those external connectivity features for an occasion.

APIs remain the interface layer
integrations remain the scoped external-principal framework
webhooks remain the delivery and callback platform
api_access and webhooks decide whether those interfaces are exposed as customer-facing product powers

This keeps infrastructure existence separate from product entitlement.

planner integrations: the page still loads and shows capability state, catalog, and existing connection history, but connection-management actions are hidden when api_access is absent
admin integrations: support and ops can still inspect platform-wide integration health regardless of capability state
admin webhooks: platform admins can still inspect webhook operations; occasion-scoped subscription management requires webhooks, while platform-scoped operational subscriptions remain an admin-only infrastructure surface

Capability state does not replace security:

permissions still decide who may configure integrations or webhook subscriptions
feature flags still act as runtime kill switches
webhook signing, callback secret validation, integration scopes, and auth checks still apply even when a capability is enabled

api_access does not bypass integration adapter validation, secret requirements, or scoped action grants
webhooks does not bypass subscription validation, secret rules, or admin access
later partner-facing surfaces should continue using capability checks in addition to permission and security enforcement