@syndew/oluso-admin-ui 0.0.0-stage → 1.30.1

package/help/en/admin.organizations.md

@@ -0,0 +1,38 @@
+---
+title: Organizations
+relatedTopics:
+  - Tenants | admin.tenants
+  - Users | admin.users
+  - Platform Clients | admin.platform.clients
+---
+
+Organizations are the top-level grouping in a multi-tenant deployment. Each organization can have its own tenants, members, and feature entitlements. This page is only visible to Super Admins.
+
+## Organization List
+
+The table shows all organizations with:
+
+- **Name** — organization name and description
+- **Slug** — the URL-friendly identifier
+- **Tenants** — how many tenants belong to this organization
+- **Status** — Enabled or Disabled
+- **Created** — when the organization was created
+
+Use the search bar to filter by name. Click a row to open the organization's detail page.
+
+## Creating an Organization
+
+Click **Add Organization** and provide:
+
+- **Name** (required) — display name for the organization
+- **Slug** (required) — unique URL identifier (lowercase, hyphens allowed)
+- **Description** — optional summary
+- **Website URL** — the organization's website
+- **Max Members** — limit on how many users can be added as members
+- **Max Tenants** — limit on how many tenants this organization can create
+
+## Tips
+
+- Each organization operates independently — users, clients, and data are isolated between organizations
+- Disabling an organization does not delete its tenants or data, but prevents access
+- Use the settings icon on each row to jump directly to the organization's detail page

package/help/en/admin.platform.clients.create.md

@@ -0,0 +1,34 @@
+---
+title: Create Platform Client
+relatedTopics:
+  - Platform Clients | admin.platform.clients
+  - Create Client | admin.clients.create
+  - Clients | admin.clients
+---
+
+Register a new platform-level OAuth 2.0 client. Platform clients operate across all tenants, making them suitable for admin dashboards, shared services, and internal tooling.
+
+## Form Sections
+
+The creation form has the same sections as a regular client:
+
+1. **Basic** — Client ID (required, unique), Client Name, Description, Client URI, Logo URI, Enabled
+2. **Authentication** — Grant types (Authorization Code, Client Credentials, etc.), security settings (require secret, require PKCE)
+3. **URIs & CORS** — Redirect URIs, post-logout redirect URIs, CORS origins
+4. **Scopes** — Which scopes this client can request (openid, profile, email, custom scopes)
+5. **Access Control** — Required permission, allowed roles, allowed users, identity provider restrictions
+
+## Recommended Setup
+
+For a typical admin portal or internal tool:
+
+- **Grant Type:** Authorization Code
+- **Require PKCE:** Yes
+- **Scopes:** `openid profile email`
+- **Redirect URI:** Your application's callback URL
+
+## Tips
+
+- The Client ID cannot be changed after creation — choose a descriptive, stable identifier
+- Platform clients appear on all tenants' login screens if no identity provider restrictions are set
+- See the Client Details help for a full explanation of each configuration tab

package/help/en/admin.platform.clients.detail.md

@@ -0,0 +1,28 @@
+---
+title: Platform Client Details
+relatedTopics:
+  - Platform Clients | admin.platform.clients
+  - Client Details | admin.clients.detail
+---
+
+View and edit a platform-level OAuth 2.0 client. The configuration tabs are identical to tenant-scoped clients — see the Client Details help for a full explanation of each section.
+
+## Tabs
+
+- **Basic** — Client ID (read-only), name, description, URIs, enabled status
+- **Authentication** — Grant types, PKCE settings, client secrets management
+- **URIs & CORS** — Redirect URIs, post-logout URIs, allowed CORS origins
+- **Scopes** — Allowed scopes for this client
+- **Access Control** — Permission requirements, role and user restrictions, identity provider restrictions
+- **Tokens** — Access token, identity token, and authorization code lifetimes
+- **Logout** — Front-channel and back-channel logout URIs
+- **Claims & Properties** — Custom client claims, properties, and claim prefix settings
+- **Advanced** — SSO settings, UI flow, device flow, PAR, and additional security options (JAR, DPoP, JWT ID)
+
+## Client Secrets
+
+Manage secrets in the **Authentication** tab. Secrets are hashed on creation and cannot be viewed again — copy the value immediately when generating a new one.
+
+## Key Difference from Tenant Clients
+
+The only difference is scope: platform clients are available across all tenants. All configuration options, token behavior, and security settings work the same way.

