Configuration

The Configuration section is where you set up access control, authentication, and monetization for your Twin.

Requirements: Paid plan (Starter or above)

Access Control

Domain Verification

Verify ownership of your custom domain before enabling authentication features. The dashboard provides verification records to add to your DNS.

Authentication Methods

Configure how users sign in to access your Twin:

• Magic Link — Passwordless email authentication
• Google OAuth — Sign in with Google

Authentication is only available for custom domain deployments. Embedded widgets rely on the host platform’s authentication.

Access Modes

Control who can access your Twin:

Monetization

Charge users for access to your Twin through Stripe integration. For full details on how payments, checkout, tax compliance, and payouts work, see Monetization.

Platform Integrations

Sync app access from your external checkout or membership platform. Webhooks apply the access changes your platform sends; polling checks membership at configured intervals. Native Apple/Google purchases and Steno’s configured Stripe checkout use their existing billing integrations.

Supported Platforms

• Kajabi
• GoHighLevel (GHL)
• Circle
• Teachable
• Mighty Networks
• Custom webhook

Sync Methods

Configuration

For each integration:

• Platform API credentials
• Webhook URL and secret
• Polling interval (if applicable)
• Active/inactive toggle
• Access Tier when your app has multiple tiers

Open Users, click ⋯ beside Add User → Integration & settings, and find the Platform integration cards. Customer admins can copy each active integration’s full webhook URL. Each card shows the access tier assigned to that integration.

For tiered apps, configure a separate integration for each tier. For example, Personal may use basic and Business may use pro; use the actual keys configured for your app. Your checkout maps each plan to the corresponding webhook URL. The URL selects the tier, so adding tier or tierKey to the request body does not change access.

Customers sign into the same app and their account determines access. Send webhook requests from your backend to the copied URL:

https://dashboard.steno.ai/api/webhooks/platform-sync/<token>

Keep the full URL private. Its token authenticates requests, so no separate authorization header is required. Use the app’s sign-in URL for checkout redirects.

Setup Wizard

The dashboard provides a step-by-step wizard for configuring each integration.

For detailed platform-specific instructions, see the Platform Guides.

Webhook Format

Send an HTTP POST to the copied Custom integration URL with Content-Type: application/json. After your platform confirms that a customer should have access, send:

{
  "action": "provision",
  "email": "user@example.com",
  "name": "User Name",
  "provisionSource": "your-integration"
}

To remove access, send this to the integration for the customer’s current tier, using the same source:

{
  "action": "deprovision",
  "email": "user@example.com",
  "provisionSource": "your-integration"
}

Tier changes and account continuity

The flow is checkout → payment/access confirmation → customer email → tier webhook → account update → app access. Your platform decides when access should start or end; Steno applies the configured tier when the request arrives. A checkout-success redirect alone does not grant access.

Steno matches the email within the app and updates the existing account. Use the same sign-in email for purchases and plan changes. Provisioning creates an account only when no matching account exists; deprovisioning disables access without deleting the account or conversations.

For an upgrade or downgrade, send provision to the destination tier’s URL when the change takes effect. You do not need to deprovision first. Send changes in order for each customer. The custom webhook does not schedule changes or use event timestamps to reject an older grant.

The app refreshes access from the account. In apps with tiered coach access, existing conversations with unavailable coaches remain read-only.

Subscription events and ownership

Your external platform owns payment confirmation, subscription timing and grace rules. Steno owns the webhook-to-tier mapping and app access. Store-account administrators manage Apple/Google product availability, pricing and subscription settings.

These are access-sync requests. They do not charge, refund or cancel a subscription, and there are no custom actions named upgrade, downgrade, refund or billing_issue.

Responses and troubleshooting

Provisioning normally returns HTTP 200 with the account ID:

{
  "status": "success",
  "action": "provision",
  "userId": "example-account-id-123456"
}

Inspect the response body as well as the HTTP status, and verify the account’s access in Users during integration testing:

• HTTP 200 with "status": "ignored" means no action was taken. For Custom integrations, check the required fields and action.
• HTTP 400 can indicate invalid JSON, a reserved source or a userId shorter than 20 characters. HTTP 404 means the token does not match an active integration. HTTP 409 can indicate a missing/unknown configured tier or a conflicting supplied account ID.
• A deprovision request can return success without removing access if the account is missing or its current tier/source does not match. This protects a new tier from a delayed former-tier removal and preserves access managed by another source. Multiple active configurations for the same app, platform and tier also suppress webhook removal; ask Steno to review that setup.
• Confirm the resulting access even after success, especially for removal or new-account sign-in. An acknowledgement alone does not prove every downstream account operation completed. Investigate server errors and retry requests in order; do not replay an old tier grant after a newer change.

Questions? Contact support@steno.ai.