- {orgs.map((item) => (
- ))}
How do I choose the right Kinde billing pricing model for my SaaS customers?
Think about how your customers actually use your product and what they value most. If you're selling a tool where usage varies dramatically - like API calls or storage - go with usage-based pricing so customers only pay for what they consume. For products where value comes from access to features rather than consumption, subscription pricing makes more sense. Kinde lets you mix these models within a single plan, so you could have a $20 base subscription plus $0.10 per extra API call. Start simple with one model and add complexity as you grow - your customers will thank you for not overwhelming them upfront. [Explore pricing models](/billing/pricing/pricing-models/) | [About billing concepts](/billing/about-billing/billing-concepts-terms/)What's the difference between Kinde's metered and unmetered features in plans?
Metered features are the ones you can put a number on - monthly active users, API calls, storage gigabytes, support hours. These can be chargeable (customers pay per unit) or non-chargeable (included in their plan up to a limit). Unmetered features are more like switches - either customers have access to your advanced analytics dashboard or they don't. Think of metered features as "how much" and unmetered as "yes or no." Most SaaS businesses use a mix of both to create clear upgrade paths without making pricing too complicated. [About plans and features](/billing/manage-plans/about-plans/) | [Billing concepts guide](/billing/about-billing/billing-concepts-terms/)How do Kinde plan groups help me organize billing for different customer types?
Plan groups are how you separate B2B and B2C offerings without creating a mess. Each group is tied to either individual users or organizations, never both. So you might have a "Professional" group with individual plans for freelancers and consultants, and a separate "Enterprise" group with team-based pricing for companies. You can create multiple pricing tables from one group, but each table can only show plans from a single group. This keeps your offerings clean and makes it easier for customers to find the right fit. [Plan groups management](/billing/manage-plans/about-plans/) | [Billing concepts](/billing/about-billing/billing-concepts-terms/)Why should I use Kinde's billing features instead of building my own payment system?
Unless you're excited about spending months building subscription management, dunning logic, proration calculations, and tax compliance - spoiler alert: you're probably not - Kinde's billing saves you from that headache. We handle the messy bits like Stripe integration, plan upgrades, usage tracking, and invoice generation, so you can focus on building features your customers actually care about. Plus, you get a self-serve portal out of the box, which means fewer support tickets about billing issues. [About billing plans](/billing/manage-plans/about-plans/) | [Self-serve portal setup](/build/self-service-portal/self-serve-portal-for-orgs/)How does Kinde handle the technical complexity of subscription billing?
We abstract away the most technical parts. Once you connect to Stripe (we create a new account for you automatically), everything syncs seamlessly. Plan changes, usage tracking, proration, invoice generation - it all happens behind the scenes. Your customers get a smooth experience upgrading or downgrading, and you can set up webhook notifications when important billing events happen. The only thing you need to worry about is building great features and deciding how to price them. [Stripe integration guide](/billing/get-started/connect-to-stripe/) | [About billing plans](/billing/manage-plans/about-plans/)What happens when I publish a plan versus keeping it in draft, in Kinde?
Draft plans are your work in progress - you can tweak pricing, add features, change everything without affecting anyone. Once you publish a plan, it syncs to Stripe and becomes available for actual customers to subscribe to. Here's the catch: once someone subscribes to a published plan, you can't change it anymore, only version it (though plan versioning isn't available yet). This protects your existing customers from surprise pricing changes, but it means you need to think things through before hitting publish. [About plans lifecycle](/billing/manage-plans/about-plans/) | [Billing concepts](/billing/about-billing/billing-concepts-terms/)Why does Kinde create a new Stripe account instead of connecting to my existing one?
This is actually a Stripe requirement for third-party integrations like ours, not something we chose. They want to ensure security and compliance by controlling how connected accounts are set up. The good news? You can transfer your existing business information during the Stripe onboarding process, so you're not starting from scratch. We're working on a migration strategy to make this smoother, but for now, the new account approach keeps everyone secure and compliant. [Stripe connection setup](/billing/get-started/connect-to-stripe/) | [Manage Stripe connection](/billing/payment-management/manage-stripe-connection/)What should I tell customers when my Kinde–Stripe connection shows "In progress" status?
Don't worry - this just means Stripe needs a bit more information from you to complete the setup. Usually it's business details like contact information, tax info, or identity verification (they might ask for ID upload). The connection won't work for live payments until this is sorted, so customers won't be able to subscribe to paid plans yet. Jump into your Stripe dashboard through the "Update Stripe information" button in Kinde to see what's missing. Once everything's complete, the status should change to "Connected" and you're good to go. [Stripe connection troubleshooting](/billing/payment-management/manage-stripe-connection/) | [Connect to Stripe guide](/billing/get-started/connect-to-stripe/)How do I test Kinde billing without charging real money?
Switch to your non-production environment in Kinde - this automatically creates a test Stripe account that won't process real payments. You can create plans, test the whole customer journey, even simulate failed payments, all without touching real credit cards. This is perfect for making sure your billing flow works before going live. Just remember to switch back to your production environment when you're ready to accept real payments. [Stripe integration setup](/billing/get-started/connect-to-stripe/) | [About billing plans](/billing/manage-plans/about-plans/)How should I structure Kinde billing plans to make upgrading feel natural for customers?
Create a clear progression where each plan builds on the previous one. Start with a generous free plan that gives users real value, then add features and remove limits as they upgrade. Instead of completely different feature sets, use metered features to give everyone a "taste" - maybe 100 API calls on Free, 1,000 on Pro, unlimited on Enterprise. This way upgrades feel like growth, not switching to something completely different. Keep plan names simple and descriptive - "Starter," "Professional," "Enterprise" beats "Bronze," "Silver," "Gold" every time. [About pricing models](/billing/pricing/pricing-models/) | [Plan management guide](/billing/manage-plans/about-plans/)What's the best way to handle Kinde plan features that some customers need but others don't?
This is where unmetered features shine. Instead of cramming every possible feature into every plan, gate advanced capabilities behind higher tiers. Use unmetered features as "gates" - advanced reporting might only be available on Business plans, while API access could be Professional and up. For features with variable usage, use metered features with different limits per plan. This way customers self-select into the right plan based on what they actually need, and you avoid feature bloat in your lower tiers. [Feature planning strategy](/billing/manage-plans/about-plans/) | [Billing concepts](/billing/about-billing/billing-concepts-terms/)How do I explain Kinde's tiered pricing to customers who are confused about usage charges?
Be upfront about how the math works and give concrete examples. If you charge $0.50 for the first 10 API calls, then $0.30 for calls 11-50, show them: "If you make 25 API calls, you pay $5 for the first 10, then $4.50 for the next 15 = $9.50 total." Most customers appreciate transparency over surprises. Consider setting reasonable limits on lower plans instead of unlimited usage-based charging - it makes budgeting easier for them and upgrade paths clearer for you. Mke sure your pricing table is descriptive and clear about metered or package prices. This can be tricky. [Pricing models explained](/billing/pricing/pricing-models/) | [Build a pricing table](/billing/billing-user-experience/plan-selection/)What should I consider when setting Kinde plan upgrade and downgrade policies?
Think about what's fair for both you and your customers. By default, Kinde forgives unpaid usage when customers downgrade and doesn't refund unused subscription days - this is pretty industry standard and avoids messy proration calculations. But you can change these policies if needed. For example, if someone on your $100/month plan cancels mid-month, you might choose not to refund the remaining days but also not charge them for any metered usage that month. Find the balance that feels fair and stick with it consistently. [Plan policies configuration](/billing/manage-plans/upgrade-downgrade-plans/) | [Billing setup guide](/billing/get-started/connect-to-stripe/)How do I create Kinde pricing tables that actually convert visitors into customers?
Less is more when it comes to pricing tables. Stick to your 3-4 core plans (Free, Pro, Business works great), highlight which plan is most popular, and focus on benefits rather than features. Use the custom features section to highlight your best selling points for each plan, and don't just copy your technical feature list. Test different approaches, but remember - confused customers don't buy anything. If your product is complex or has a lot of features, you might want to create a custom designed table. [Build effective pricing tables](/billing/billing-user-experience/plan-selection/) | [Pricing table customization](/billing/billing-user-experience/plan-selection/)Should I show Kinde pricing tables during the signup flow or after users experience my product?
Depends on your product and customer type. For simple tools where the value is obvious upfront, showing pricing during signup can work well - especially if you have a generous free tier. For complex products where users need to understand the value first, let them sign up and experience your product before presenting upgrade options. You can control this in Kinde by toggling the "Show pricing table when customers sign up" option. Test both approaches if you're unsure - the data will tell you what works for your audience. [Pricing table display options](/billing/billing-user-experience/pricing-table-display/) | [Billing integration guide](/billing/billing-user-experience/plan-selection/)How do I handle customers who need custom pricing that doesn't fit Kinde's standard plans?
Start by trying to fit them into your existing plans with some creative metered feature limits - you'd be surprised how often this works. If they truly need something custom, you can manually adjust metered usage for specific customers through the Kinde API after they subscribe. For true enterprise deals with annual contracts or bank transfers, those arrangements are available but you'll need to work with Kinde's enterprise team. Most customers who think they need custom pricing actually just need a slightly modified version of your top tier. [API billing management](/billing/manage-plans/about-plans/) | [Enterprise billing options](/manage-your-account/profile-and-plan/change-kinde-plan/)How does Kinde's self-serve portal reduce my customer support workload?
Think of it as your billing support team that never sleeps. Customers can update their payment details, view billing history, upgrade plans, and manage organization settings without creating support tickets. You control exactly what they can self-manage - maybe you want them handling payment updates but prefer to manage plan changes yourself. The portal generates one-time secure links, so you can add "Manage Billing" buttons throughout your app that take users directly to the right section. Less support tickets means more time building features that matter. [Self-serve portal setup](/build/self-service-portal/self-serve-portal-for-orgs/) | [Portal configuration options](/build/self-service-portal/self-serve-portal-for-orgs/)What permissions should I give organization members via Kinde's self-serve portal feature?
It's better to start with more restrictions and expand, than start with too many that you might have to remove. Most organizations want their admins to manage payment details and view billing history, but you might not want every team member changing subscription plans. Kinde provides some pre-defined roles with varying portal access - so that the right people can change the right things. The permissions map directly to Kinde's system permissions like `org:write:billing`, so you can be granular about who can do what. [Portal permissions setup](/build/self-service-portal/self-serve-portal-for-orgs/).How do I generate Kinde self-serve portal links for use in my app?
You've got two options depending on your setup. If you're using Kinde for authentication, use the SDK to generate portal links on the fly - perfect for "Account Settings" buttons in your app. If you're handling auth yourself or need server-side generation, hit the Kinde Management API with an M2M token. You can specify which section of the portal to open (billing, profile, etc.) and where to redirect users when they're done. The links are one-time use for security, so generate them fresh each time. [Portal link generation](/build/self-service-portal/self-serve-portal-for-orgs/) | [Management API integration](/build/self-service-portal/self-serve-portal-for-orgs/)How do I sync Kinde billing data with my application's feature access controls?
Use the Account API to check what features and usage limits a signed-in user has access to. The API returns billing entitlements along with roles and permissions, so you can gate features based on their current plan. For organization-level billing data (which is more sensitive), use the Management API instead. Set up webhooks for billing events like plan changes or usage updates, so your app stays in sync automatically. Don't try to cache billing data for too long - things change, and you want accurate limits. [Account API for billing](/developer-tools/account-api/about-account-api/) | [Billing webhooks](/integrate/webhooks/about-webhooks/)How should I handle Kinde billing webhook events in my application?
Set up dedicated API endpoints to receive billing webhooks and verify the JWT signatures - this is how you know the requests actually come from Kinde. Handle key events like subscription changes, payment failures, and usage updates to keep your app in sync. Always respond with a 200 status code when you successfully process a webhook, or Kinde will keep retrying with backoff logic. Use the webhook request ID as an idempotency key to avoid processing the same event twice if there are retries. [Webhook implementation](/integrate/webhooks/about-webhooks/) | [Webhook setup guide](/integrate/webhooks/add-manage-webhooks/)How do I implement Kinde billing URLs and parameters for seamless user experiences?
Use URL parameters to direct customers to specific plans or pricing tables when they're ready to upgrade. For example, `?plan=pro_monthly` can take them straight to your Pro plan signup. This is super useful for email campaigns, in-app upgrade prompts, or landing pages. You can also override which pricing table displays using parameters, so different marketing campaigns can show different plan combinations. The SDK handles most of this automatically, but manual URL construction gives you more control. [Billing URL integration](/billing/billing-user-experience/plan-selection/) | [Pricing table configuration](/billing/billing-user-experience/plan-selection/)Why aren't the plan prices I set up in Kinde syncing with Stripe?
If you see "price not synced" status, it usually means the plan isn't published yet - only published plans sync to Stripe. Mixed sync status (some features synced, others not) typically happens when some features are already in a published plan while others are new additions. Try publishing or re-publishing the plan to trigger a sync. If it's still not working, check that your Stripe connection status shows "Connected" rather than "In progress" or "Connecting." [Plan publishing process](/billing/manage-plans/about-plans/) | [Stripe connection status](/billing/payment-management/manage-stripe-connection/)What should I do when customers report billing discrepancies?
Start by checking the billing history in their organization's portal - this shows exactly what they were charged and when. Look for things like mid-month plan changes (which can cause proration), metered usage overages, or failed payment retries. Most "billing errors" are actually just confusing timing - customers might see charges for last month's usage appearing on this month's invoice. If you genuinely find an error, Kinde's support team can help resolve it, but having the billing details handy speeds things up. [Billing history access](/manage-your-account/profile-and-plan/view-kinde-plan/) | [Support resources](/build/self-service-portal/self-serve-portal-for-orgs/)What are some of Kinde's billing limitations and when might these be fixed?
Currently, Kinde only supports monthly billing (no annual), doesn't have free trial periods built-in, and plan versioning isn't ready yet. For customers who need annual billing, you could manually create annual plans with different pricing. For free trials, you could start them on a free plan and set up automated emails to encourage upgrades. Give us feedback about your billing experience with Kinde by reporting bugs and making feature suggestions. We genuinely are listening. [Current billing limitations](/billing/manage-plans/about-plans/) | [Alternative approaches](/billing/pricing/pricing-models/)What's the smartest way to launch Kinde billing for an existing SaaS product with users?
Start by setting up your billing plans and pricing tables in a non-production environment to get everything perfect. Create a grandfathering strategy for existing users - maybe they keep their current access levels for a certain period before needing to choose a plan. When you're ready to go live, communicate the changes clearly with plenty of notice. Consider starting with just new signups on the new billing system, then migrating existing users in batches. This gives you time to iron out any issues without affecting your entire user base at once. [Billing setup strategy](/billing/get-started/connect-to-stripe/) | [Plan management](/billing/manage-plans/about-plans/)How should I price Kinde metered features to encourage growth while staying profitable?
Pricing decisions can be really hard. Start with generous free tiers that let customers experience real value, then use usage limits to create natural upgrade triggers. If your app gets more valuable with heavier usage, price metered features aggressively low or even free up to reasonable limits. The goal is to make customers successful enough that upgrading feels like a no-brainer rather than a burden. Watch your unit economics closely - some features cost you more to provide than others, so price accordingly. [Metered pricing strategies](/billing/pricing/pricing-models/) | [Feature management](/billing/manage-plans/about-plans/)What's the most effective way to use Kinde billing data to reduce customer churn?
Set up webhooks for payment failures and usage pattern changes, then create automated workflows to reach out before customers hit walls. If someone's approaching their usage limits, send them upgrade prompts with specific benefits rather than just warnings. Use billing data to identify your best customers (high usage, consistent payments) and make sure they're getting white-glove treatment. Failed payments aren't always churn signals - sometimes cards expire or customers need payment method updates. [Billing webhooks setup](/integrate/webhooks/about-webhooks/) | [Usage tracking](/billing/manage-plans/about-plans/)How do I structure Kinde plans to minimize customer confusion while maximizing revenue?
Keep it simple with clear value differences between tiers. Three to four plans usually hit the sweet spot - more than that and customers get paralyzed by choice. Use the "good, better, best" psychology: make your middle plan the obvious choice by giving it the best value ratio. Include some metered features as "freebies" in higher plans to justify the price jump. And please, test your pricing table with real humans before launching - what seems obvious to you might be confusing to customers who see it fresh. [Pricing table best practices](/billing/billing-user-experience/plan-selection/) | [Plan strategy guide](/billing/pricing/pricing-models/){content.heading}
{content.description}
``` + +# Design - Content customization - Update page content + +> Guide for updating authentication page content including multi-language support, text variables, and escape route URL configuration for error handling. + +page content, content customization, text variables, multi-language, auth pages, escape route URL, preview +design, content-customization, multi-language + +For maximum extensibility, page content has been decoupled from the page itself. This lets you update the copy on most screens, which you can do via the **Page content** section of the admin area (see below) or via API (coming soon). ### Update page content If your application is built for [multiple languages](https://docs.kinde.com/design/pages/set-language-for-pages/), select these first in Kinde. 1. In Kinde, go to **Design > Page content**. 2. Select the language you want (only applicable if multiple languages are configured). 3. Select the page you want to edit. The list of content shown corresponds with page elements such as headings, field labels, helper text, error messages, etc. 4. Make the changes to the content. If you want, you can use text variables, explained below. 5. When you’ve finished, select **Save**. The save only applies to the current language and page selected. You need to select **Save** again if you edit in different languages. 6. Check changes by selecting **Preview**. You'll only see an accurate preview if the environment is fully connected, otherwise you may see errors. 7. Repeat from step 2 for each language and page you want to edit. ### Text variables for page content Variables are used to stand in for actual values that you want to appear on pages. They are a way of automating content. For example, if you use the `${email_address}` variable, the user’s email address will be shown. Variables can be used on pages as follows. **Sign in confirm code page** `${email_address}` - shows the full email address of the user `${email_address_obfuscated}` - shows only a part of the user's email **Sign up confirm code page** `${email_address}` ### Include ‘escape route’ URL in auth errors When auth errors appear, you want to give users a way to navigate out of them. To provide an ‘escape route’ URL in these situations: 1. In Kinde, go to **Settings > Applications** and select **View details** on your application. 2. Enter your website URL into the **Application homepage URI** and **Application login URI** fields. 3. Select **Save**. + +# Design - Customize with code - Connect your repo for custom pages + +> Guide for connecting GitHub repositories for custom page design including directory structure setup, code preview options, and status monitoring. + +connect repo, custom pages, GitHub, custom domain, code preview, directory structure, code status +design, customize-with-code, git + +To enable your custom code to override Kinde page design, you need to set up and connect a git repo for the design files. You must also be using a [custom domain](/build/domains/pointing-your-domain/) to run your custom code with Kinde. ## Connect your repo 1. Go to **Design > Custom code**. 2. Select the option to **Connect repo**. This will take you to the **Settings > Git Repo** page where you can manage your repo connection for design and workflows. 3. If you don’t already have a repo set up for workflows, select **Connect GitHub**. 4. Follow the prompts to connect a repo and branch. ## Option to enable code preview If you are on the Kinde Plus or Scale plan, you can enable a code preview before you deploy new code to be live. This is helpful for checking the design before making it public in your production environment. If you have a free or Pro plan, we recommend you preview designs in a non-production environment before syncing in production. ## Set up the Git directory structure Your directory structure should follow the following structure. ```jsx myApp/ ├── kindeSrc/ │ └── environment/ │ └── pages/ │ └── (kinde)/ │ └── {/* Content for the Next.js App */}
) : clientId == CLIENT_ID_PYTHON_APP? ( Styling for the First App - Next.js
Client ID: {clientId}
{getKindeWidget()}
{/* Content for the Python App */}
) : ( Styling for the Second App - Python
Client ID: {clientId}
| Company | Contact | Country |
|---|---|---|
| Alfreds Futterkiste | Maria Anders | Germany |
{getKindeWidget()}
{/* Fallback content for any other app (e.g., Nuxt app) */}
)} Default Kinde Authentication Page
Client ID: {clientId || 'Not available'}
{getKindeWidget()}
{heading}
{description}
{getKindeWidget()} // our footer won't change so exclude from re-rendering ``` This means that only critical page items are being re-rendered. + +# Design - Customize with code - Pages and the Kinde Management API + +> Guide for integrating Kinde Management API with custom pages including M2M setup, environment variables, and common API calls for B2B applications. + +Kinde Management API, M2M application, API calls, server rendering, environment variables, organization API, bindings +design, customize-with-code, api + +Pages are rendered on the server which means it is possible to make API calls before the page is delivered to the browser. The most common use case for this is calling the Kinde Management API to get additional information for the page. ## Before using the Kinde Mangement API for pages 1. [Create an M2M application](/developer-tools/kinde-api/connect-to-kinde-api/) within Kinde and grant it access to the Kinde Management API with the desired scopes. 2. Setup environment variables in Kinde to provide the client ID and secret. By default the `createKindeAPI` method initially looks up the following environment variables setup in Kinde settings to determine the application to use. - `KINDE_WF_M2M_CLIENT_ID` - `KINDE_WF_M2M_CLIENT_SECRET` - Ensure this is setup with sensitive flag enabled to prevent accidental sharing `createKindeAPI` can also accept an additional parameter which can contain `clientID/clientSecret` or `clientIDKey/clientSecretKey` which can define the environment variables to look up. ## Calling the Kinde Management API for pages The example below calls the `environment` API and adds the logo to the page. **Required bindings** ```js export const pageSettings = { bindings: { "kinde.env": {}, "kinde.fetch": {}, url: {} } }; ``` Example usage calling Organization API: ```jsx export default async Page(event: onPageRequestEvent) { const orgCode = event.request.authUrlParams.orgCode; const kindeAPI = await createKindeAPI(event); const { data: res } = await kindeAPI.get({ endpoint: `organization?code=${orgCode}`, }); const {org} = res; return `{org.name}
`; } ``` ## Common API calls for custom page design - `GET /environment` - includes brand settings for the environment including logos / background images. Required M2M scope: `read:environments` - `GET /organizations?org_code=${request.authUrlParams.orgCode}` brand settings for the requested org including logo. Required M2M scope: `read:organizations` - `GET /business` - business details like the business name. Required M2M scope: `read:businesses` - `GET /applications/${request.authUrlParams.clientId}`. Required M2M scope: `read:applications` + +# Design - Customize with code - Libraries and packages for pages + +> Guide for using npm packages and libraries in Kinde page designs including supported packages, React templates, and development dependencies. + +npm packages, libraries, React, Liquid, dev dependencies, runtime environment +design, customize-with-code, packages + +As part of bringing your own code to page designs, you'll likely need to work with some `npm` libraries in addition to the `@kinde/infrastructure` package. Kinde supports a handful of carefully selected libraries from `npm`. These include: `@kinde/infrastructure` This is Kinde’s package that supplies helpers and methods to give you the best possible authoring experience of Kinde pages and workflows. For server side React templates: `react` and `react-dom/server.browser` For Liquid templates: `liquidjs` Attempting to import unsupported packages into your runtime code will result in your deployment failing. Dev dependencies (e.g packages used for linting, tests and build steps) can be used, as they do not affect the Kinde runtime environment. Any code dependent on these packages should be prebuilt before deploying to Kinde. + +# Design - Customize with code - Preview custom code + +> Guide for previewing custom code designs using preview credentials and auth flow testing for Plus and Scale plan users. + +preview custom code, pages_mode, preview password, Plus plan, Scale plan, auth flow +design, customize-with-code, preview + + Unlike changes you make in the Kinde UI that impact page layouts and content, your custom designs can’t be viewed in a Kinde-generated preview. Instead, you can test designs using your real auth flow, using preview credentials. ## Preview custom code 1. In your application code, pass the additional auth url parameter `pages_mode=preview`. When the auth flow is initiated a password screen will appear which is required to view the preview. 2. Enter your preview password. Go to **Design > Custom code > Preview**. 3. Copy the **Password** and use it in the authentication request. The preview will show the latest code deployment version. + +# Design - Customize with code - Quick start guide + +> Quickly set up and run your first Kinde workflow in minutes. + +quick start, custom UI, GitHub template, React Server Components, custom domain, workflow setup +design, customize-with-code, quick-start + +The quickest way to see an end-to-end example of custom HTML/CSS and JS running on Kinde hosted pages is to follow this guide. ## What you need - A Kinde account with an application set up on a [custom domain](/build/domains/pointing-your-domain/). - A GitHub account to host your code. ## Step 1: Clone a Kinde example template 1. Sign in to your GitHub account and go to [Kinde example Splitscape Custom UI template](https://github.com/kinde-starter-kits/custom-ui-splitscape). 2. Select the green **Use this template button**. 3. Select **Create a new repository**. This will create a new repository in your GitHub account with a copy of the example code. It contains a a fully customizable UI starter template built with React Server Components. ## Step 2: Connect your GitHub repository to Kinde 1. Sign in to your Kinde account and go to **Settings > Git repo**. 2. Select **Connect GitHub** and follow the instructions to connect your GitHub account to Kinde. When you select the repository you just created, Kinde will automatically sync the code for you. ## You're done! Assuming you have an application set up, you can see your custom UI by navigating to your sign in screen. You can now modify the custom UI code to look however you like. ## Next steps - Explore the [Kinde custom UI documentation](/design/customize-with-code/customize-with-css-html/) to learn more about how custom UI works. - Take a look at some other example templates + +# Design - Customize with code - Style with style hooks + +> Comprehensive guide for styling Kinde widgets using style hooks including CSS selectors, theme support, dark mode, and HTML data attributes for custom styling. + +style hooks, CSS styling, data attributes, widget styling, dark mode, theme styles, HTML selectors +design, customize-with-code, styling + +Style hooks are [HTML data attributes](https://developer.mozilla.org/en-US/docs/Learn_web_development/Howto/Solve_HTML_problems/Use_data_attributes) that can be targeted using the [CSS attribute selector](https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors), allowing you to apply styles directly to the Kinde widget in your custom CSS. They give you full control over styling widget components and layouts. Unlike CSS classes, which are used internally, style hooks are dedicated to external (custom) styling. This separation ensures your custom styles remain stable, even if internal styles change. Style hooks are useful when a setting doesn’t exist for a specific style, such as adding a shadow effect to the **Button** component. For example: ```css [data-kinde-button] { box-shadow: 0 1px 3px rgba(12, 12, 12, 0.09); } ``` ## Define style hooks in your CSS Style hooks allow you to apply styles directly in your custom CSS. For example, add a shadow effect to the **Button** component when hovered: ```css [data-kinde-button]:hover { box-shadow: 0 1px 3px rgba(12, 12, 12, 0.09); } ``` ## Available style hooks Nearly all elements in the widget have a style hook applied, allowing you to style it as needed. The best way to see which hooks are available is by using [DevTools](/design/customize-with-code/inspect-design-devtools/). Here’s an example of a form field with its style hooks: ```html Email
``` And here’s the HTML showing only the style hooks: ```html