package/help/en/admin.platform.clients.md

@@ -0,0 +1,38 @@
+---
+title: Platform Clients
+relatedTopics:
+  - Clients | admin.clients
+  - Organizations | admin.organizations
+---
+
+Platform clients are system-level OAuth 2.0 applications that operate across all tenants and organizations. Unlike regular tenant-scoped clients, platform clients are available globally. This page is only visible to Super Admins.
+
+## Client List
+
+The table shows all platform clients with:
+
+- **Client ID** — the unique OAuth identifier
+- **Name** — display name of the client
+- **Status** — Enabled or Disabled
+- **Grant Types** — which OAuth 2.0 flows the client supports
+- **Created** — when the client was registered
+
+Click **Edit** to open the client detail page, or **Delete** to remove it.
+
+## Creating a Platform Client
+
+Click **Add Platform Client** to open the client creation form. The form is the same as for regular clients but the client will be registered at the platform level rather than scoped to a single tenant.
+
+## Platform vs Tenant Clients
+
+| | Platform Clients | Tenant Clients |
+|---|---|---|
+| **Scope** | Available across all tenants | Scoped to a single tenant |
+| **Managed by** | Super Admins only | Tenant admins |
+| **Use case** | Admin portals, shared services, internal tools | Customer-facing apps, third-party integrations |
+| **Visibility** | This page | Clients page |
+
+## Tips
+
+- Use platform clients for applications that need to authenticate users across multiple tenants (e.g., the admin portal itself)
+- Platform clients follow the same configuration options as regular clients — grant types, scopes, URIs, etc.

package/help/en/admin.resources.detail.md

@@ -0,0 +1,44 @@
+---
+title: Resource Details
+relatedTopics:
+  - Resources | admin.resources
+  - API Scopes | admin.api-scopes
+  - Clients | admin.clients
+---
+
+View and edit the full configuration of a protected resource.
+
+## Basic Information
+
+- **Resource URI** — the unique API identifier (read-only after creation)
+- **Display Name** — label shown on consent screens
+- **Description** — context for administrators
+- **Status** — Enabled or Disabled
+
+## Settings
+
+- **Show in Discovery Document** — include this resource in the `.well-known/openid-configuration` response so clients can discover it
+- **Created / Updated** — timestamps
+
+## Allowed Scopes
+
+The API scopes associated with this resource. When a client requests a token for this resource, only these scopes can be granted.
+
+Click **Add Scope** to associate an existing API scope with this resource. The modal shows all unassigned scopes — select one or more and save.
+
+Remove a scope by clicking the remove button next to it. This does not delete the scope itself, only the association.
+
+## User Claims
+
+Claims included in access tokens when this resource is the audience. For example, a user management API might include `role` and `department` claims.
+
+Click **Edit Claims** to:
+
+- Add custom claim types by name
+- Remove existing claims
+- Pick from common suggestions: `sub`, `email`, `name`, `role`, `preferred_username`, etc.
+
+## Tips
+
+- Scopes and claims work together — scopes control what the client is allowed to do, claims provide identity context
+- A scope can be shared across multiple resources if the same permission applies to several APIs

package/help/en/admin.resources.md

