raystack · rohanchkrabrty · Sep 29, 2026 · Sep 28, 2026 · Sep 28, 2026
diff --git a/docs/content/docs/admin-portal.mdx b/docs/content/docs/admin-portal.mdx
@@ -3,8 +3,6 @@ title: Admin Portal
 order: 13
 ---
 
-# Admin Portal
-
 The Admin Portal provides the Frontier administrators with a centralized interface for managing the Raystack/Frontier platform. This README will guide you through the installation, setup, and usage of the Admin Portal.
 
 ### Features

diff --git a/docs/content/docs/admin-settings.mdx b/docs/content/docs/admin-settings.mdx
@@ -3,8 +3,6 @@ title: Platform Preferences
 order: 14
 ---
 
-# Platform Preferences
-
 Platform wide settings can be configured using `Preferences` in Frontier. These preferences are stored in the database and are applied to all the users of the platform. Since these settings are crucial to the platform, only the platform admin can set these settings. In case the preferences are not set, the default values are used.
 
 The settings can be set using the preferences CLI or the API as described below.

diff --git a/docs/content/docs/authn/introduction.mdx b/docs/content/docs/authn/introduction.mdx
@@ -3,8 +3,6 @@ title: Overview
 order: 1
 ---
 
-# Overview
-
 Authentication is the process of verifying the identity of a user. This is done by checking the user's credentials
 against a database of verified users. The database is populated with user credentials during the registration process.
 If the credentials are valid, the user is granted access to the system. In some cases, the user's credentials are

diff --git a/docs/content/docs/authn/org-domain.mdx b/docs/content/docs/authn/org-domain.mdx
@@ -3,8 +3,6 @@ title: Domain Whitelisting
 order: 5
 ---
 
-# Domain Whitelisting
-
 In Frontier adding a user to an Organization can be done in either of these ways:
 - **By allowing all users from a Organization's trusted domains**: Say `raystack.org` is a trusted domain for `raystack` Organization, then any user with email address `*@raystack.org` can join the Organization without explicit invitation.
 - **By explicitely inviting individual users to the Organization**: Assuming a user with a public domain email address `@gmail.com` is required to be part of the `raystack` Organization, then the user can join the Organization only after accepting the invitation for the same.

diff --git a/docs/content/docs/authn/serviceuser.mdx b/docs/content/docs/authn/serviceuser.mdx
@@ -1,10 +1,8 @@
 ---
-title: Service User
+title: Service User Authentication
 order: 4
 ---
 
-# Service User Authentication
-
 Service User authentication is used to authenticate a service to another service where a human is not actively
 involved in the authentication process. For example, an external service is authenticating to a backend service.
 Before the authentication is started for a service user, a service user should exist in an organization. A service

diff --git a/docs/content/docs/authn/session.mdx b/docs/content/docs/authn/session.mdx
@@ -3,8 +3,6 @@ title: Session Management
 order: 3
 ---
 
-# Session Management
-
 Sessions are created automatically when a user successfully authenticates with Frontier. They allow the system to remember that a user is authenticated without requiring them to authenticate again for every request. Sessions are stored as encrypted cookies in the user's browser and are managed entirely by the Frontier SDK.
 
 :::note

diff --git a/docs/content/docs/authn/user.mdx b/docs/content/docs/authn/user.mdx
@@ -1,10 +1,8 @@
 ---
-title: User
+title: User Authentication
 order: 2
 ---
 
-# User Authentication
-
 To integration User authentication with a frontend application, you need to configure either of the supported strategies
 in Frontier. Frontier is a multi-tenant authentication server, so you can configure multiple strategies and use them in
 different applications. Each tenant has its own organization and each organization can have its own set of allowed

diff --git a/docs/content/docs/authz/custom-resources.mdx b/docs/content/docs/authz/custom-resources.mdx
@@ -3,8 +3,6 @@ title: Custom Resources and Permissions
 order: 7
 ---
 
-# Custom Resources and Permissions
-
 Frontier lets services register their own resource types (for example `compute/machine`).
 Once registered, Frontier can answer permission checks on those resources the same way it
 does for built-in types like projects and organizations.

diff --git a/docs/content/docs/authz/disable-vs-delete.mdx b/docs/content/docs/authz/disable-vs-delete.mdx
@@ -3,8 +3,6 @@ title: Disable vs Delete
 order: 6
 ---
 
