server/src/api/analytics/getOverviewBucketed.ts (1)

48-63: Consider refactoring the nested ternary to a lookup map.

The nested ternary operator reduces readability. Consider extracting this logic into a map similar to bucketIntervalMap for better maintainability.

Apply this refactor by adding a new map near the top of the function:

+const bucketToIntervalUnit: Record<TimeBucket, string> = {
+  minute: "MINUTE",
+  five_minutes: "MINUTE",
+  ten_minutes: "MINUTE",
+  fifteen_minutes: "MINUTE",
+  hour: "HOUR",
+  day: "DAY",
+  week: "WEEK",
+  month: "MONTH",
+};

Then replace the nested ternary:

     return ` WITH FILL 
       FROM ${TimeBucketToFn[validatedBucket]}(toDateTime(${SqlString.escape(startIso)}))
       TO ${TimeBucketToFn[validatedBucket]}(toDateTime(${SqlString.escape(endIso)})) + INTERVAL 1 ${
-        validatedBucket === "minute"
-          ? "MINUTE"
-          : validatedBucket === "five_minutes"
-            ? "MINUTE"
-            : validatedBucket === "ten_minutes"
-              ? "MINUTE"
-              : validatedBucket === "fifteen_minutes"
-                ? "MINUTE"
-                : validatedBucket === "month"
-                  ? "MONTH"
-                  : validatedBucket === "week"
-                    ? "WEEK"
-                    : validatedBucket === "day"
-                      ? "DAY"
-                      : "HOUR"
+        bucketToIntervalUnit[validatedBucket]
       }
       STEP INTERVAL ${bucketIntervalMap[validatedBucket]}`;

client/package.json (1)

79-79: New syntax-highlighter dependency looks appropriate; just confirm types & bundle impact.

The addition of react-syntax-highlighter and its type package matches the new CodeSnippet usage. Please just confirm that TypeScript builds cleanly with the @types/runtime version combo, and keep an eye on bundle size—if this grows, consider lazy-loading the highlighter only where the playground is rendered.

Also applies to: 96-96

client/src/app/[site]/api-playground/components/TimezoneSelect.tsx (1)

12-32: TimezoneSelect store wiring looks good; optional a11y enhancement.

State binding and timezone options mapping are solid. For better accessibility, consider giving the trigger an id and wiring the <label> via htmlFor or aria-labelledby so assistive tech can associate them explicitly.

client/src/app/[site]/api-playground/components/RequestBodyEditor.tsx (1)

3-41: JSON validation is solid; consider reordering imports to match guidelines.

The handleChange logic cleanly keeps the store and error state in sync, and the UX around empty vs invalid JSON is good. To align with the “external before internal imports” guideline, you could move the useState import above the @/components and relative imports, e.g.:

-import { Textarea } from "@/components/ui/textarea";
-import { usePlaygroundStore } from "../hooks/usePlaygroundStore";
-import { useState } from "react";
+import { useState } from "react";
+import { Textarea } from "@/components/ui/textarea";
+import { usePlaygroundStore } from "../hooks/usePlaygroundStore";

As per coding guidelines, external imports should be grouped before internal ones.

client/src/app/[site]/api-playground/components/EndpointList.tsx (1)

11-75: EndpointList selection logic is correct; you can tighten button semantics.

Endpoint grouping and selection based on { method, path } match the store shape and look good. To make the items more robust if this ever lives inside a <form>, you might set an explicit type="button" and expose the selection state to assistive tech:

-function EndpointItem({ endpoint, isSelected, onClick }: EndpointItemProps) {
+function EndpointItem({ endpoint, isSelected, onClick }: EndpointItemProps) {
   return (
-    <button
-      onClick={onClick}
+    <button
+      type="button"
+      aria-pressed={isSelected}
+      onClick={onClick}

client/src/app/[site]/api-playground/components/ApiPlayground.tsx (1)

7-25: ApiPlayground shell composes the layout well; watch fixed viewport height on small screens.

The three-column layout and dark-mode styling are clean and match the playground’s needs. If you see issues on very short viewports, you might later consider a more responsive height (e.g., using a CSS var for header height or letting the container grow with min-h-screen).

client/src/app/[site]/api-playground/components/CodeExamples.tsx (1)

12-41: CodeExamples wiring is correct; consider tightening selectedLang typing.

Using languageOrder and codeGenerators together is tidy, and the tabs + CodeSnippet integration look good. You can get stronger type-safety (and better editor help) by constraining selectedLang and the helper signature to the known language list:

-export function CodeExamples({ config }: CodeExamplesProps) {
-  const [selectedLang, setSelectedLang] = useState("cURL");
+export function CodeExamples({ config }: CodeExamplesProps) {
+  const [selectedLang, setSelectedLang] = useState<(typeof languageOrder)[number]>("cURL");
@@
-      <CodeSnippet
-        code={code}
-        language={getLanguageForHighlight(selectedLang)}
-      />
+      <CodeSnippet
+        code={code}
+        language={getLanguageForHighlight(selectedLang)}
+      />
@@
-function getLanguageForHighlight(lang: string): string {
+function getLanguageForHighlight(lang: (typeof languageOrder)[number]): string {

This ensures selectedLang always matches an entry in languageOrder and that getLanguageForHighlight can’t be called with an unsupported value.

Also applies to: 46-59

client/src/app/[site]/api-playground/components/FilterBuilder.tsx (1)

19-105: FilterBuilder integrates cleanly with the store; consider more stable row keys if filters evolve.

The add/update/remove wiring and use of filterParameters/filterOperators are consistent with the store and should behave well. If you later add per-row local state or reordering, you may want to move away from key={index} to a stable identifier (e.g., an id added when creating filters) to avoid React reusing DOM nodes across different logical filters; for now it’s fine given fully controlled inputs.

client/src/components/CodeSnippet.tsx (2)

11-17: Interface extends HTMLPreElement but component renders a div.

The CodeSnippetProps interface extends React.HTMLAttributes<HTMLPreElement>, but the component now renders a <div> container instead of a <pre>. This mismatch could cause type confusion when passing HTML attributes.

-interface CodeSnippetProps extends React.HTMLAttributes<HTMLPreElement> {
+interface CodeSnippetProps extends React.HTMLAttributes<HTMLDivElement> {
   code: string;
   language?: string;
   showLanguageLabel?: boolean;
 }

---

20-24: Consider adding error handling for clipboard API.

The navigator.clipboard.writeText() call can fail (e.g., in non-secure contexts or if permission is denied). Currently, errors would be silently swallowed.

 const copyToClipboard = React.useCallback(async () => {
-  await navigator.clipboard.writeText(code);
-  setHasCopied(true);
-  setTimeout(() => setHasCopied(false), 2000);
+  try {
+    await navigator.clipboard.writeText(code);
+    setHasCopied(true);
+    setTimeout(() => setHasCopied(false), 2000);
+  } catch (err) {
+    console.error("Failed to copy to clipboard:", err);
+  }
 }, [code]);

client/src/app/[site]/api-playground/components/ParameterControls.tsx (1)

62-72: Consider associating labels with inputs using htmlFor and id.

The labels wrap their inputs which provides implicit association, but using explicit htmlFor and id attributes is more robust for accessibility, especially for screen readers.

-              <div key={param} className="space-y-1">
-                <label className="text-sm font-medium text-neutral-700 dark:text-neutral-300">
+              <div key={param} className="space-y-1">
+                <label
+                  htmlFor={`path-param-${param}`}
+                  className="text-sm font-medium text-neutral-700 dark:text-neutral-300"
+                >
                   {meta?.label || param}
                 </label>
                 <Input
+                  id={`path-param-${param}`}
                   value={pathParams[param] || ""}

client/src/app/[site]/api-playground/utils/endpointConfig.ts (2)

13-13: Consider using a stricter type for requestBodyExample.

Using object is permissive. A Record<string, unknown> provides slightly better type safety and is more explicit about the expected structure.

   hasRequestBody?: boolean;
-  requestBodyExample?: object;
+  requestBodyExample?: Record<string, unknown>;
 }

---

413-417: The mode parameter metadata mixes unrelated enum values.

The options ["day", "week", "reached", "dropped"] combine retention modes (day, week) with funnel step modes (reached, dropped). This could cause confusion in the UI when different endpoints expect different subsets of these values.

Consider splitting into separate metadata entries:

-  mode: {
-    label: "Mode",
-    type: "select",
-    options: ["day", "week", "reached", "dropped"],
-  },
+  mode: {
+    label: "Mode",
+    type: "select",
+    options: ["reached", "dropped"],
+  },
+  retention_mode: {
+    label: "Mode",
+    type: "select",
+    options: ["day", "week"],
+  },

Then update the retention endpoint to use retention_mode instead of mode, or alternatively handle this at the endpoint level with per-endpoint option overrides.

client/src/app/[site]/api-playground/components/ResponsePanel.tsx (2)

96-106: getApiFilters in dependency array may cause unnecessary recalculations.

getApiFilters is a function from the Zustand store. While Zustand functions are typically stable, including a function in the dependency array is unconventional. If filters state changes, the memoized value should recalculate—consider depending on filters directly instead.

   const {
     // ... other values
+    filters,
     getApiFilters,
     // ...
   } = usePlaygroundStore();

   // In useMemo
-  }, [
-    // ...
-    getApiFilters,
-    // ...
-  ]);
+  }, [
+    // ...
+    filters,
+    // ...
+  ]);

Then call getApiFilters() inside the memo without listing it as a dependency.

---

198-203: Add error handling for clipboard API.

Similar to CodeSnippet, the clipboard write can fail. Consider wrapping in try-catch.

 const handleCopyUrl = () => {
-  navigator.clipboard.writeText(fullUrl);
-  setCopied(true);
-  setTimeout(() => setCopied(false), 2000);
+  navigator.clipboard.writeText(fullUrl).then(() => {
+    setCopied(true);
+    setTimeout(() => setCopied(false), 2000);
+  }).catch((err) => {
+    console.error("Failed to copy URL:", err);
+  });
 };

client/src/api/analytics/standalone/misc.ts (1)

11-20: Consider documenting the parameter interfaces.

Adding JSDoc comments to RetentionParams and JourneysParams would improve the developer experience when using these standalone API functions.

+/**
+ * Parameters for retention cohort analysis
+ */
 export interface RetentionParams {
+  /** Cohort grouping mode - "day" or "week" */
   mode?: RetentionMode;
+  /** Number of days to analyze (default: 90) */
   range?: number;
 }

+/**
+ * Parameters for user journey path analysis
+ */
 export interface JourneysParams extends CommonApiParams {
+  /** Number of steps in the journey (default: 3) */
   steps?: number;
+  /** Maximum number of journeys to return (default: 100) */
   limit?: number;
+  /** Filters to apply at specific journey steps */
   stepFilters?: Record<number, string>;
 }

client/src/app/[site]/api-playground/hooks/usePlaygroundStore.ts (1)

117-126: Consider more precise typing for filter values.

The value field in PlaygroundFilter is always a string (line 9), but line 124 casts [f.value] to (string | number)[]. While this works, a more precise type would be [string] since UI filters are string-based.

This is a minor type precision improvement:

       .map((f) => ({
         parameter: f.parameter as Filter["parameter"],
         type: f.operator as Filter["type"],
-        value: [f.value] as (string | number)[],
+        value: [f.value],
       }));

client/src/api/analytics/standalone/performance.ts (1)

35-98: Fetcher implementations align with existing standalone API pattern

All three fetchers build on toQueryParams, add only the endpoint‑specific fields, and unwrap the { data: ... } envelope from authedFetch, which is consistent with other analytics modules. If you start seeing ?param= noise in the backend logs, you could optionally strip undefined optionals before passing queryParams, but it’s not required for correctness.

client/src/app/[site]/api-playground/utils/codeGenerators.ts (1)

3-9: Overall codegen structure is solid and easy to extend

The shared CodeGenConfig, small helpers, and codeGenerators/languageOrder registry make it straightforward to add more languages or tweak existing ones. Once the language‑specific edge cases above are fixed, this should be a very ergonomic backbone for the playground’s code examples.

Also applies to: 304-327

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:24.979Z
Learning: Applies to client/**/*.{ts,tsx} : Client: React functional components with minimal useEffect and inline functions

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/src/app/(home)/tools/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:59.895Z
Learning: Applies to docs/src/app/(home)/tools/**/tools/**/*.tsx : Use `useState<string | null>(null)` for error state and display error in `bg-red-50` container when present

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:42.365Z
Learning: Applies to docs/app/(home)/tools/**/*.{ts,tsx} : Place tool components and API routes in `app/(home)/tools/` directory for analytics and SEO tools

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:42.365Z
Learning: Applies to docs/**/*.{ts,tsx} : Use React 19 functional components with hooks

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:42.365Z
Learning: Applies to docs/src/mdx-components.tsx : Define MDX components in `src/mdx-components.tsx` for rendering custom markdown elements

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:42.365Z
Learning: Applies to docs/app/**/*.{ts,tsx} : Use route groups with App Router for organizing marketing, documentation, and blog pages

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/src/app/(home)/tools/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:59.895Z
Learning: Applies to docs/src/app/(home)/tools/**/tools/*/[slug]/page.tsx : For multi-platform tools with identical logic but different branding, use dynamic route pattern `[slug]/page.tsx` with `generateStaticParams()` to minimize code duplication

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/src/app/(home)/tools/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:59.895Z
Learning: Applies to docs/src/app/(home)/tools/**/tools/**/[slug]/page.tsx : Use `await params` to extract dynamic route parameters in Next.js 15+ (required for Server Components)

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/src/app/(home)/tools/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:59.895Z
Learning: Applies to docs/src/app/(home)/tools/**/tools/**/[slug]/page.tsx : Use `notFound()` from Next.js when a requested platform configuration is not found

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/src/app/(home)/tools/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:59.895Z
Learning: Applies to docs/src/app/(home)/tools/**/tools/**/page.tsx : Tool client components should be named as `YourToolForm.tsx` and placed in the same directory as `page.tsx`

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:24.979Z
Learning: Frontend: Use Next.js with Turbopack, Tailwind CSS, Shadcn UI, Tanstack Query, Zustand, Luxon, Nivo, and react-hook-form

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:42.365Z
Learning: Applies to docs/app/layout.config.tsx : Define shared navigation and links in `app/layout.config.tsx` for Fumadocs

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/src/app/(home)/tools/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:59.895Z
Learning: Applies to docs/src/app/(home)/tools/**/tools/**/*.tsx : Use `navigator.clipboard.writeText()` for copy functionality in tools

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:42.365Z
Learning: Applies to docs/src/lib/trackAdEvent.ts : Track analytics events via `src/lib/trackAdEvent.ts` for monitoring tool usage and analytics

client/src/components/CodeSnippet.tsx (2)

21-31: Consider adding TypeScript language support.

Given this is for an API playground, TypeScript code examples may be needed. If so, consider registering the TypeScript language as well.

 import json from "react-syntax-highlighter/dist/esm/languages/hljs/json";
+import typescript from "react-syntax-highlighter/dist/esm/languages/hljs/typescript";
 import { atomOneDark } from "react-syntax-highlighter/dist/esm/styles/hljs";

 SyntaxHighlighter.registerLanguage("json", json);
+SyntaxHighlighter.registerLanguage("typescript", typescript);

---

33-37: Interface extends HTMLPreElement but component renders a div wrapper.

The interface extends React.HTMLAttributes<HTMLPreElement>, but only className is destructured and applied to a <div>. The other HTML attributes aren't passed through, which could be misleading.

Consider either:

1. Changing to React.HTMLAttributes<HTMLDivElement> to match the actual root element
2. Passing the rest of the props to the wrapper div

-interface CodeSnippetProps extends React.HTMLAttributes<HTMLPreElement> {
+interface CodeSnippetProps extends React.HTMLAttributes<HTMLDivElement> {
   code: string;
   language?: string;
   showLanguageLabel?: boolean;
 }

And spread remaining props:

 export const CodeSnippet = React.memo(function CodeSnippet({
   code,
   language,
   showLanguageLabel = false,
-  className
+  className,
+  ...props
 }: CodeSnippetProps) {
   // ...
   return (
-    <div className={cn("relative", className)}>
+    <div className={cn("relative", className)} {...props}>

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:24.979Z
Learning: Applies to client/**/*.{ts,tsx} : Client: React functional components with minimal useEffect and inline functions

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/src/app/(home)/tools/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:59.895Z
Learning: Applies to docs/src/app/(home)/tools/**/tools/**/*.tsx : Use `navigator.clipboard.writeText()` for copy functionality in tools

client/src/api/analytics/standalone/funnels.ts (1)

69-163: Inconsistent response unwrapping pattern across functions.

As noted in a previous review, the response handling is inconsistent:

• fetchFunnels and analyzeFunnel return response.data
• fetchFunnelStepSessions, saveFunnel, deleteFunnel return response directly

This creates API surface inconsistency for consumers.

client/src/api/analytics/standalone/sessions.ts (1)

128-184: Inconsistent response unwrapping pattern continues here.

As flagged in a previous review:

• fetchSessions and fetchSession return response (wrapped { data: ... })
• fetchSessionLocations returns response.data (unwrapped)

This creates an inconsistent API surface across the standalone modules.

client/src/api/analytics/standalone/misc.ts (2)

69-80: Inconsistent response type handling already flagged.

This issue with fetchRetention was identified in a previous review. The function should follow the fetchJourneys pattern by typing authedFetch<ProcessedRetentionData> and returning the response directly without the extra .data access.

---

121-136: Fix inconsistent response type handling in fetchPageTitles.

Similar to fetchRetention (already flagged), this function incorrectly wraps the response type. The backend returns PageTitlesPaginatedResponse directly, not { data: PageTitlesPaginatedResponse }.

Apply this diff:

 export async function fetchPageTitles(
   site: string | number,
   params: PageTitlesParams
 ): Promise<PageTitlesPaginatedResponse> {
   const queryParams = {
     ...toQueryParams(params),
     limit: params.limit,
     page: params.page,
   };
 
-  const response = await authedFetch<{ data: PageTitlesPaginatedResponse }>(
+  const response = await authedFetch<PageTitlesPaginatedResponse>(
     `/page-titles/${site}`,
     queryParams
   );
-  return response.data;
+  return response;
 }

client/src/api/analytics/useGetOverviewBucketed.ts (1)

59-59: Minor optimization: getStartAndEndDate call is unnecessary for past-minutes mode.

The getStartAndEndDate call returns { startDate: null, endDate: null } for past-minutes mode (per the utils implementation), but these values are unused since lines 68-69 explicitly set empty strings. Consider moving this call inside the conditional block for non-past-minutes modes to avoid the unnecessary computation.

client/src/api/utils.ts (1)

8-34: Potential null return from toISODate() not handled.

DateTime.fromISO(...).endOf(...).toISODate() can return null if the DateTime is invalid. While unlikely with valid input from time.week, time.month, or time.year, the return type should account for this possibility. The current signature { startDate: string | null; endDate: string | null } does technically allow null, but callers may not expect null from valid week/month/year modes.

Consider adding validation or using a non-null assertion if you're confident the input is always valid:

   if (time.mode === "week") {
     return {
       startDate: time.week,
-      endDate: DateTime.fromISO(time.week).endOf("week").toISODate(),
+      endDate: DateTime.fromISO(time.week).endOf("week").toISODate() ?? time.week,
     };
   }

client/src/api/analytics/useGetMetric.ts (1)

108-114: Complex filter logic could benefit from extraction.

The nested ternary for combinedFilters is moderately complex. Consider extracting to a named variable or helper for readability, though the current logic is correct.

+  const getFilters = () => {
+    if (!useFilters) return undefined;
+    if (customFilters.length > 0) return customFilters;
+    return [...filters, ...additionalFilters];
+  };
+
-  const combinedFilters = useFilters
-    ? customFilters.length > 0
-      ? customFilters
-      : [...filters, ...additionalFilters]
-    : undefined;
+  const combinedFilters = getFilters();

client/src/api/analytics/events/useGetEvents.ts (1)

24-31: The useGetEvents hook appears to be unused; clarify its purpose or remove it.

The useGetEvents hook passes empty strings for startDate and endDate, which triggers the backend's default 30-minute time window (see getEvents.ts line 45). However, this hook is not used in the codebase—only useGetEventsInfinite is active. The empty string handling is correct and intentional per the type documentation in CommonApiParams, but the hook itself should either be removed or its purpose clarified if it's meant for backward compatibility.

client/src/app/[site]/api-playground/hooks/usePlaygroundStore.ts (3)

50-57: Tighten response typing instead of using any.

To keep strict typing, consider changing response: any and setResponse(response: any, ...) to unknown (or a generic type parameter) and narrowing in consumers. This preserves flexibility for the playground while avoiding any sneaking through the rest of the code.

---

117-126: Align PlaygroundFilter types with Filter instead of casting.

getApiFilters currently relies on as Filter["parameter"] / as Filter["type"], which bypasses type checking. Prefer deriving the union types from Filter and using them in PlaygroundFilter and related helpers so mismatches are caught at compile time.

For example:

-interface PlaygroundFilter {
-  parameter: string;
-  operator: string;
-  value: string;
-}
+type FilterParameter = Filter["parameter"];
+type FilterOperator = Filter["type"];
+
+interface PlaygroundFilter {
+  parameter: FilterParameter;
+  operator: FilterOperator;
+  value: string;
+}

Then getApiFilters no longer needs the as assertions.

---

98-106: Avoid duplicating default filter literals; derive from exported options.

addFilter hardcodes { parameter: "country", operator: "equals" } while filterParameters / filterOperators also define these values. This can drift if the constants change. Consider deriving the defaults from the first entries of those arrays:

-  addFilter: () =>
-    set((state) => ({
-      filters: [
-        ...state.filters,
-        { parameter: "country", operator: "equals", value: "" },
-      ],
-    })),
+  addFilter: () =>
+    set((state) => ({
+      filters: [
+        ...state.filters,
+        {
+          parameter: filterParameters[0]?.value ?? "country",
+          operator: filterOperators[0]?.value ?? "equals",
+          value: "",
+        },
+      ],
+    })),

This keeps the UI defaults consistent with the exported option lists.

Also applies to: 188-213

client/src/api/analytics/goals/useUpdateGoal.ts (1)

3-40: updateGoal helper usage looks correct; watch for site ID consistency.

The mutation correctly calls updateGoal(goalData.siteId, { goalId, name, goalType, config }), and the return type matches UpdateGoalResponse. One thing to keep in mind: invalidation uses ["goals", site] from the store while the request uses goalData.siteId. If these can ever differ in future usage, consider invalidating by variables.siteId instead to avoid stale caches.

client/src/app/[site]/api-playground/components/RequestBodyEditor.tsx (1)

31-33: Consider adding accessibility attributes to the error message.

The error message is visually present but not programmatically associated with the textarea for screen readers. Adding aria-live="polite" and/or linking via aria-describedby would improve accessibility.

+      <div className="flex items-center justify-between">
+        <label className="text-sm font-medium text-neutral-700 dark:text-neutral-300">
+          Request Body (JSON)
+        </label>
         {error && (
-          <span className="text-xs text-red-500">{error}</span>
+          <span id="request-body-error" className="text-xs text-red-500" aria-live="polite">{error}</span>
         )}
       </div>
       <Textarea
         value={requestBody}
         onChange={(e) => handleChange(e.target.value)}
         placeholder='{"key": "value"}'
         className="font-mono text-xs min-h-[120px]"
+        aria-describedby={error ? "request-body-error" : undefined}
       />

client/src/api/analytics/funnels/useGetFunnels.ts (1)

10-14: Minor redundancy: early return and enabled guard overlap.

Both the if (!siteId) return [] check and enabled: !!siteId serve to prevent fetching without a siteId. This redundancy is safe but slightly verbose. The enabled flag already prevents the queryFn from running.

     queryFn: async () => {
-      if (!siteId) {
-        return [];
-      }
       return fetchFunnels(siteId);
     },

Alternatively, keep both if you prefer the explicit defensive check.

client/src/api/analytics/useGetSessionLocations.ts (1)

24-33: QueryKey uses filters but queryFn uses locationExcludedFilters.

This is likely intentional—using the full filters in the queryKey ensures cache invalidation when any filter changes. However, it means the cache key doesn't precisely match the request parameters. If this causes confusion later, consider documenting why they differ or using locationExcludedFilters in the queryKey.

client/src/app/[site]/main/components/ExportButton.tsx (1)

113-114: Type cast is redundant and should be removed.

The result.data access is correct—fetchMetric returns Promise<{ data: MetricResponse[]; totalCount: number }>, so the structure matches. However, casting to Record<string, unknown>[] is unnecessary since MetricResponse[] is already a strongly-typed array and fully compatible. Remove the type assertion:

return { filename, data: result.data };

client/src/app/[site]/api-playground/components/ParameterControls.tsx (2)

150-164: Consider handling empty/unset Select values explicitly.

Radix UI's Select component may have issues when value is an empty string. Consider using undefined or a placeholder pattern to indicate "no selection":

 <Select
-  value={endpointParams[param] || ""}
+  value={endpointParams[param] || undefined}
   onValueChange={(value) => setEndpointParam(param, value)}
 >

Alternatively, if an empty string is a valid initial state, ensure the SelectValue placeholder displays correctly when no value is selected.

---

63-65: Consider associating labels with inputs for accessibility.

The <label> elements are not programmatically associated with their corresponding inputs. For better accessibility, use htmlFor and id attributes:

-<label className="text-sm font-medium text-neutral-700 dark:text-neutral-300">
+<label htmlFor={`param-${param}`} className="text-sm font-medium text-neutral-700 dark:text-neutral-300">
   {meta?.label || param}
 </label>
 <Input
+  id={`param-${param}`}
   value={pathParams[param] || ""}

This pattern should be applied to all label/input pairs in the component.

Also applies to: 87-88, 98-99, 129-130, 146-147, 171-172

client/src/api/analytics/errors/useGetErrorEvents.ts (1)

22-32: Consider simplifying the return wrapper.

The fetchErrorEvents already returns ErrorEventsPaginatedResponse (which contains data and totalCount). Wrapping it again as { data } creates a nested structure { data: { data: ErrorEvent[], totalCount: number } }.

While this works with the current getNextPageParam implementation, it adds unnecessary nesting. Consider whether this wrapper is needed for backward compatibility, or if it can be simplified:

    queryFn: async ({ pageParam = 1 }) => {
-     const data = await fetchErrorEvents(site, {
+     return fetchErrorEvents(site, {
        startDate: startDate ?? "",
        endDate: endDate ?? "",
        timeZone,
        filters,
        errorMessage,
        limit: 20,
        page: pageParam,
      });
-     return { data };
    },

If simplified, update getNextPageParam accordingly:

-   getNextPageParam: (lastPage: { data: ErrorEventsPaginatedResponse }, allPages) => {
+   getNextPageParam: (lastPage: ErrorEventsPaginatedResponse, allPages) => {
      const currentPage = allPages.length;
-     const totalItems = lastPage?.data?.totalCount || 0;
+     const totalItems = lastPage?.totalCount || 0;

client/src/api/analytics/sessionReplay/useGetSessionReplayEvents.ts (1)

2-10: Redundant type imports alongside re-exports.

The types SessionReplayEvent, SessionReplayMetadata, and GetSessionReplayEventsResponse are imported at lines 4-6 but aren't used within this file—they're only re-exported at line 10. You can remove the imports and keep only the export type re-export, which doesn't require importing the types first.

 import { useQuery } from "@tanstack/react-query";
-import {
-  fetchSessionReplayEvents,
-  SessionReplayEvent,
-  SessionReplayMetadata,
-  GetSessionReplayEventsResponse,
-} from "../standalone";
+import { fetchSessionReplayEvents } from "../standalone";

 // Re-export types from standalone
 export type { SessionReplayEvent, SessionReplayMetadata, GetSessionReplayEventsResponse } from "../standalone";

client/src/api/analytics/standalone/types.ts (1)

7-15: Consider documenting the empty-string convention.

The interface comments mention (empty string for past-minutes mode) but the relationship between empty strings and pastMinutesStart/pastMinutesEnd could be clearer. Since toQueryParams uses pastMinutesStart !== undefined to detect the mode, consider adding a brief note that callers should pass empty strings for startDate/endDate when using past-minutes mode.

client/src/api/analytics/standalone/overview.ts (1)

11-20: Redundant type imports alongside re-exports.

Similar to the session replay file, types are both re-exported (lines 12-15) and imported separately (lines 17-20). The re-export doesn't require the separate import statement.

 // Re-export types from hooks for convenience
 export type { GetOverviewResponse } from "../useGetOverview";
 export type { GetOverviewBucketedResponse } from "../useGetOverviewBucketed";
 export type { MetricResponse } from "../useGetMetric";
 export type { LiveUserCountResponse } from "../useGetLiveUserCount";

-import type { GetOverviewResponse } from "../useGetOverview";
-import type { GetOverviewBucketedResponse } from "../useGetOverviewBucketed";
-import type { MetricResponse } from "../useGetMetric";
-import type { LiveUserCountResponse } from "../useGetLiveUserCount";

Then use inline type imports where needed in the function signatures, or keep the type imports if TypeScript requires them for the return type annotations.

client/src/api/analytics/standalone/sessionReplay.ts (2)

4-31: Inconsistent date types between list and detail responses.

SessionReplayListItem uses string for start_time and end_time (lines 10-11), while SessionReplayMetadata uses Date for the same fields (lines 46-47). If the API returns consistent types, consider aligning these—typically API responses return ISO strings that need to be parsed into Date objects on the client side.

If the API returns ISO date strings, consider:

 export interface SessionReplayMetadata {
   // ...
-  start_time: Date;
-  end_time?: Date;
+  start_time: string;
+  end_time?: string;
   // ...
-  created_at: Date;
+  created_at: string;
 }

Alternatively, if Date objects are desired, parse them during fetch or add a transformation layer.

---

33-38: Consider documenting the type union.

The type: string | number union is unusual. If this aligns with rrweb's event type system, a brief comment explaining this would help maintainability. The data: any is acceptable given the varied nature of replay event payloads.

client/src/api/analytics/useGetUserSessions.ts (3)

4-4: Remove unused import APIResponse.

The APIResponse type is imported but no longer used after migrating to the standalone fetchers that return { data: T } directly.

-import { APIResponse } from "../types";

---

42-55: Duplicated date handling logic across hooks.

The logic for computing effectiveStartDate and effectiveEndDate is duplicated in useGetSessions (lines 43-44) and useGetSessionsInfinite (lines 71-72). Consider extracting this into a helper function for maintainability.

// Example helper at module scope
function getEffectiveDates(
  time: Time, 
  startDate: string | null, 
  endDate: string | null, 
  userId?: string
) {
  const skipDates = time.mode === "past-minutes" || userId;
  return {
    effectiveStartDate: skipDates ? "" : (startDate ?? ""),
    effectiveEndDate: skipDates ? "" : (endDate ?? ""),
  };
}

---

101-103: Redundant condition check.

The condition pastMinutesMode && time.mode === "past-minutes" is redundant since pastMinutesMode is already assigned from time.mode === "past-minutes" on line 97. Simplify to just use pastMinutesMode.

-  if (pastMinutesMode && time.mode === "past-minutes") {
+  if (pastMinutesMode) {
     minutes = time.pastMinutesStart;
   }

client/src/api/analytics/funnels/useGetFunnel.ts (2)

46-48: Generic error message loses context.

The catch block discards the original error details. Consider preserving the error cause for debugging.

       } catch (error) {
-        throw new Error("Failed to analyze funnel");
+        throw new Error("Failed to analyze funnel", { cause: error });
       }

---

74-76: Same pattern: preserve error cause for debugging.

       } catch (error) {
-        throw new Error("Failed to save funnel");
+        throw new Error("Failed to save funnel", { cause: error });
       }

client/src/api/analytics/standalone/users.ts (2)

5-10: Reorder imports to appear before re-exports.

The type imports on lines 9-10 appear after the re-exports on lines 6-7. Per coding guidelines, group imports logically. Consider moving the type imports before the re-exports for clarity.

+import type { UsersResponse } from "../useGetUsers";
+import type { UserInfo } from "../userGetInfo";
+
 // Re-export types from hooks
 export type { UsersResponse } from "../useGetUsers";
 export type { UserInfo, LinkedDevice } from "../userGetInfo";
-
-import type { UsersResponse } from "../useGetUsers";
-import type { UserInfo } from "../userGetInfo";

---

43-108: Same inconsistent response unwrapping pattern.

Similar to funnels.ts:

• fetchUsers returns response directly (line 60)
• fetchUserSessions returns response directly (line 75)
• fetchUserSessionCount returns response directly (line 93)
• fetchUserInfo returns response.data (line 107)

Consider standardizing the unwrapping pattern across all standalone API modules.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:24.979Z
Learning: Frontend: Use Next.js with Turbopack, Tailwind CSS, Shadcn UI, Tanstack Query, Zustand, Luxon, Nivo, and react-hook-form

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:24.979Z
Learning: Applies to client/**/*.{ts,tsx} : Client: React functional components with minimal useEffect and inline functions

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:42.365Z
Learning: Applies to docs/**/*.{ts,tsx} : Use React 19 functional components with hooks

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:42.365Z
Learning: Applies to docs/src/mdx-components.tsx : Define MDX components in `src/mdx-components.tsx` for rendering custom markdown elements

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:42.365Z
Learning: Applies to docs/app/**/*.{ts,tsx} : Use route groups with App Router for organizing marketing, documentation, and blog pages

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/src/app/(home)/tools/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:59.895Z
Learning: Applies to docs/src/app/(home)/tools/**/tools/*/[slug]/page.tsx : For multi-platform tools with identical logic but different branding, use dynamic route pattern `[slug]/page.tsx` with `generateStaticParams()` to minimize code duplication

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:42.365Z
Learning: Applies to docs/app/(home)/tools/**/*.{ts,tsx} : Place tool components and API routes in `app/(home)/tools/` directory for analytics and SEO tools

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/src/app/(home)/tools/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:59.895Z
Learning: Applies to docs/src/app/(home)/tools/**/tools/**/[slug]/page.tsx : Use `await params` to extract dynamic route parameters in Next.js 15+ (required for Server Components)

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/src/app/(home)/tools/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:59.895Z
Learning: Applies to docs/src/app/(home)/tools/**/tools/**/[slug]/page.tsx : Use `notFound()` from Next.js when a requested platform configuration is not found

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/src/app/(home)/tools/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:59.895Z
Learning: Applies to docs/src/app/(home)/tools/**/tools/**/page.tsx : Tool client components should be named as `YourToolForm.tsx` and placed in the same directory as `page.tsx`

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:24.979Z
Learning: Frontend: Use Next.js with Turbopack, Tailwind CSS, Shadcn UI, Tanstack Query, Zustand, Luxon, Nivo, and react-hook-form

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:42.365Z
Learning: Applies to docs/src/lib/trackAdEvent.ts : Track analytics events via `src/lib/trackAdEvent.ts` for monitoring tool usage and analytics

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/src/app/(home)/tools/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:59.895Z
Learning: Applies to docs/src/app/(home)/tools/**/tools/**/*.tsx : Use `useState(false)` for loading state and display 'Processing...' during loading

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/src/app/(home)/tools/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:59.895Z
Learning: Applies to docs/src/app/(home)/tools/**/tools/**/*.tsx : Use `useState<string | null>(null)` for error state and display error in `bg-red-50` container when present

Learnt from: CR
Repo: rybbit-io/rybbit PR: 0
File: docs/src/app/(home)/tools/CLAUDE.md:0-0
Timestamp: 2025-11-25T02:34:59.895Z
Learning: Applies to docs/src/app/(home)/tools/**/tools/**/platform-configs.ts : Platform configurations should be stored in `platform-configs.ts` as a `Record<string, PlatformConfig>` with `platformList` export for generating static params