@@ -0,0 +1,43 @@
+---
+title: Resources
+relatedTopics:
+  - API Scopes | admin.api-scopes
+  - Clients | admin.clients
+---
+
+Resources represent protected APIs that clients can request access to. They follow the OAuth 2.0 Resource Indicators specification (RFC 8707), allowing clients to specify which API they intend to call when requesting tokens.
+
+## Resource List
+
+The table shows all registered resources with:
+
+- **Resource URI** — the unique identifier for the API (e.g., `https://api.example.com`)
+- **Display Name** — a human-readable label
+- **Status** — Enabled or Disabled
+- **Scopes** — how many API scopes are associated with this resource
+- **Created** — when the resource was registered
+
+Click a row to view or edit the resource's details.
+
+## Creating a Resource
+
+Click **Add Resource** and provide:
+
+- **Resource URI** (required) — the API's base URI, used as the `resource` parameter in OAuth requests
+- **Display Name** — shown on consent screens and in the admin UI
+- **Description** — additional context for administrators
+- **Enabled** — whether clients can request this resource
+- **Show in Discovery** — include in the `.well-known/openid-configuration` response
+
+## How Resources Work
+
+1. Register the resource with its URI
+2. Associate API scopes with the resource
+3. Clients include `resource=https://api.example.com` in their token request
+4. The issued access token is audience-restricted to that resource
+
+## Tips
+
+- Each resource should represent a distinct API or microservice
+- The resource URI should match the audience (`aud`) claim your API validates
+- Associate scopes to control fine-grained permissions within each resource

package/help/en/admin.roles.md

@@ -0,0 +1,33 @@
+---
+title: Roles & Permissions
+relatedTopics:
+  - Users | admin.users
+  - Grants | admin.grants
+---
+
+Roles define sets of permissions that control what users can see and do in the admin portal. Assign roles to users to grant them the appropriate level of access.
+
+## Built-in Roles
+
+- **SuperAdmin** - full access to all platform features across all organizations
+- **OrgAdmin** - full access within a single organization
+- **Custom roles** - create your own with fine-grained permissions
+
+## Creating a Role
+
+Click **Add Role** and:
+
+1. Give the role a descriptive **Name** (e.g., "Team Manager", "Report Viewer")
+2. Select the **Permissions** this role should grant
+3. Save the role
+
+## Permission Categories
+
+Permissions are organized by module:
+
+- **Core** - users, clients, resources, roles, settings
+- Each enabled module contributes its own permission category for its features and records
+
+## Assigning Roles
+
+Navigate to a user's detail page and add roles in the **Roles** section. Users can hold multiple roles; their effective permissions are the union of all assigned role permissions.

package/help/en/admin.settings.license.md

@@ -0,0 +1,39 @@
+---
+title: License
+relatedTopics:
+  - Settings | admin.settings
+  - Module Seats | admin.module-seats
+  - Subscription | admin.billing.subscriptions
+---
+
+View and manage the license key that activates your tenant's enabled modules and feature flags.
+
+## License Status
+
+The page displays the current license state:
+
+- **Tier** — the plan associated with the licence (e.g. Starter, Pro, Enterprise)
+- **Issued** — date the license was generated
+- **Expires** — expiry date, with warning indicators as the date approaches
+- **Modules** — list of modules unlocked by this license
+- **Seat caps** — per-module seat limits where applicable
+
+## Updating the License
+
+Paste a new license key into the **License Key** field and click **Apply**. The key is validated server-side before being stored. If valid:
+
+- New modules become visible in navigation immediately
+- Seat caps update to the new tier
+- Expiry warnings are recalculated
+
+If invalid, the existing license remains active and an error explains why (expired, signature mismatch, wrong tenant ID, malformed).
+
+## Removing a License
+
+Clearing the field and saving reverts to the default trial/free tier. Any modules outside that tier are hidden until a valid licence is reapplied.
+
+## Tips
+
+- Keep your license key in a password manager — it's a one-time issuance from the platform owner.
+- Set a calendar reminder a month before expiry to request a renewal key from your account manager.
+- If a module disappears from navigation, check this page first — an expired or downgraded license is the most common cause.

package/help/en/admin.settings.md

