Connect a scoped API and verify webhook delivery

Connect a single workspace from its owner-only Workspace operations page. These interfaces are implemented in the repository; external callback delivery and account sessions still need the configured release environment. Use a test destination before relying on a live business automation.

Give a connection the permissions it needs

Create a named API key with an expiry and selected scopes. Save the one-time key in your integration's secret storage. Send it as an Authorization Bearer header; never place it in a public page or share link. Revoke a key when the connection ends.

An event-only connection receives a versioned envelope containing the event ID, kind, workspace, record ID, revision and occurrence time. It does not receive guest addresses, form answers or message bodies. Reading the referenced record requires its separate scope. For example, an integration that receives a guest update cannot read the guest list until you explicitly grant guest access.

For event polling, process each page and save its opaque cursor, even when nextCursor is null. Request after=cursor to resume. Feed positions are assigned after changes commit, so a slow transaction cannot disappear behind a newer cursor. Arrival order can differ from occurrence time: use the record revision to decide which state is current, and deduplicate by event ID. Follow nextCursor while it is present. Cursors belong to one workspace. Older event-ID cursors are accepted when available and may replay their anchor event; restart from the beginning if a legacy cursor is unavailable.

The OpenAPI document describes the implemented routes. The MCP endpoint discovers only the tools permitted by the current credential. It offers selected project, contact, conversation and task operations plus scoped assistant lookup, priced preparation, and exact-proposal approval. Assistant financial proposals require their separate finance scopes. These tools do not charge a card, issue a refund, or publish a schedule.

Review writes and keep their identity

Use a new request UUID for a new change, and retain that UUID when retrying the same request. A changed payload with a previously used UUID is rejected. A stale revision requires you to reload and review the current record; do not silently submit the old decision against a new revision.

Creating a workspace through the API requires an account session and a requestId. Repeating the same request returns the existing workspace; it cannot add another business, wedding, or billable membership. If a response is lost, retry unchanged details or refresh your workspace list before creating anything else. A replay does not restore access after a membership is revoked.

Email writes require approval of the recipient, subject and body. If you include private attachments, approve those exact files too and grant both message-write and asset-read scope. The response records the reviewed payload fingerprint. A queued message is persisted work, not proof of delivery.

Verify callbacks and review uncertain delivery

Create a signed webhook, retain its one-time signing secret, and verify the signature against the exact raw body and timestamp. Check the event ID before applying an effect at your destination: retries can deliver the same event more than once. Keep processing idempotent even when your first acknowledgement was lost.

The connection's attempt history distinguishes pending, accepted, failed and uncertain work. A successful HTTP response means the destination accepted the callback, not that every downstream action completed. Uncertain Slack deliveries stop for review so a lost response does not automatically create duplicate channel messages. Disabling a connection cancels pending work when the worker next checks it; inspect already accepted events at the destination.