Loading...
; } /* do something with the data... */ return ({JSON.stringify(posts)}
Loading...
; } /* do something with the data... */ return ({JSON.stringify(posts)}
Loading...
; } /* do something with the session data... */ return{session.data?.user?.email}
; }; ``` That's how you can access user details right in your extension. ## Signing out Signing out from the extension also involves using the well-known `signOut` function that is derived from our [auth client](https://www.better-auth.com/docs/basic-usage#signout): ```tsx title="logout.tsx" import { authClient } from "~/lib/auth"; export const Logout = () => { return ; }; ``` The session is automatically invalidated, so the next use of `useSession` or any other query that depends on the session will return `null`. The UI for both the extension and the web app will be updated to show the user as logged out.Loading...
; } const plan = getActivePlan(summary.data); return{plan}
; } ``` You may also want to ensure that user is logged in before fetching their billing data to avoid unnecessary API calls. ```tsx title="header.tsx" import { api } from "~/lib/api"; import { authClient } from "~/lib/auth"; export const User = () => { const session = authClient.useSession(); const summary = useQuery({ queryKey: ["me"], queryFn: handle(api.billing.me.$get), enabled: !!session.data?.user, // [!code highlight] }); if (!session.data?.user || !summary.data) { return null; } return ({session.data.user.email}
{summary.data.length}
My Component Content
Loading...
; } /* do something with the data... */ return{data?.message}
; }; ```Current plan: {plan}
; } ``` ### Client-side ```tsx title="billing-status.tsx" "use client"; import { useQuery } from "@tanstack/react-query"; import { handle } from "@workspace/api/utils"; import { getActivePlan } from "@workspace/billing"; import { api } from "~/lib/api/client"; export function BillingStatus() { const summary = useQuery({ queryKey: ["me"], queryFn: handle(api.billing.me.$get), }); if (!summary.data) { return null; } const plan = getActivePlan(summary.data); returnCurrent plan: {plan}
; } ``` In summary, TurboStarter offers a flexible and unified billing framework, allowing you to mix and match billing models and providers as needed. Each section above provides focused documentation to help you configure the approach that best suits your SaaS application's needs. --- url: /docs/web/billing/per-seat title: Per-seat billing description: Charge your customers based on the number of seats they have. ---My Component Content
{activeOrganization?.name}
{activeMember?.role}
); } ``` Using the hook is recommended over direct API calls, as it will keep the state in sync with the server session. It also returns the active member of the active organization, so you can access the user's role and other member-specific data. ## API route To access the active organization data in an API route, you can read it from the session that is appended to the context when you use [authentication middleware](/docs/web/api/protected-routes). ```ts title="action/router.ts" export const actionRouter = new Hono().post("/", enforceAuth, async (c) => { const organizationId = c.var.user.activeOrganizationId; const organization = await getOrganization({ id: organizationId }); return c.json(organization); }); ``` Although it's the simplest way, we recommend directly passing the `organizationId` together with the payload when you need to perform an action. ```ts title="action/router.ts" export const actionRouter = new Hono().post( "/", enforceAuth, validate( "json", z.object({ organizationId: z.string(), /* rest of the payload */ }), ), async (c) => { const { organizationId, ...payload } = c.req.valid("json"); const organization = await getOrganization({ id: organizationId }); return c.json(await performAction(organization, payload)); }, ); ``` This ensures that the action is performed on the correct organization, even if the user has multiple organizations open in different tabs. See [Edge cases](#edge-cases) for more details. ## Edge cases * **Expected and harmless:** Short periods where the URL slug and server session differ can happen (for example, with multiple tabs or quick switching). The active tab always treats the slug as the source of truth and the session catches up. * **Multiple tabs:** Each tab maintains its own org context from its slug. As you switch focus, the shared session updates; brief divergence is normal and safe. * **Rapid switching/slow network:** During fast navigation or poor connectivity, you may momentarily see the previous org while the session updates. Show a small loading state; cancel in-flight requests tied to the old org. * **Missing/invalid slug:** If the slug is missing or invalid, we fall back to the session’s `activeOrganizationId` or redirect to a safe default. * **Access or permission changes:** If a user loses access to the org they’re viewing, the data is cleared from the session and the user is redirected to a valid organization or personal dashboard.