@@ -0,0 +1,70 @@
+---
+title: Settings
+relatedTopics:
+  - Signing Keys | admin.signing-keys
+  - Clients | admin.clients
+---
+
+Configure platform-wide settings for authentication, tokens, security, and CORS. Changes are saved per-tenant.
+
+## General
+
+- **Use Journey-Based Flow** — switch between the journey builder UI and standalone login/register pages
+- **Allow Self Registration** — let users create their own accounts
+- **Require Email Verification** — new users must verify their email before they can sign in
+- **Require Terms Acceptance** — show a terms checkbox during registration
+- **Terms of Service / Privacy Policy URLs** — links shown on the registration page
+- **Allowed Email Domains** — restrict self-registration to specific domains (comma-separated)
+
+## Tokens
+
+Default lifetimes applied to new clients. Individual clients can override these values.
+
+| Setting | Default | Description |
+|---|---|---|
+| **Access Token Lifetime** | 3600s (1 hour) | How long access tokens are valid |
+| **Identity Token Lifetime** | 300s (5 minutes) | How long ID tokens are valid |
+| **Refresh Token Lifetime** | 2592000s (30 days) | How long refresh tokens can be used |
+
+## Security
+
+- **Require HTTPS** — reject non-TLS requests
+- **Emit Static Claims** — include standard claims in all tokens
+- **Enable Backchannel Logout** — support server-to-server logout notifications
+
+## CORS
+
+Control which origins can make cross-origin requests to the token and authorization endpoints.
+
+- **Allow All Origins** — accept requests from any origin (not recommended for production)
+- **Allowed Origins** — comma-separated list of permitted origins
+
+## Dynamic Client Registration
+
+Enable RFC 7591 for programmatic client registration:
+
+- **Enable DCR** — turn on the registration endpoint
+- **Allow Open Registration** — anyone can register clients without an initial access token
+- **Require PKCE** — dynamically registered clients must use PKCE
+- **Allowed Scopes / Grant Types** — restrict what registered clients can request
+
+
+## WhatsApp
+
+Connects the organisation's WhatsApp Business number (Meta Cloud API) for every module that sends notifications. Credentials are stored encrypted.
+
+- **Setup** — phone number ID, access token, WhatsApp Business Account ID (for templates), app secret (for webhooks) and a default country used to complete local phone numbers. **Test connection** calls Meta with your credentials and records the verified name and number.
+- **Webhook** — paste the callback URL and verify token into Meta's app configuration and subscribe to the *messages* field. Inbound messages open the 24-hour reply window, STOP and START replies update consent, and delivery receipts (sent, delivered, read, failed) update the notification log.
+- **Templates** — Meta only accepts free-form text within 24 hours of a person's last message; anything the organisation starts must use an approved template. Sync templates here, then pick them in a workflow's Send WhatsApp step.
+- **Contacts & consent** — every number messaged or received appears with its consent state and whether its reply window is open. Opted-out numbers are never messaged until they opt back in (by replying START or by an administrator).
+- **Send a test** — sends one template or text message with the saved credentials.
+
+## Business verification
+
+Shown when the business verification module is installed. Configures the providers the **Business Verification** journey step uses. Needs the *Manage business verification providers* permission.
+
+- **Providers** — Dojah (App ID and secret key) and Youverify (API secret key). Choose Sandbox while testing (test data, not billed) or Live. Secrets are stored encrypted, never shown again, and cleared when you switch environment. **Test saved credentials** calls the provider's free endpoint (Dojah's wallet balance, Youverify's supported countries); it never buys a lookup.
+- **Hosted verification (Dojah)** — for the step's *hosted* mode, also save the public key, the EasyOnboard widget ID of your KYB flow and the webhook secret, and give Dojah the **Webhook URL** shown on the provider (subscribe the *kyc_widget* service to it). The URL is on this organisation's own domain.
+- **Country routing** — which enabled provider verifies businesses in each country. There is no fallback: a country without a provider can't be verified.
+- **Reuse registry results** — within this many days, verifying the same registration number again reuses the earlier registry result instead of paying for a new lookup. 0 always looks up again.
+