-# Disable vs Delete
-
 Frontier treats **disabling** and **deleting** an entity (organization, project,
 group, or user) as two deliberately different operations. Knowing which one you
 want matters, because only one of them revokes access.

diff --git a/docs/content/docs/authz/overview.mdx b/docs/content/docs/authz/overview.mdx
@@ -3,8 +3,6 @@ title: Overview
 order: 1
 ---
 
-# Overview
-
 Authorization is the process of determining whether a user is allowed to perform an action. In the context of Frontier, authorization is the process of determining whether a user is allowed to perform an action on a resource. This is done after the system has already confirmed that user has proven their identity (authentication).
 
 Frontier authorization is based on the Role Based Access Control (RBAC) model. In RBAC, access is granted to users based on their roles. A role is a collection of permissions that can be assigned to a user. Permissions determine what actions are allowed on a resource. When a role is assigned to a user, the user is granted all the permissions that the role contains.

diff --git a/docs/content/docs/authz/permission.mdx b/docs/content/docs/authz/permission.mdx
@@ -3,8 +3,6 @@ title: Permissions
 order: 2
 ---
 
-# Permissions
-
 Permissions determine what operations are allowed on a resource. In Frontier, permissions are represented in the form of `service.resource.verb`, for example, `potato.cart.list`.
 
 Permissions often correspond one-to-one with API methods. That is, each service has an associated set of permissions for each API method that it exposes. The caller of that method needs those permissions to call that method. For example, if you want to create a new project you must have the projecr create permission.

diff --git a/docs/content/docs/authz/policy.mdx b/docs/content/docs/authz/policy.mdx
@@ -3,8 +3,6 @@ title: Policy
 order: 4
 ---
 
-# Policy
-
 Policies define the permissions and access control rules that govern user access to resources within the Frontier platform. By configuring policies, you can control and manage the level of access granted to users, groups, or service accounts.
 
 A policy in Frontier consists of a set of permissions associated with a role. The role determines the actions that a user can perform on specific resources.

diff --git a/docs/content/docs/authz/role.mdx b/docs/content/docs/authz/role.mdx
@@ -3,8 +3,6 @@ title: Roles
 order: 3
 ---
 
