Actions and integration runtime

Separate customer setup from website runtime

An authorized customer configures providers, verified destinations, Routing, and action visibility inside Concierge. A public website may request an already-approved Action, but it must never configure providers or receive provider credentials.

Open a site-configured external intent

A site owner creates reusable forms in Actions, then defines an intent key and its form, conversation, or confirmed external-link behavior in Site Settings. Website code supplies only that key; the widget downloads and resolves the current site configuration.

• Do not put form contents, destination logic, provider credentials, or private configuration in website HTML.
• Concierge attaches page URL and referring intent to form submissions automatically; they are not visitor-editable fields.
• Unknown and disabled keys do nothing and never invent a response or navigate the visitor.
• External-link intents always show a Concierge confirmation before navigation.

1. 1Open Actions, then Forms, and create or select a reusable form when structured information is needed.
2. 2Open Site Settings, then External buttons.
3. 3Create a unique intent key and choose an enabled Concierge form, conversation flow, or an HTTP/HTTPS destination.
4. 4Enable and save the intent, then use Test to verify the customer experience.
5. 5Place the same key in the website button attribute or public JavaScript API.

<button type="button" data-concierge-intent="request-help">Request help</button>

window.Concierge.open({
  intentKey: "request-help"
});

Open an approved action from a page

Concierge Pages writes the stable action key into data-concierge-action and dispatches the existing concierge:open lifecycle. A custom page can use the same event after the site owner has configured and placed the Action.

• Use only released action keys: bookings, payments, promotions, videos, requests, calls, messages, and human_handoff.
• Treat the widget response as authoritative when an action is not ready or not customer-visible.
• Do not put an OAuth token, API key, Stripe secret, signing secret, or private provider URL in HTML or browser JavaScript.
• Preserve the visitor confirmation step before leaving Concierge for a payment or booking destination.

<button type="button" data-concierge-action="bookings">Book a consultation</button>

window.dispatchEvent(new CustomEvent("concierge:open", {
  detail: { actionKey: "bookings" }
}));

Use payment execution through the Concierge runtime

Native Stripe Checkout is created server-side through the public Concierge runtime. The runtime validates the site origin and configured payment action, returns a short-lived checkout URL, and exposes a reconciled execution status. These endpoints are intended for the shipped Concierge widget runtime, not direct secret-bearing browser integration.

1. 1The site owner connects Stripe and configures Payments in authenticated Concierge.
2. 2The site owner adds a customer-visible Payments placement and runs Test action.
3. 3The visitor confirms the secure payment handoff in the Concierge widget.
4. 4The widget requests execution from the allowed site origin and opens the returned Checkout URL.
5. 5Concierge reconciles status from its verified Stripe webhook and runtime status endpoint.

Choose an integration contract

Actions are customer outcomes; integrations are provider connections. Use the Ticket API, CRM Webhook, CRM inbound, or Routing webhooks only for the released server-to-server purpose documented by each guide.

• Use /integrations for the complete customer-facing availability inventory.
• Use /actions for the behavior, setup, providers, and surfaces of every customer action.
• Use the downloaded OpenAPI document as the operation allowlist.
• Do not infer native API support from the presence of a provider logo or a verified-link option.