package/help/en/admin.signing-keys.md

@@ -0,0 +1,47 @@
+---
+title: Signing Keys
+relatedTopics:
+  - Settings | admin.settings
+  - Clients | admin.clients
+---
+
+Manage the cryptographic keys used to sign tokens (JWTs). Proper key management ensures that tokens cannot be forged and that key rotation happens without downtime.
+
+## Key Table
+
+Each key shows:
+
+- **Name / Key ID** — identifier and optional client assignment
+- **Type / Algorithm** — RSA, EC, or Symmetric with the specific algorithm and key size
+- **Status** — Active (can sign), Retired (verify only), or Expired
+- **Expires** — expiration date, with a warning for keys expiring soon
+- **Usage** — how many signatures the key has produced and when it was last used
+
+## Key Actions
+
+- **Generate Key** — create a new signing key with a chosen algorithm, key size, and lifetime
+- **Rotate Keys** — retire the current active key and activate the next one
+- **Revoke** — immediately retire an active key (requires a reason)
+- **Delete** — permanently remove an inactive key
+
+## Automatic Rotation
+
+Click **Rotation Settings** to configure automatic key rotation:
+
+- **Key Lifetime** — how long a key stays active before rotation
+- **Rotation Lead Time** — how far in advance to generate the next key
+- **Grace Period** — how long retired keys continue to validate existing tokens
+- **Maximum Keys** — limit on how many keys are retained
+
+## How Rotation Works
+
+1. A new key is generated before the active key expires (lead time)
+2. The old key is retired — it can still verify tokens but no longer signs new ones
+3. After the grace period, the retired key can be safely deleted
+4. Clients that cache the JWKS document will pick up new keys on their next refresh
+
+## Tips
+
+- Always keep at least one active key — without it, no tokens can be issued
+- RSA 2048+ or EC P-256 are recommended for production
+- The JWKS endpoint (`.well-known/jwks`) automatically publishes all active and retired keys

package/help/en/admin.tenants.detail.md

@@ -0,0 +1,58 @@
+---
+title: Tenant Settings
+relatedTopics:
+  - Tenants | admin.tenants
+  - Settings | admin.settings
+---
+
+Configure a tenant's identity policies, password requirements, and enabled features. Changes here apply only to this specific tenant.
+
+## General
+
+### Tenant Details
+
+- **Name** and **Display Name** — how the tenant appears in the UI
+- **Description** — optional context
+- **Custom Domain** — vanity domain for this tenant's login pages
+- **Enabled** — toggle the tenant on or off
+- **Hide Embed Branding** — remove platform branding from hosted pages
+
+### Password Requirements
+
+Control the complexity rules for user passwords:
+
+- **Min / Max Length** — character count bounds
+- **Required Unique Characters** — minimum distinct characters
+- **Require Digit** — at least one number
+- **Require Lowercase / Uppercase** — case requirements
+- **Require Special Character** — at least one symbol
+
+### Password Lifecycle
+
+- **Password History Count** — how many previous passwords to remember (prevents reuse)
+- **Password Expiration Days** — force password changes after N days (0 = never)
+
+### Account Lockout
+
+- **Max Failed Attempts** — lock the account after this many consecutive failures
+- **Lockout Duration** — how long the lockout lasts (in minutes)
+- **Block Common Passwords** — reject passwords found in common breach lists
+
+### Custom Validation
+
+- **Custom Regex Pattern** — an additional regex that passwords must match
+- **Custom Error Message** — shown to users when the regex fails
+
+Use **Reset to Defaults** to revert all password and lockout settings, or **Save Settings** to apply changes.
+
+## Features
+
+A grid of feature toggles controlling which modules are available in this tenant. Features must first be enabled at the organization level before they can be activated here.
+
+Each card shows the feature name, description, and a toggle switch.
+
+## Tips
+
+- Password policies apply to new passwords only — existing passwords are not retroactively validated
+- Lockout protects against brute-force attacks without requiring MFA
+- The custom regex is useful for industry-specific compliance (e.g., requiring passwords to contain no part of the username)