-# Roles
-
 A Role is a collection of permissions in Frontier. Roles are typically associated with one or more policies, which specify the permissions granted to the users. When a user is assigned a role, they inherit the permissions defined within that role. This simplifies access management by allowing administrators to assign roles to users rather than individually assigning permissions.
 
 Roles in Frontier is used to implement the [Role based acces control (RBAC)](../concepts/glossary.md#rbac)

diff --git a/docs/content/docs/basics.mdx b/docs/content/docs/basics.mdx
@@ -3,8 +3,6 @@ title: Basics
 order: 12
 ---
 
-# Basics
-
 Let's walk through the basics of Frontier. Any online platform that need to manage users require at least a authentication
 system. Once the user is authenticated, users should be persisted in Frontier and should work as an identity server.
 

diff --git a/docs/content/docs/billing/billing_customers.mdx b/docs/content/docs/billing/billing_customers.mdx
@@ -3,8 +3,6 @@ title: Billing Customers
 order: 2
 ---
 
-# Billing Customers
-
 Billing customers represent a customer entity with fields for storing billing related customer data like ID, organization ID (OrgID), currency etc. It also includes a field called `provider_id` which represents the ID of the customer in a billing engine (Frontier supports Stripe as the default billing engine).
 
 ## Configuration

diff --git a/docs/content/docs/billing/billing_subscriptions.mdx b/docs/content/docs/billing/billing_subscriptions.mdx
@@ -3,8 +3,6 @@ title: Billing Subscriptions
 order: 3
 ---
 
-# Billing Subscriptions
-
 Billing subscriptions enable billing customers to subscribe to recurring plans on the billing engine(currently, only Stripe). Subscriptions can be availed on a trial basis as well, where a trial period can be set for a plan, and customers can use the subscription for the trial period without paying any charges.
 On Frontier, plans and subscriptions are not weighted, and do not have any hierarchy. Thus, there is no inherent concept of upgrades and downgrades when it comes to subscripitons. Whenever a customer chooses to change their plan, the plan amounts are prorated as per the configuration in Frontier. Frontier provides various configurations around trials, default subscriptions, prorations etc. which are described in the next section.
 

diff --git a/docs/content/docs/billing/introduction.mdx b/docs/content/docs/billing/introduction.mdx
@@ -3,8 +3,6 @@ title: Introduction
 order: 1
 ---
 
-# Introduction
-
 ## Overview
 The Billing Service is a comprehensive solution for managing all billing-related operations in your Go service. It provides a robust Pricing Engine that allows you to create and manage various pricing plans and features, onboard customers, and handle all billing transactions.
 

diff --git a/docs/content/docs/concepts/architecture.mdx b/docs/content/docs/concepts/architecture.mdx
@@ -3,8 +3,6 @@ title: Architecture
 order: 1
 ---
 
-# Architecture
-
 Frontier is a cloud-native role-based authentication & authorization server that helps you secure microservices of given resources. It uses [SpiceDB](https://github.com/authzed/spicedb) authorization engine, which is an open source fine-grained permissions database inspired by [Google Zanzibar](https://authzed.com/blog/what-is-zanzibar/).
 
 We can configure role assignments to certain user or group on this resource as well during the resource creation.

diff --git a/docs/content/docs/concepts/glossary.mdx b/docs/content/docs/concepts/glossary.mdx
@@ -3,8 +3,6 @@ title: Glossary
 order: 2
 ---
 
-# Glossary
-
 Terminology and concepts used in Frontier documentation.
 
 ### Access Token

diff --git a/docs/content/docs/configurations.mdx b/docs/content/docs/configurations.mdx
@@ -3,8 +3,6 @@ title: Configuration
 order: 11
 ---
 
-# Configuration
-
 Frontier binary contains both the CLI client and the server. Each has it's own configuration in order to run. Server configuration contains information such as database credentials, spicedb connection, log severity, etc. while CLI client configuration only has configuration about which server to connect.
 
 ## Server Setup

diff --git a/docs/content/docs/contribution/contribute.mdx b/docs/content/docs/contribution/contribute.mdx
@@ -3,8 +3,6 @@ title: Contribution Process
 order: 1
 ---
 
-# Contribution Process
-
 The following is a set of guidelines for contributing to Frontier. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request. Here are some important resources:
 
 - [Concepts](https://raystack.github.io/frontier/concepts/architecture) section will explain you about Frontier architecture,

diff --git a/docs/content/docs/deployment-guide.mdx b/docs/content/docs/deployment-guide.mdx
@@ -1,10 +1,8 @@
 ---
-title: Deployment Guide
+title: Frontier Admin Console — Deployment Guide
 order: 16
 ---
 
-# Frontier Admin Console — Deployment Guide
-
 How a [raystack/frontier](https://github.com/raystack/frontier) admin console deployment is built,
 configured, deployed, verified, and rolled back. Applies to any Helm-on-Kubernetes deployment.
 

diff --git a/docs/content/docs/index.mdx b/docs/content/docs/index.mdx
@@ -3,8 +3,6 @@ title: Introduction
 order: 1
 ---
 
-# Introduction
-
 Welcome to the introductory guide to Frontier! We cover what Frontier is, what problems it can solve, how it works, and how you can get started using it. If you are familiar with the basics of Frontier, the guides provides a more detailed reference of available features.
 
 ## What is Frontier?

diff --git a/docs/content/docs/installation.mdx b/docs/content/docs/installation.mdx
@@ -3,8 +3,6 @@ title: Installation
 order: 10
 ---
 
-# Installation
-
 There are several approaches to install Frontier.
 
 1. [Using a pre-compiled binary](#binary-cross-platform)

diff --git a/docs/content/docs/local-setup.mdx b/docs/content/docs/local-setup.mdx
@@ -1,10 +1,8 @@
 ---
-title: Local Setup
+title: Frontier — Frontend & Local Setup
 order: 9
 ---
 
-# Frontier — Frontend & Local Setup
-
 Local dev guide for running **Frontier** (backend + frontend) on macOS.
 
 **Before you start**

diff --git a/docs/content/docs/prospects/introduction.mdx b/docs/content/docs/prospects/introduction.mdx
@@ -3,8 +3,6 @@ title: Introduction
 order: 1
 ---
 
-# Introduction
-
 ## Overview
 Prospects in Frontier stores and manage subscription preferences for various activities like newsletters, blog updates, and marketing communications. Unlike user preferences which are tied to registered accounts (registered account means record is present in users table), Prospects is designed to handle subscriptions for non-registered users.
 

diff --git a/docs/content/docs/reconcile.mdx b/docs/content/docs/reconcile.mdx
@@ -3,8 +3,6 @@ title: Reconcile
 order: 15
 ---
 
-# Reconcile
-
 Frontier can manage parts of its platform configuration from a YAML file instead of
 one-off API calls. You write down what should exist, and the `frontier reconcile` command
 makes the server match it. The `frontier export` command does the reverse: it prints what

diff --git a/docs/content/docs/reference/api-auth.mdx b/docs/content/docs/reference/api-auth.mdx
@@ -3,8 +3,6 @@ title: Authorization for APIs
 order: 4
 ---
 
-# Authorization for APIs
-
 There are 3 ways to authenticate in Frontier via APIs
 1. API Token
 2. Client Credentials

diff --git a/docs/content/docs/reference/api-definitions.mdx b/docs/content/docs/reference/api-definitions.mdx
@@ -3,8 +3,6 @@ title: Proto Definitions
 order: 8
 ---
 
-# Proto Definitions
-
 [Raystack/Proton](https://github.com/raystack/proton) is an open-source project developed by [Raystack](https://github.com/raystack) (Open DataOps Foundation) that provides a unified way to define and manage APIs in a microservices architecture. It aims to simplify the development and deployment of APIs by abstracting away the underlying implementation details.
 
 In Raystack/Proton, the [Protobuf (protocol buffers)](https://protobuf.dev/) definitions are used to describe the structure and behavior of APIs. Protobuf is a language-agnostic binary serialization format developed by Google. It allows you to define the data models and API endpoints using a simple and concise syntax.

diff --git a/docs/content/docs/reference/billing-configurations.mdx b/docs/content/docs/reference/billing-configurations.mdx
@@ -3,8 +3,6 @@ title: Billing Configurations
 order: 5
 ---
 
-# Billing Configurations
-
 Frontier provides billing and subscription related capabilities, which can be customized using various configs. Frontier uses Stripe as the billing engine to manage payments and subscriptions. For more details on concepts related to billing on Frontier, please [refer to this guide](../billing/introduction.md).
 
 This document provides instructions on how to configure the billing settings for managing payment and subscriptions using Frontier.

diff --git a/docs/content/docs/reference/cli.mdx b/docs/content/docs/reference/cli.mdx
@@ -3,8 +3,6 @@ title: CLI
 order: 6
 ---
 
-# CLI
-
 ## `frontier auth`
 
 Auth configs that need to be used with frontier

diff --git a/docs/content/docs/reference/configurations.mdx b/docs/content/docs/reference/configurations.mdx
@@ -3,8 +3,6 @@ title: Server Configurations
 order: 1
 ---
 
-# Server Configurations
-
 <details>
 <summary> Sample Config </summary>
 

diff --git a/docs/content/docs/reference/metaschemas.mdx b/docs/content/docs/reference/metaschemas.mdx
@@ -3,8 +3,6 @@ title: MetaSchemas
 order: 7
 ---
 
-# MetaSchemas
-
 MetaSchemas in Frontier are default JSON-schemas designed to validate metadata that is included in the body of a resource. These schemas provide a standard way of describing the expected structure and content of metadata, which can be used to ensure consistency and accuracy of metadata across different resources.
 
 ## Why MetaSchemas?

diff --git a/docs/content/docs/reference/shell-autocomplete.mdx b/docs/content/docs/reference/shell-autocomplete.mdx
@@ -3,8 +3,6 @@ title: Shell Autocompletion
 order: 9
 ---
 
-# Shell Autocompletion
-
 ### Bash auto-completion
 
 The Frontier completion script for Bash can be generated with `frontier completion bash`. Sourcing this script in your shell enables the Frontier completion.

diff --git a/docs/content/docs/reference/smtp.mdx b/docs/content/docs/reference/smtp.mdx
@@ -3,8 +3,6 @@ title: SMTP Server Configurations
 order: 2
 ---
 
-# SMTP Server Configurations
-
 Frontier can be used to send invites to users to join an organization currently or send OTPs (One Time Password) for verification. For this it implements a mailer service which provides the functionality to send emails using the configured [SMTP(Simple Mail Transfer Protocol)](https://datatracker.ietf.org/doc/html/rfc2821) server. This involves establishing a connection with the SMTP server, authenticating with the provided credentials, and delivering the email to the specified recipients.
 
 This document provides instructions on how to configure the SMTP settings for sending emails using the mailer configuration in Frontier.

diff --git a/docs/content/docs/reference/webhook.mdx b/docs/content/docs/reference/webhook.mdx
@@ -3,8 +3,6 @@ title: Webhook
 order: 3
 ---
 
-# Webhook
-
 Webhooks are a way to send frontier activity events to an external service. Frontier supports sending events to a webhook 
 URL when a user performs an action in the system. This allows you to integrate Frontier with other services and automate workflows.
 

diff --git a/docs/content/docs/sdk/web/admin/components.mdx b/docs/content/docs/sdk/web/admin/components.mdx
@@ -3,8 +3,6 @@ title: Components
 order: 2
 ---
 
-# Components
-
 All view components are exported from `@raystack/frontier/admin`.
 
 ```tsx

diff --git a/docs/content/docs/sdk/web/admin/overview.mdx b/docs/content/docs/sdk/web/admin/overview.mdx
@@ -3,8 +3,6 @@ title: Overview
 order: 1
 ---
 
-# Overview
-
 `@raystack/frontier/admin` is a React component library that provides pre-built admin views for managing Frontier resources such as users, organizations, plans, webhooks, and more. Each view handles data fetching, pagination, and rendering internally using [ConnectRPC](https://connectrpc.com/) and [`@raystack/apsara`](https://github.com/raystack/apsara) UI components.
 
 ## Installation

diff --git a/docs/content/docs/sdk/web/admin/utilities.mdx b/docs/content/docs/sdk/web/admin/utilities.mdx
@@ -3,8 +3,6 @@ title: Utilities
 order: 3
 ---
 
-# Utilities
-
 The SDK exports utility functions for working with ConnectRPC pagination and query transformation.
 
 ```tsx

diff --git a/docs/content/docs/tenants/managing-resource.mdx b/docs/content/docs/tenants/managing-resource.mdx
@@ -3,8 +3,6 @@ title: Manage Resources
 order: 3
 ---
 
-# Manage Resources
-
 A resource is a logical entity that represents any user-defined entity in the system. A resource always belongs to
 a `project` and is identified by a unique identifier called `urn` or via it's `id`. For example, in a system that
 manages databases, a resource can be a database instance. For a database instance, it's namespace can be `db/instance`

diff --git a/docs/content/docs/tenants/org.mdx b/docs/content/docs/tenants/org.mdx
@@ -3,8 +3,6 @@ title: Organization
 order: 1
 ---
 
-# Organization
-
 ## Overview
 
 An Organization in Frontier is a top-level resource. Each Project, Group, User, and Audit logs (coming soon) belongs to an Organization. There can be multiple tenants in each Frontier deployement and an Organization will usually represent one of your tenant.

diff --git a/docs/content/docs/tenants/project.mdx b/docs/content/docs/tenants/project.mdx
@@ -3,8 +3,6 @@ title: Project
 order: 2
 ---
 
-# Project
-
 Projects in Frontier are sub-resources within an organization. They allow for logical grouping of resources and users (including groups and service users). Each project can have its own set of permissions and access controls, enabling fine-grained control over resource allocation and user management.A single organization can contain multiple projects.
 
 Principals(user, groups, service users) can be assigned a pre-defined or a custom role at the project level if multiple resources in a project are to share the same role for a user. A Frontier policy can be created for that Project namespace for enabling user to have same role for all the underlying resources. Say a user A has `app_project_viewer` role for both the applications say X and Y in a project.

diff --git a/docs/content/docs/tour/creating-user.mdx b/docs/content/docs/tour/creating-user.mdx
@@ -3,8 +3,6 @@ title: Authenticating user via the external IDP
 order: 2
 ---
 
-# Authenticating user via the external IDP
-
 ## Pre-requisites
 
 - [Set-up an external identity provider for authentication](./setup-idp-oidc.md)
-Original file line number
+Diff line change
@@ Expand Up / @@ -3,8 +3,6 @@ title: Session Management @@
     order: 3
     ---
-    # Session Management
     Sessions are created automatically when a user successfully authenticates with Frontier. They allow the system to remember that a user is authenticated without requiring them to authenticate again for every request. Sessions are stored as encrypted cookies in the user's browser and are managed entirely by the Frontier SDK.
     :::note
@@ Expand Down @@