package/help/en/admin.tenants.md

@@ -0,0 +1,46 @@
+---
+title: Tenants
+relatedTopics:
+  - Organizations | admin.organizations
+  - Settings | admin.settings
+---
+
+Tenants provide data isolation within an organization. Each tenant has its own users, clients, settings, and feature set. This page is visible to Organization Admins.
+
+## Tenants Tab
+
+The table lists all tenants in your organization:
+
+- **Name**: the tenant's display name
+- **Identifier**: the unique slug used in URLs and API requests
+- **Environment**: Development, Staging, or Production
+- **Status**: Enabled or Disabled
+- **Created**: when the tenant was created
+
+Use the search bar to filter by name. Click the settings icon to open a tenant's configuration page.
+
+### Creating a Tenant
+
+Click **Add Tenant** and provide:
+
+- **Name** and **Display Name**
+- **Identifier** (required): unique slug, cannot be changed later
+- **Environment**: Development, Staging, or Production
+- **Description**
+- **Custom Domain**: optional vanity domain for this tenant. It's added to the tenant's **Domains** for verification; add the DNS TXT record shown there and verify it before the domain is used.
+
+The new tenant gets its Administrator and User roles. If setting it up fails, nothing is left behind and you see the reason. Assign someone the Administrator role from the organisation's members.
+
+## Settings Tab
+
+Organization-level settings shared across all tenants:
+
+- **Name** and **Slug** (read-only)
+- **Description**: update the organization's description
+- **Website URL**: the organization's website
+
+## Tips
+
+- Use the Environment field to distinguish between dev, staging, and production tenants
+- Each tenant is fully isolated: users in one tenant cannot access another unless explicitly granted access
+- Disabling a tenant blocks all logins without deleting data

package/help/en/admin.users.detail.md

@@ -0,0 +1,41 @@
+---
+title: User Details
+relatedTopics:
+  - Users | admin.users
+  - Roles & Permissions | admin.roles
+---
+
+View and manage all aspects of a user account. The detail page is organized into tabs.
+
+## Profile
+
+Core identity information: username, email, first name, last name, display name, phone number, and timestamps for creation, last update, and last login. A checkmark next to the email or phone indicates it has been verified.
+
+## Security
+
+Account security status and actions:
+
+- **Account Status** — Active or Disabled
+- **Lockout Status** — whether the account is currently locked, with an **Unlock** button
+- **Failed Login Attempts** — count of consecutive failures
+- **Reset Password** — set a new password for the user
+
+## Roles
+
+Lists all roles assigned to the user as badges. Click **Manage Roles** to add or remove roles from a checkbox list. A user's effective permissions are the union of all assigned roles.
+
+## Sessions
+
+Active authentication sessions for this user. Each row shows the client, IP address, user agent, and expiration time. You can revoke individual sessions or use **Revoke All** to terminate every active session.
+
+## MFA
+
+Multi-factor authentication status. If MFA is enabled, you can **Reset MFA** to clear the user's authenticator registration, requiring them to re-enroll on next login.
+
+## Claims
+
+Custom claims attached to the user's identity. These are included in tokens issued for this user. Use **Add Claim** to create new type/value pairs. Common claims include `department`, `employee_id`, or `cost_center`.
+
+## External Logins
+
+Linked external authentication providers (Google, Microsoft, GitHub, etc.). You can remove a linked provider, which will prevent the user from signing in with that provider until they re-link it.

package/help/en/admin.users.md

@@ -0,0 +1,56 @@
+---
+title: Users
+relatedTopics:
+  - Roles & Permissions | admin.roles
+  - Grants | admin.grants
+  - Settings | admin.settings
+---
+
+Manage user accounts across your identity platform. From here you can create, edit, disable, and delete users, as well as manage their roles and credentials.
+
+## User List
+
+The table shows all registered users with:
+
+- **User**: avatar, display name, and username
+- **Email**: address with a verification indicator
+- **Status**: Active or Disabled, with a Locked badge if the account is locked out
+- **Roles**: assigned roles (shows the first two, with a +N count for additional)
+- **Last Login**: the most recent authentication timestamp
+
+Click any row to open the user's detail page.
+
+## Creating a User
+
+Click **Add User** and fill in:
+
+- **Email** (required)
+- **Username** (required)
+- **Password**: either **Email an invite** (the default), which emails the user a link to set their own password, or **Set a password now**
+- **First Name** and **Last Name**
+- **Phone Number**
+- **Active**: whether the account is immediately usable
+- **Email Verified**: skip the email verification step
+
+### Invites
+
+An invite email comes from your organisation and carries a link to set a password on your organisation's own sign-in page. The email says how long the link lasts: your tenant's account-link lifetime (24 hours unless you've changed it). The password must meet your tenant's password policy, and the page shows its rules.
+
+If the email can't be sent (for example, email isn't set up), the user is still created and you're told why. Until the user sets a password, **Resend invite** in their row sends a fresh link.
+
+## Quick Actions
+
+Each row has action buttons for common operations without opening the detail page:
+
+- **Edit**: update the user's profile
+- **Manage Roles**: assign or remove roles
+- **Reset Password**: set a new password
+- **Resend invite**: send the set-password invite again (only for users who haven't set a password yet)
+- **Unlock**: clear a locked account (only appears if locked)
+- **Delete**: permanently remove the user
+
+## Tips
+
+- Use the search bar to find users by name or email
+- Disabling a user prevents login without deleting their account or data
+- Locked accounts are typically caused by too many failed login attempts. Use the Unlock action or configure lockout policy in Settings

package/help/en/admin.webhooks.detail.md

@@ -0,0 +1,41 @@
+---
+title: Webhook
+relatedTopics:
+  - Webhooks | admin.webhooks
+  - Clients | admin.clients
+  - Signing Keys | admin.signing-keys
+---
+
+Create or edit one webhook endpoint. Existing endpoints have two tabs: **Settings** and **Deliveries**.
+
+## Basics
+
+The name, an optional description, the URL that receives the POST requests, and whether the endpoint is active. Turn an endpoint off to pause deliveries without losing its configuration.
+
+## Events
+
+Events are grouped by module. Search by name or event type, and use the checkbox on a group to select or clear all of its events. Restricted events need the permission they name; without it you can't subscribe to them.
+
+## Authentication
+
+How each delivery proves it comes from Oluṣọ:
+
+- **HMAC signature (shared secret)** - each delivery is signed with a `whsec_` secret in the `X-Webhook-Signature` header. The secret is shown once, when the webhook is created or the secret is rotated.
+- **Signed by this tenant's issuer (no shared secret)** - each delivery carries a short-lived token signed with this tenant's issuer key. The receiver checks it against the issuer's public keys (its JWKS); nothing secret is shared. The page shows the JWKS URL to give the receiver.
+- **Static credential** - a fixed bearer token, username and password (Basic), or API key (`X-API-Key`), for receivers that only check a header. Deliveries are also HMAC signed. Credentials are stored encrypted and never shown again; leave the field blank to keep the current one.
+
+## Owning client
+
+The client this endpoint belongs to. Events this client causes itself (for example comments it writes through the Service API) are not sent back to it when **Skip own client events** is on. With issuer-signed delivery, the token names this client as its subject.
+
+## Sensitive data
+
+When the selected events include restricted ones, their confidential fields are withheld unless you authorise the endpoint. Authorising needs each restricted event's permission and records your name and the time.
+
+## Headers and version
+
+Extra headers sent with every delivery. Headers the delivery sets itself (such as `Authorization` and the `X-Webhook-` headers) can't be overridden. Don't put secrets in custom headers.
+
+## Deliveries
+
+Delivery counts, the recent delivery history, and a retry button for failed deliveries. Use **Send test event** to try the endpoint.