Cookbook: Apify Actor with per-user OAuth via Scalekit Agent Auth#622
Conversation
Covers deriving connected-account identifier from Apify userId, shared vs per-user connector design, interactive live-view auth UX, and input schema best practices learned building the notion-youtube-agent actor. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughAdds a new cookbook MDX explaining how to implement per-user OAuth in Apify Actors using Scalekit Agent Auth, covering identifier derivation, authorization gating, serving a live consent page, wiring the flow into the Actor entry point, input schema, testing, common pitfalls, and production notes. ChangesOAuth Cookbook Documentation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~15 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
✅ Deploy Preview for scalekit-starlight ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
Actionable comments posted: 7
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx`:
- Around line 230-232: Add the missing fenced code block language identifier by
changing the URL snippet fence from ``` to ```text so the block containing
"https://{actorId}--{actorRunId}-{PORT}.runs.apify.net" is marked as plain text;
update the fenced code block around that URL in the
apify-actor-per-user-oauth.mdx content to use ```text at the start and ``` at
the end.
- Around line 52-56: The fenced code block containing the environment variables
(the triple backticks before the lines "SCALEKIT_ENV_URL=...",
"SCALEKIT_CLIENT_ID=...", "SCALEKIT_CLIENT_SECRET=...") needs a language
identifier for syntax highlighting and accessibility; update the opening fence
from ``` to ```bash so the block becomes a bash shell snippet and nothing else
in the file requires changes.
- Line 18: The file imports unused components TabItem and Tabs; remove the
import statement or drop TabItem and Tabs from the import so only used
components remain (e.g., remove "TabItem, Tabs" from the import line that
currently reads "import { TabItem, Tabs } from '@astrojs/starlight/components';"
and keep other required imports if any) to satisfy the guideline of importing
components only when used.
- Around line 78-81: The fenced code block in the caution lacks a language
identifier; update the block that contains Actor.getEnv(), the userId
destructuring, and the notionIdentifier fallback (symbols: Actor.getEnv, userId,
notionIdentifier) to include the JavaScript language tag (e.g., ```js) before
the code and close with ``` after it so the example is properly
syntax-highlighted.
- Around line 1-16: Update the frontmatter "title" value to a shorter string of
60 characters or fewer (replace the current 72-character title in the title
field) so it clearly describes the page; edit the title frontmatter (the title:
'Build an Apify Actor with per-user OAuth using Scalekit Agent Auth') to a
concise variant ≤60 chars that preserves the core concept (e.g., "Apify Actor
with per-user OAuth via Scalekit") and save the change.
- Around line 319-321: Replace the directive block using the admonition syntax
(::note[...]) with the JSX Aside component: wrap the same message text inside an
<Aside title="Apify input schema does not support `placeholder`"> … </Aside>
element (using the Aside component name) so it follows the project's
accessibility/guidelines; ensure the title attribute matches the note label and
the body contains the guidance about putting example values in description
instead of placeholder.
- Around line 75-82: Replace the directive-style caution block with the JSX
<Aside> component and add an import for Aside at the top of the file;
specifically, import the Aside component (near the other imports around line 18)
and wrap the existing snippet that references Actor.getEnv() / notionIdentifier
in an <Aside title="Caution">...</Aside> so it uses the accessible component
instead of the :::caution directive.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 0d7bc644-df8d-4339-8571-96b2d1ccb49a
📒 Files selected for processing (1)
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Redirect rules - scalekit-starlight
- GitHub Check: Header rules - scalekit-starlight
- GitHub Check: Pages changed - scalekit-starlight
🧰 Additional context used
📓 Path-based instructions (6)
**/*.mdx
📄 CodeRabbit inference engine (.cursorrules)
**/*.mdx: Use clear, descriptive titles that explain the purpose of the document
Include comprehensive descriptions in frontmatter metadata
Organize content with logical heading hierarchy (H2, H3, H4)
Use tableOfContents property in frontmatter when content has multiple sections
Set appropriate sidebar labels for navigation in frontmatter
Use direct instruction writing style with phrases like 'This guide shows you how to...' and 'Create an authorization URL to...'
Use second person perspective ('your application', 'you receive', 'you must') in documentation
Keep sentences concise, aiming for under 25 words per sentence
Explain the 'why' in documentation with phrases like 'This prevents CSRF attacks by...' or 'Use this to validate that...'
Use action verbs in section headings: 'Store session tokens securely', 'Validate the state parameter', 'Exchange authorization code for tokens'
Use present tense for descriptions: 'Scalekit handles the complex authentication flow', 'The SDK provides methods to refresh tokens'
Use future tense for results: 'This will redirect users to...', 'You'll receive a JWT containing...', 'Scalekit returns an authorization code'
Use transition phrases between sections: 'After the user authenticates...', 'Once the state is validated...', 'Let's take a look at how to...'
Write 1-3 opening paragraphs that explain what users will accomplish, provide context about when/why, preview key concepts, and use direct instructional language
Begin introduction sections with a clear statement of what the guide covers and explain the problem being solved
Use collapsible sections in introduction for sequence diagrams, video demonstrations, data models, and JSON examples with appropriate icons
Use numbered format within Steps component:1. ## Titlewith all step content indented with exactly 3 spaces
Use action-oriented headings in step-by-step guides within Steps components
Include code examples in all 4 languages (Node.js, Python, Go, Java) within Steps co...
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
⚙️ CodeRabbit configuration file
**/*.mdx: You are reviewing Scalekit developer documentation written in MDX
(Astro + Starlight framework). Apply ALL of the following checks:Frontmatter
titleMUST be ≤ 60 characters and clearly state what the page does.descriptionMUST be ≤ 160 characters, action-oriented, unique per page.sidebar.labelMUST be present and ≤ 30 characters.sidebar.orderMUST be set on every page that lives inside a section
with siblings, to enforce the journey order in sidebar.config.ts.- Flag any missing
prev/nextlinks on pages that are clearly
part of a sequential flow (e.g., quickstart → implement-login →
complete-login → manage-session → logout).Voice & Style (CLAUDE.md standards)
- Voice: confident, direct, collaborative, instructional.
- Person: second person only ("you", "your application"). Reject "we",
"our", "the developer", "the user".- Tense: present tense for descriptions; imperative mood for instructions.
- Flag weasel words: "simply", "just", "easy", "straightforward",
"obviously", "of course", "note that".- Flag passive voice constructions where active voice is clearer.
- Headings must be sentence case, not Title Case (except proper nouns).
- No heading should end with a colon or period.
Content structure
- Journey how-to guides MUST contain numbered
<Steps>(Starlight
component). This does NOT apply tosrc/content/docs/cookbooks/**
(blog-style recipes — optional<Steps>,<Tabs>after</Steps>OK;
see cookbookspath_instructions).- Concept pages MUST NOT contain numbered steps — concepts explain, not instruct.
- API reference pages MUST list parameters in a table with Name / Type /
Required / Description columns.- Every page MUST end with a clear "what's next" signal — either a
next:frontmatter link, a<LinkCard>, or an explicit paragraph
pointing the reader forward in the sidebar journey.Code examples
- ALL code examples that show SDK usage MUST include all four language
tabs...
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
**/*.{yml,yaml,md,mdx}
📄 CodeRabbit inference engine (.cursor/rules/browsecentral-labels.mdc)
**/*.{yml,yaml,md,mdx}: BrowseCentral labels should be maximum 3-5 words - keep concise but add context when needed
BrowseCentral labels should be action-oriented - start with verbs when possible
BrowseCentral labels should be specific and clear - add context when simple labels are ambiguous
BrowseCentral labels should be outcome-focused - describe what users accomplish and the context
BrowseCentral labels should use 'Action + Object' pattern (e.g., 'Invite users', 'Restrict sign-up', 'Set up SCIM')
BrowseCentral labels should use feature names (e.g., 'Enterprise SSO', 'Passwordless quickstart')
BrowseCentral labels should describe task completion (e.g., 'Run migrations', 'Migrate auth', 'Merge identities')
BrowseCentral labels should include specific context when needed (e.g., 'Configure Scalekit MCP server', 'Validate incoming API requests')
BrowseCentral labels should use integration context when applicable (e.g., 'Build MCP auth with your existing auth system')
BrowseCentral labels should avoid instructional prefixes: 'How to', 'Guide to', 'Implement', 'Configure', 'Learn', 'Understand'
BrowseCentral labels should avoid verbose phrases: 'Step-by-step guide', 'Complete tutorial', 'Detailed documentation'
BrowseCentral labels should avoid weak verbs: 'Enable', 'Allow', 'Provide', 'Support'
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
**/*.{md,mdx}
📄 CodeRabbit inference engine (.cursor/rules/deno-docs-style.mdc)
**/*.{md,mdx}: Use sentence case for all titles and headings in MD/MDX documentation
Keep page titles short and descriptive (3–7 words when possible) in MD/MDX documentation
Use outcome-focused headings that describe results, not categories (e.g., 'Run a script' not 'Scripts')
Avoid gerunds in headings when an imperative works - prefer 'Configure proxies' over 'Configuring proxies'
Keep sidebar labels concise (1–3 words), use sentence case, and focus on outcomes or objects
Use sentence case in sidebar labels without punctuation
Set frontmatter title in sentence case with a clear outcome; description in one sentence (≤160 chars); sidebar.label as shorter form of title; enable tableOfContents on longer pages
Start documentation pages with a one-paragraph overview explaining what the page covers and when to use it
Present the primary use case (80% path) first in documentation, with edge cases later
Use numbered steps for task-focused sections in documentation, with each step beginning with a verb
Break up long documentation sections with subheadings every 3–6 paragraphs
Use asides for important notes, tips, cautions, and references in documentation
Provide runnable, minimal code examples that work as-is in documentation
Prefer CLI-first examples and show file layout when helpful in documentation
Label code blocks with titles for context (e.g., 'Terminal', 'main.ts') in documentation
Keep code block annotations brief and purposeful - annotate only what matters
Use consistent variable and file names across a documentation page
Use descriptive link text in documentation (e.g., 'See permission flags' not 'click here')
Prefer relative links for internal documentation pages and include anchors for section references
Reference APIs consistently using backticks for code, file names, CLI flags, and endpoints
Use backticks for code, file names, CLI flags, and endpoints in documentation
Use lists for options and features in documentation; tables only when comparisons are cleare...
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
src/content/docs/**/*.mdx
📄 CodeRabbit inference engine (.cursor/rules/starlight-steps-tabs-structure.mdc)
src/content/docs/**/*.mdx: In MDX documentation files,<Steps>must contain one continuous ordered list. Wrap<Steps>around a normal Markdown ordered list such as1. ## ...
In MDX documentation files, numbered step lines must start at column 0. Do not indent the1. ##,2. ##, etc.
In MDX documentation files, any content that belongs to a step must be indented with 3 spaces: paragraphs, bullets, images,<Tabs>,<TabItem>, and fenced code blocks
In MDX documentation files, prefer plain Markdown inside<Steps>. If the content is mostly<Tabs>or other JSX-heavy blocks, use normal section headings instead of<Steps>
In MDX documentation files, when<Tabs>is used inside a step, keep<Tabs>,<TabItem>,</TabItem>, and</Tabs>consistently nested under that step
In MDX documentation files, if a tabs block is not part of a numbered step, place it outside</Steps>
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
src/content/docs/**/*.{md,mdx}
📄 CodeRabbit inference engine (CLAUDE.md)
src/content/docs/**/*.{md,mdx}: Every documentation page must include frontmatter with at least:title(≤60 chars),description(≤160 chars), andsidebar.label(1-3 words)
Use H2 for major sections, H3 for subsections, and H4 only inside<Steps>; never use H1 in body content and avoid nesting beyond H4
Use numbered lists only inside<Steps>for ordered procedures; use bulleted lists for unordered information
Use bold for first mention of important terms, UI elements, and dashboard paths; use inline code for technical identifiers (variables, functions, endpoints, scopes, environment variables, file paths, placeholders)
The<Steps>component requires a single continuous ordered list with proper indentation: steps at column 0, continuation content indented with exactly 3 spaces
Use<Aside>component with atitleattribute for cautions, tips, and notes
Use<Badge>component to indicate parameter requirements in tables and inline text
Use<details>blocks at the end of pages for FAQs, common scenarios, and troubleshooting
Split content into clear sections with descriptive, sentence-style titles; include a table of contents for documents with multiple sections; keep paragraphs short and isolate critical points in their own short paragraphs
Begin sections and paragraphs with standalone topic sentences that preview content; put topic words at the beginning to support fast skimming; put key takeaways and results at the top of documents
Use bullets and tables generously to structure information; bold important text to highlight key concepts and decisions
Keep sentences simple, right-branching, and unambiguous; avoid ambiguous noun stacks and demonstrative pronouns like 'this' or 'that' when the referent is not explicit
Maintain strict consistency in terminology, formatting, and style; do not presume the reader's state of mind or intentions; use direct, instructional language
Write more simply than you think you need to; optimize for readers new to the do...
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
src/content/docs/cookbooks/**/*.mdx
⚙️ CodeRabbit configuration file
src/content/docs/cookbooks/**/*.mdx: This file is a Scalekit cookbook: a standalone recipe under the
starlight-blog integration (prefix: cookbooksin astro.config.mjs).
Apply global MDX voice, style, links, and accessibility rules, but use
these cookbook-specific expectations:Overrides to global MDX checks
- Do NOT require
sidebar.order— ordering follows the blog plugin and
publication metadata, not sidebar.config.ts journey slots.- Do NOT require
prev/nextfrontmatter — cookbooks are not a
sequential product journey; cross-links and related docs are enough.tableOfContentsis optional — enable it when the post has many H2s.Frontmatter
titleanddescriptionfollow the same length and clarity rules as
global MDX.- Prefer
sidebar.labelfor navigation consistency; if absent, do not
treat it as a hard failure (older cookbooks may omit it).date,tags,authors,excerpt, andfeaturedare normal for
cookbooks — verify tags match the topic (e.g. MCP, SSO, FSA).Code examples
- Require all four SDK tabs (Node.js, Python, Go, Java) ONLY when the
snippet demonstrates Scalekit client SDK usage. For MCP setup, CLI,
shell, framework-only (e.g. Next.js), or IDE configuration recipes,
use the tabs or single-language blocks that fit the task. Do not
demand four SDK languages for bash, JSON, env files, or non-SDK code.- Minimal examples (single command, config block) do not need both
success and error paths unless the recipe is explicitly about errors.- Flag real-looking API keys or secrets — use placeholders such as
YOUR_API_KEYorYOUR_CLIENT_SECRET.
<Steps>(overrides global "how-to MUST use Steps")
- Do NOT require
<Steps>on cookbooks. The global rule targets journey
how-to pages; a cookbook may use H2 sections,<Tabs>, or prose.- Do NOT flag "missing Steps" when the procedure is already clear.
- If
<Steps>is used,<Tabs>or other blocks MAY appear after
</Steps>(e.g. per–IDE ...
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
🧠 Learnings (17)
📓 Common learnings
Learnt from: CR
Repo: scalekit-inc/developer-docs PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-20T11:29:40.242Z
Learning: Product-based documentation (MCP Auth, Agent Auth, Full Stack Auth, Modular SCIM, Modular SSO) must follow a journey-focused approach representing a developer's journey toward implementing authentication
Learnt from: CR
Repo: scalekit-inc/developer-docs PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-04-20T11:30:52.410Z
Learning: Product-based documentation (MCP Auth, Agent Auth, Full Stack Auth, Modular SCIM, Modular SSO) MUST follow a journey-focused approach. Each product represents a developer's journey toward implementing authentication in their projects
📚 Learning: 2026-03-12T05:02:13.454Z
Learnt from: dhaneshbs
Repo: scalekit-inc/developer-docs PR: 487
File: src/content/docs/agent-auth/connections.mdx:0-0
Timestamp: 2026-03-12T05:02:13.454Z
Learning: In `src/content/docs/agent-auth/connections.mdx` (and Agent Auth docs in general), custom authentication (username/password/bearer-token flows) is intentionally out of scope for the current Agent Auth release. Do not flag the absence of custom authentication documentation in Agent Auth connection-type sections.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-03-12T05:02:13.454Z
Learnt from: dhaneshbs
Repo: scalekit-inc/developer-docs PR: 487
File: src/content/docs/agent-auth/connections.mdx:0-0
Timestamp: 2026-03-12T05:02:13.454Z
Learning: In `src/content/docs/agent-auth/connections.mdx` (and Agent Auth docs generally), custom authentication (username/password/bearer-token flows) is intentionally out of scope for the current Agent Auth release. Do not flag the absence of custom authentication connection type documentation in Agent Auth connection-type sections.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-04-20T11:29:40.242Z
Learnt from: CR
Repo: scalekit-inc/developer-docs PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-20T11:29:40.242Z
Learning: Product-based documentation (MCP Auth, Agent Auth, Full Stack Auth, Modular SCIM, Modular SSO) must follow a journey-focused approach representing a developer's journey toward implementing authentication
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-04-01T08:35:26.973Z
Learnt from: srinivaskarre-sk
Repo: scalekit-inc/developer-docs PR: 566
File: src/content/docs/agent-auth/user-verification.mdx:55-117
Timestamp: 2026-04-01T08:35:26.973Z
Learning: In `src/content/docs/agent-auth/user-verification.mdx` and Agent Auth connected accounts documentation (src/content/docs/agent-auth/**/*.mdx), only Python and Node.js SDK support is currently available for Agent Auth features (including connected accounts magic link creation and user verification). Do not require or enforce Go and Java tabs in `<Tabs syncKey="tech-stack">` blocks for these files. Add Go and Java TabItems once those SDKs support Agent Auth/connected account features.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-04-20T11:29:40.242Z
Learnt from: CR
Repo: scalekit-inc/developer-docs PR: 0
File: CLAUDE.md:0-0
Timestamp: 2026-04-20T11:29:40.242Z
Learning: Applies to src/content/docs/agentkit/**/*.{md,mdx} : Agentkit code examples live in the external repo **scalekit-developers/agent-auth-examples** organized as `javascript/frameworks/<framework>` and `python/frameworks/<framework>`; verify docs snippets match current implementations in that repo
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-01-30T18:18:50.883Z
Learnt from: AkshayParihar33
Repo: scalekit-inc/developer-docs PR: 415
File: src/content/docs/authenticate/fsa/multiapp/manage-apps.mdx:31-49
Timestamp: 2026-01-30T18:18:50.883Z
Learning: In all Scalekit documentation files (MDX), treat the terms 'Applications', 'Single Page Application (SPA)', 'Native Application', and 'Web Application' as proper nouns and preserve their capitalization in headings and body text. Ensure these terms remain capitalized even when used in sentence case or within prose.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-02-04T12:47:16.544Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 412
File: src/content/docs/dev-kit/tools/scalekit-dryrun.mdx:1-23
Timestamp: 2026-02-04T12:47:16.544Z
Learning: In scalekit-inc/developer-docs, the MDX frontmatter field order is required only when the sidebar configuration points to a directory (for auto-generation). If the sidebar.config.ts references a specific file path, the order field is not required. Apply this check to all MDX files under src/content/docs: if a file contributes to an auto-generated sidebar (directory path), ensure order is present; if it’s linked to a concrete file, order can be omitted. Use sidebar.config.ts to determine whether a given MDX file falls under directory-based vs file-specific sidebar references.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-02-25T08:57:12.201Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 444
File: src/content/docs/agent-auth/quickstart.mdx:2-10
Timestamp: 2026-02-25T08:57:12.201Z
Learning: In Scalekit developer-docs (Astro Starlight), do not auto-suggest adding tableOfContents in frontmatter unless the user explicitly overrides the default behavior. The default enables tableOfContents with minHeadingLevel 2 and maxHeadingLevel 3. Only set tableOfContents when you want to customize heading levels or disable it entirely; otherwise omit it for other docs.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-02-25T13:04:27.491Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 444
File: src/content/docs/agent-auth/start-agent-auth-coding-agents.mdx:9-17
Timestamp: 2026-02-25T13:04:27.491Z
Learning: Allow page-level CSS overrides in MDX frontmatter (head: style) for readability and engagement, even if it customizes typography beyond defaults. This applies to per-page UX decisions, including heading sizes and style tweaks, but keep overrides purposeful, accessible, and within the repository's design guidelines. Use these overrides sparingly and document the rationale for maintainability.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-03-05T11:29:08.125Z
Learnt from: AkshayParihar33
Repo: scalekit-inc/developer-docs PR: 463
File: src/content/docs/agent-auth/providers.mdx:35-73
Timestamp: 2026-03-05T11:29:08.125Z
Learning: In src/content/docs/agent-auth/providers.mdx, the Card components intentionally use icon=" " (a space) to render consistent colored boxes since some Starlight icon names resolve to icons and others do not. Do not flag icon=" " as a placeholder issue for this file; treat this as a deliberate UX choice specific to this MDX page and avoid raising a placeholder-icon warning here.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-03-09T07:27:56.794Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 469
File: src/content/docs/guides/integrations/scim-integrations/azure-scim.mdx:95-107
Timestamp: 2026-03-09T07:27:56.794Z
Learning: Do not enforce the 3-space indentation rule for Steps component content as a hard style rule in MDX files under src/content/docs/**/*.mdx. Only flag/rectify it if it causes visible rendering problems in the UI. Otherwise, allow current formatting; apply this rule only when rendering issues are observed and document any fixes.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-03-09T07:32:38.426Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 467
File: src/content/docs/sso/guides/sso-user-attributes.mdx:108-148
Timestamp: 2026-03-09T07:32:38.426Z
Learning: In MDX code samples under src/content/docs (and similar conceptual snippets in scalekit-inc/developer-docs), when an example's sole purpose is to show how to access a specific value (e.g., reading JWT claims after token validation), omit error/non-happy-path handling to keep the snippet focused. Do not flag the absence of error paths in narrowly scoped conceptual snippets.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-03-17T16:01:50.487Z
Learnt from: dhaneshbs
Repo: scalekit-inc/developer-docs PR: 506
File: src/content/docs/authenticate/fsa/quickstart.mdx:851-853
Timestamp: 2026-03-17T16:01:50.487Z
Learning: In the Scalekit Python SDK docs, clarify that LogoutUrlOptions is not exported from the top-level scalekit package __init__.py. The correct import path in code samples or reviews is: from scalekit.common.scalekit import LogoutUrlOptions. Do not flag this import path as incorrect in documentation or code reviews; ensure examples reflect the proper import path to avoid confusion for users.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-02-25T03:34:41.147Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 444
File: src/content/docs/agent-auth/start-agent-auth-coding-agents.mdx:31-31
Timestamp: 2026-02-25T03:34:41.147Z
Learning: In MDX files, import { Code } from 'astrojs/starlight/components' only if the MDX content actually uses the <Code> component. If the file uses only fenced code blocks (```), the import is not required. Apply this guideline to all MDX files (e.g., src/content/docs/**/*.mdx) to avoid unnecessary imports and reduce bundle size.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-02-25T18:41:00.639Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 446
File: src/content/docs/authenticate/m2m/api-auth-quickstart.mdx:78-78
Timestamp: 2026-02-25T18:41:00.639Z
Learning: Preserve full URLs inside code comments in MDX code blocks (bash/python/js) when the URLs are part of copyable examples. Do not flag these in code examples. Use relative paths in prose and hyperlinks within MDX; only enforce relative paths for markdown prose links, not for URLs inside code comments.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-03-26T13:43:49.940Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 539
File: src/content/docs/cookbooks/search-scalekit-docs-in-your-ide.mdx:1-15
Timestamp: 2026-03-26T13:43:49.940Z
Learning: In scalekit-inc/developer-docs, cookbook pages under `src/content/docs/cookbooks/` use directory-based auto-generation for the sidebar (configured in `src/configs/sidebar.config.ts` with routes like `/cookbooks` and `/cookbooks/**/*`). For files in this directory, do not require or flag missing `sidebar.label` in the MDX frontmatter.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
🪛 LanguageTool
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
[style] ~22-~22: Consider using “who” when you are referring to a person instead of an object.
Context: ...omatically. This recipe builds an Actor that connects to Notion per-user and to YouT...
(THAT_WHO)
🔇 Additional comments (1)
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx (1)
20-412: Excellent cookbook structure and content flow.This cookbook exemplifies strong technical writing:
- Opening paragraphs clearly explain the problem, solution, and value
- "What this recipe covers" section sets clear expectations
- Logical progression from setup → implementation → testing → production notes
- Consistent second-person voice with imperative mood in instructions
- Clear "Next steps" with actionable links to related documentation
<details>blocks for common mistakes provide practical troubleshooting- Production notes address real-world concerns (token persistence, re-authorization)
The content is well-scoped for the Agent Auth + Apify Actor use case, and the explanations strike a good balance between brevity and completeness.
- Add 'Before you start' section: enable YouTube Data API v3, create OAuth clients, Notion integration setup, and tooling prerequisites - Expand Step 1 with full YouTube and Notion connector configuration including scopes, redirect URIs, and scope-locking caution - Add NOTION_DEFAULT_PARENT_PAGE_ID env var guidance with instructions for finding a Notion page ID - Add three runtime failure modes to Common mistakes: - permission_denied when API is not enabled (YouTube Data API v3) - permission_denied after adding scopes to existing tokens - Notion page creation without a default parent configured - Fix dashboard path from 'Agent Auth' to 'AgentKit' for consistency
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx`:
- Around line 95-97: The fenced code block containing the environment variable
NOTION_DEFAULT_PARENT_PAGE_ID lacks a language identifier; update that specific
code fence in src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx to
include a language tag (e.g., use ```bash) so the block reads as a bash/env
style snippet for the NOTION_DEFAULT_PARENT_PAGE_ID entry.
- Line 3: Shorten the frontmatter "description" value so it is ≤160 characters,
action-oriented and unique for this page; locate the description string in the
frontmatter (the line that currently reads description: 'Deploy a serverless
Apify Actor that authenticates each user against their own OAuth-protected APIs,
using Apify user identity to key Scalekit connected accounts.') and replace it
with a concise action-focused summary under 160 chars (e.g., "Deploy a
serverless Apify Actor that authenticates each user against their
OAuth-protected APIs and keys Scalekit accounts by Apify user identity"). Ensure
the new text remains accurate to the page content and stays within the character
limit.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 991f8a0d-3f93-4fb7-8e6f-d9457b396ed4
📒 Files selected for processing (1)
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Redirect rules - scalekit-starlight
- GitHub Check: Header rules - scalekit-starlight
- GitHub Check: Pages changed - scalekit-starlight
🧰 Additional context used
📓 Path-based instructions (8)
**/*.mdx
📄 CodeRabbit inference engine (.cursorrules)
**/*.mdx: Use clear, descriptive titles that explain the purpose of the document
Include comprehensive descriptions in frontmatter metadata
Organize content with logical heading hierarchy (H2, H3, H4)
Use tableOfContents property in frontmatter when content has multiple sections
Set appropriate sidebar labels for navigation in frontmatter
Use direct instruction writing style with phrases like 'This guide shows you how to...' and 'Create an authorization URL to...'
Use second person perspective ('your application', 'you receive', 'you must') in documentation
Keep sentences concise, aiming for under 25 words per sentence
Explain the 'why' in documentation with phrases like 'This prevents CSRF attacks by...' or 'Use this to validate that...'
Use action verbs in section headings: 'Store session tokens securely', 'Validate the state parameter', 'Exchange authorization code for tokens'
Use present tense for descriptions: 'Scalekit handles the complex authentication flow', 'The SDK provides methods to refresh tokens'
Use future tense for results: 'This will redirect users to...', 'You'll receive a JWT containing...', 'Scalekit returns an authorization code'
Use transition phrases between sections: 'After the user authenticates...', 'Once the state is validated...', 'Let's take a look at how to...'
Write 1-3 opening paragraphs that explain what users will accomplish, provide context about when/why, preview key concepts, and use direct instructional language
Begin introduction sections with a clear statement of what the guide covers and explain the problem being solved
Use collapsible sections in introduction for sequence diagrams, video demonstrations, data models, and JSON examples with appropriate icons
Use numbered format within Steps component:1. ## Titlewith all step content indented with exactly 3 spaces
Use action-oriented headings in step-by-step guides within Steps components
Include code examples in all 4 languages (Node.js, Python, Go, Java) within Steps co...
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
⚙️ CodeRabbit configuration file
**/*.mdx: You are reviewing Scalekit developer documentation written in MDX
(Astro + Starlight framework). Apply ALL of the following checks:Frontmatter
titleMUST be ≤ 60 characters and clearly state what the page does.descriptionMUST be ≤ 160 characters, action-oriented, unique per page.sidebar.labelMUST be present and ≤ 30 characters.sidebar.orderMUST be set on every page that lives inside a section
with siblings, to enforce the journey order in sidebar.config.ts.- Flag any missing
prev/nextlinks on pages that are clearly
part of a sequential flow (e.g., quickstart → implement-login →
complete-login → manage-session → logout).Voice & Style (CLAUDE.md standards)
- Voice: confident, direct, collaborative, instructional.
- Person: second person only ("you", "your application"). Reject "we",
"our", "the developer", "the user".- Tense: present tense for descriptions; imperative mood for instructions.
- Flag weasel words: "simply", "just", "easy", "straightforward",
"obviously", "of course", "note that".- Flag passive voice constructions where active voice is clearer.
- Headings must be sentence case, not Title Case (except proper nouns).
- No heading should end with a colon or period.
Content structure
- Journey how-to guides MUST contain numbered
<Steps>(Starlight
component). This does NOT apply tosrc/content/docs/cookbooks/**
(blog-style recipes — optional<Steps>,<Tabs>after</Steps>OK;
see cookbookspath_instructions).- Concept pages MUST NOT contain numbered steps — concepts explain, not instruct.
- API reference pages MUST list parameters in a table with Name / Type /
Required / Description columns.- Every page MUST end with a clear "what's next" signal — either a
next:frontmatter link, a<LinkCard>, or an explicit paragraph
pointing the reader forward in the sidebar journey.Code examples
- ALL code examples that show SDK usage MUST include all four language
tabs...
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
**/*.{yml,yaml,md,mdx}
📄 CodeRabbit inference engine (.cursor/rules/browsecentral-labels.mdc)
**/*.{yml,yaml,md,mdx}: BrowseCentral labels should be maximum 3-5 words - keep concise but add context when needed
BrowseCentral labels should be action-oriented - start with verbs when possible
BrowseCentral labels should be specific and clear - add context when simple labels are ambiguous
BrowseCentral labels should be outcome-focused - describe what users accomplish and the context
BrowseCentral labels should use 'Action + Object' pattern (e.g., 'Invite users', 'Restrict sign-up', 'Set up SCIM')
BrowseCentral labels should use feature names (e.g., 'Enterprise SSO', 'Passwordless quickstart')
BrowseCentral labels should describe task completion (e.g., 'Run migrations', 'Migrate auth', 'Merge identities')
BrowseCentral labels should include specific context when needed (e.g., 'Configure Scalekit MCP server', 'Validate incoming API requests')
BrowseCentral labels should use integration context when applicable (e.g., 'Build MCP auth with your existing auth system')
BrowseCentral labels should avoid instructional prefixes: 'How to', 'Guide to', 'Implement', 'Configure', 'Learn', 'Understand'
BrowseCentral labels should avoid verbose phrases: 'Step-by-step guide', 'Complete tutorial', 'Detailed documentation'
BrowseCentral labels should avoid weak verbs: 'Enable', 'Allow', 'Provide', 'Support'
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
**/*.{md,mdx}
📄 CodeRabbit inference engine (.cursor/rules/deno-docs-style.mdc)
**/*.{md,mdx}: Use sentence case for all titles and headings in MD/MDX documentation
Keep page titles short and descriptive (3–7 words when possible) in MD/MDX documentation
Use outcome-focused headings that describe results, not categories (e.g., 'Run a script' not 'Scripts')
Avoid gerunds in headings when an imperative works - prefer 'Configure proxies' over 'Configuring proxies'
Keep sidebar labels concise (1–3 words), use sentence case, and focus on outcomes or objects
Use sentence case in sidebar labels without punctuation
Set frontmatter title in sentence case with a clear outcome; description in one sentence (≤160 chars); sidebar.label as shorter form of title; enable tableOfContents on longer pages
Start documentation pages with a one-paragraph overview explaining what the page covers and when to use it
Present the primary use case (80% path) first in documentation, with edge cases later
Use numbered steps for task-focused sections in documentation, with each step beginning with a verb
Break up long documentation sections with subheadings every 3–6 paragraphs
Use asides for important notes, tips, cautions, and references in documentation
Provide runnable, minimal code examples that work as-is in documentation
Prefer CLI-first examples and show file layout when helpful in documentation
Label code blocks with titles for context (e.g., 'Terminal', 'main.ts') in documentation
Keep code block annotations brief and purposeful - annotate only what matters
Use consistent variable and file names across a documentation page
Use descriptive link text in documentation (e.g., 'See permission flags' not 'click here')
Prefer relative links for internal documentation pages and include anchors for section references
Reference APIs consistently using backticks for code, file names, CLI flags, and endpoints
Use backticks for code, file names, CLI flags, and endpoints in documentation
Use lists for options and features in documentation; tables only when comparisons are cleare...
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
src/content/docs/**/*.mdx
📄 CodeRabbit inference engine (.cursor/rules/starlight-steps-tabs-structure.mdc)
src/content/docs/**/*.mdx: In MDX documentation files,<Steps>must contain one continuous ordered list. Wrap<Steps>around a normal Markdown ordered list such as1. ## ...
In MDX documentation files, numbered step lines must start at column 0. Do not indent the1. ##,2. ##, etc.
In MDX documentation files, any content that belongs to a step must be indented with 3 spaces: paragraphs, bullets, images,<Tabs>,<TabItem>, and fenced code blocks
In MDX documentation files, prefer plain Markdown inside<Steps>. If the content is mostly<Tabs>or other JSX-heavy blocks, use normal section headings instead of<Steps>
In MDX documentation files, when<Tabs>is used inside a step, keep<Tabs>,<TabItem>,</TabItem>, and</Tabs>consistently nested under that step
In MDX documentation files, if a tabs block is not part of a numbered step, place it outside</Steps>
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
**/*.{ts,tsx,py,go,java,mdx,md}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{ts,tsx,py,go,java,mdx,md}: Use the exact SDK variable names: Node.js (scalekit), Python (scalekit_client), Go (scalekitClient), Java (scalekitClient)
Never hard-code secrets or API keys in code examples; use environment variables
Include security comments that state the threat, why the pattern is required, and what can go wrong if omitted
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
**/*.{mdx,md}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{mdx,md}: All code examples must use<Tabs syncKey="tech-stack">format and include Node.js, Python, Go, and Java implementations (90% rule)
Use sentence case for all titles and headings in documentation
Use bold for first mention of important terms, UI elements, and dashboard paths (e.g., Dashboard > Authentication > Session Policy)
Use inline code for technical identifiers: variables, functions, endpoints, scopes, environment variables, file paths, and placeholders
Always include headers in tables; keep cell content concise and readable
Prefer fenced code blocks with language identifiers for all code; never use screenshots of code
Use descriptive link text; never use 'click here' or 'this' as link labels
Keep sentences simple, right-branching, and unambiguous; avoid ambiguous noun stacks and demonstrative pronouns
Use active voice; prefer 'Run the command' over 'The command should be run'
Use second person when giving instructions; address the reader as 'you'
Use present tense for procedures; 'This command installs…' not 'This command will install…'
Avoid hype, slang, and filler words like 'simply', 'just', 'obviously' in documentation
Use consistent terminology throughout; prefer standard names over synonyms
Explain security implications and threats for all security-related content
Use imperative verbs for procedure headings: 'Run a script' not 'Running a script'; 'Configure proxies' not 'Configuring proxies'
Headings must describe outcomes, not categories (good: 'Run a script'; bad: 'Scripts')
Split content into clear sections with descriptive, sentence-style titles that convey meaning without requiring the following paragraph
Keep paragraphs short; isolate critical points in their own short paragraphs
Begin sections and paragraphs with standalone topic sentences that preview content
Put the topic words at the beginning of topic sentences to support fast skimming
Put key takeaways and results at the top of documents and sections
Use bullets and tabl...
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
src/content/docs/**/*.{mdx,md}
📄 CodeRabbit inference engine (CLAUDE.md)
src/content/docs/**/*.{mdx,md}: Every documentation page must include frontmatter with at least:title,description, andsidebar.label
Page titles must be ≤60 characters and descriptions must be ≤160 characters
Sidebar labels must be concise (1-3 words) and use sentence case without punctuation
Use<Steps>component with single continuous ordered list; numbered steps start at column 0, continuation content indented with exactly 3 spaces
Use relative links for internal pages; include anchors for sections
Include a table of contents for documents with multiple sections; enabletableOfContents: truein frontmatter
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
src/content/docs/cookbooks/**/*.mdx
⚙️ CodeRabbit configuration file
src/content/docs/cookbooks/**/*.mdx: This file is a Scalekit cookbook: a standalone recipe under the
starlight-blog integration (prefix: cookbooksin astro.config.mjs).
Apply global MDX voice, style, links, and accessibility rules, but use
these cookbook-specific expectations:Overrides to global MDX checks
- Do NOT require
sidebar.order— ordering follows the blog plugin and
publication metadata, not sidebar.config.ts journey slots.- Do NOT require
prev/nextfrontmatter — cookbooks are not a
sequential product journey; cross-links and related docs are enough.tableOfContentsis optional — enable it when the post has many H2s.Frontmatter
titleanddescriptionfollow the same length and clarity rules as
global MDX.- Prefer
sidebar.labelfor navigation consistency; if absent, do not
treat it as a hard failure (older cookbooks may omit it).date,tags,authors,excerpt, andfeaturedare normal for
cookbooks — verify tags match the topic (e.g. MCP, SSO, FSA).Code examples
- Require all four SDK tabs (Node.js, Python, Go, Java) ONLY when the
snippet demonstrates Scalekit client SDK usage. For MCP setup, CLI,
shell, framework-only (e.g. Next.js), or IDE configuration recipes,
use the tabs or single-language blocks that fit the task. Do not
demand four SDK languages for bash, JSON, env files, or non-SDK code.- Minimal examples (single command, config block) do not need both
success and error paths unless the recipe is explicitly about errors.- Flag real-looking API keys or secrets — use placeholders such as
YOUR_API_KEYorYOUR_CLIENT_SECRET.
<Steps>(overrides global "how-to MUST use Steps")
- Do NOT require
<Steps>on cookbooks. The global rule targets journey
how-to pages; a cookbook may use H2 sections,<Tabs>, or prose.- Do NOT flag "missing Steps" when the procedure is already clear.
- If
<Steps>is used,<Tabs>or other blocks MAY appear after
</Steps>(e.g. per–IDE ...
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
🧠 Learnings (12)
📚 Learning: 2026-01-30T18:18:50.883Z
Learnt from: AkshayParihar33
Repo: scalekit-inc/developer-docs PR: 415
File: src/content/docs/authenticate/fsa/multiapp/manage-apps.mdx:31-49
Timestamp: 2026-01-30T18:18:50.883Z
Learning: In all Scalekit documentation files (MDX), treat the terms 'Applications', 'Single Page Application (SPA)', 'Native Application', and 'Web Application' as proper nouns and preserve their capitalization in headings and body text. Ensure these terms remain capitalized even when used in sentence case or within prose.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-02-04T12:47:16.544Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 412
File: src/content/docs/dev-kit/tools/scalekit-dryrun.mdx:1-23
Timestamp: 2026-02-04T12:47:16.544Z
Learning: In scalekit-inc/developer-docs, the MDX frontmatter field order is required only when the sidebar configuration points to a directory (for auto-generation). If the sidebar.config.ts references a specific file path, the order field is not required. Apply this check to all MDX files under src/content/docs: if a file contributes to an auto-generated sidebar (directory path), ensure order is present; if it’s linked to a concrete file, order can be omitted. Use sidebar.config.ts to determine whether a given MDX file falls under directory-based vs file-specific sidebar references.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-02-25T08:57:12.201Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 444
File: src/content/docs/agent-auth/quickstart.mdx:2-10
Timestamp: 2026-02-25T08:57:12.201Z
Learning: In Scalekit developer-docs (Astro Starlight), do not auto-suggest adding tableOfContents in frontmatter unless the user explicitly overrides the default behavior. The default enables tableOfContents with minHeadingLevel 2 and maxHeadingLevel 3. Only set tableOfContents when you want to customize heading levels or disable it entirely; otherwise omit it for other docs.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-02-25T13:04:27.491Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 444
File: src/content/docs/agent-auth/start-agent-auth-coding-agents.mdx:9-17
Timestamp: 2026-02-25T13:04:27.491Z
Learning: Allow page-level CSS overrides in MDX frontmatter (head: style) for readability and engagement, even if it customizes typography beyond defaults. This applies to per-page UX decisions, including heading sizes and style tweaks, but keep overrides purposeful, accessible, and within the repository's design guidelines. Use these overrides sparingly and document the rationale for maintainability.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-03-05T11:29:08.125Z
Learnt from: AkshayParihar33
Repo: scalekit-inc/developer-docs PR: 463
File: src/content/docs/agent-auth/providers.mdx:35-73
Timestamp: 2026-03-05T11:29:08.125Z
Learning: In src/content/docs/agent-auth/providers.mdx, the Card components intentionally use icon=" " (a space) to render consistent colored boxes since some Starlight icon names resolve to icons and others do not. Do not flag icon=" " as a placeholder issue for this file; treat this as a deliberate UX choice specific to this MDX page and avoid raising a placeholder-icon warning here.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-03-09T07:27:56.794Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 469
File: src/content/docs/guides/integrations/scim-integrations/azure-scim.mdx:95-107
Timestamp: 2026-03-09T07:27:56.794Z
Learning: Do not enforce the 3-space indentation rule for Steps component content as a hard style rule in MDX files under src/content/docs/**/*.mdx. Only flag/rectify it if it causes visible rendering problems in the UI. Otherwise, allow current formatting; apply this rule only when rendering issues are observed and document any fixes.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-03-09T07:32:38.426Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 467
File: src/content/docs/sso/guides/sso-user-attributes.mdx:108-148
Timestamp: 2026-03-09T07:32:38.426Z
Learning: In MDX code samples under src/content/docs (and similar conceptual snippets in scalekit-inc/developer-docs), when an example's sole purpose is to show how to access a specific value (e.g., reading JWT claims after token validation), omit error/non-happy-path handling to keep the snippet focused. Do not flag the absence of error paths in narrowly scoped conceptual snippets.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-03-17T16:01:50.487Z
Learnt from: dhaneshbs
Repo: scalekit-inc/developer-docs PR: 506
File: src/content/docs/authenticate/fsa/quickstart.mdx:851-853
Timestamp: 2026-03-17T16:01:50.487Z
Learning: In the Scalekit Python SDK docs, clarify that LogoutUrlOptions is not exported from the top-level scalekit package __init__.py. The correct import path in code samples or reviews is: from scalekit.common.scalekit import LogoutUrlOptions. Do not flag this import path as incorrect in documentation or code reviews; ensure examples reflect the proper import path to avoid confusion for users.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-02-25T03:34:41.147Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 444
File: src/content/docs/agent-auth/start-agent-auth-coding-agents.mdx:31-31
Timestamp: 2026-02-25T03:34:41.147Z
Learning: In MDX files, import { Code } from 'astrojs/starlight/components' only if the MDX content actually uses the <Code> component. If the file uses only fenced code blocks (```), the import is not required. Apply this guideline to all MDX files (e.g., src/content/docs/**/*.mdx) to avoid unnecessary imports and reduce bundle size.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-02-25T18:41:00.639Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 446
File: src/content/docs/authenticate/m2m/api-auth-quickstart.mdx:78-78
Timestamp: 2026-02-25T18:41:00.639Z
Learning: Preserve full URLs inside code comments in MDX code blocks (bash/python/js) when the URLs are part of copyable examples. Do not flag these in code examples. Use relative paths in prose and hyperlinks within MDX; only enforce relative paths for markdown prose links, not for URLs inside code comments.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-03-26T13:43:49.940Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 539
File: src/content/docs/cookbooks/search-scalekit-docs-in-your-ide.mdx:1-15
Timestamp: 2026-03-26T13:43:49.940Z
Learning: In scalekit-inc/developer-docs, cookbook pages under `src/content/docs/cookbooks/` use directory-based auto-generation for the sidebar (configured in `src/configs/sidebar.config.ts` with routes like `/cookbooks` and `/cookbooks/**/*`). For files in this directory, do not require or flag missing `sidebar.label` in the MDX frontmatter.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-04-25T07:22:18.321Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 633
File: src/components/templates/agent-connectors/_setup-heyreach.mdx:12-12
Timestamp: 2026-04-25T07:22:18.321Z
Learning: In this repo’s MDX documentation files, treat `@/...` paths as aliases that resolve to the `src/` directory (e.g., `@/assets/docs/foo/bar.png` -> `src/assets/docs/foo/bar.png`). When reviewing, do not flag `@`-prefixed image (or other asset) paths as broken; instead, verify that the corresponding physical file exists under `src/`.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
🪛 LanguageTool
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
[style] ~22-~22: Consider using “who” when you are referring to a person instead of an object.
Context: ...omatically. This recipe builds an Actor that connects to Notion per-user and to YouT...
(THAT_WHO)
[uncategorized] ~63-~63: The official name of this popular video platform is spelled with a capital “T”.
Context: ...t. 5. Under Scopes, select at least youtube.readonly. Add youtube if your Actor ...
(YOUTUBE)
[uncategorized] ~63-~63: The official name of this popular video platform is spelled with a capital “T”.
Context: ...select at least youtube.readonly. Add youtube if your Actor needs write access (play...
(YOUTUBE)
🔇 Additional comments (5)
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx (5)
2-2: Title length issue is still unresolved.This remains above the 60-character frontmatter limit and was already called out earlier.
As per coding guidelines: "
titleMUST be ≤ 60 characters and clearly state what the page does."
18-18: Unused MDX component import is still present.
TabItemandTabsare not used in this file, and this was already flagged previously.Based on learnings: "import { Code } ... only if the MDX content actually uses the component" (same import-when-used principle applies here).
73-75: Directive-style caution block issue is already reported.This is the same unresolved admonition-style concern previously flagged.
As per coding guidelines: "Use
<Aside>components with mandatorytitleattribute for notes, tips, cautions, and dangers."
273-275: Missing language tag on URL pattern block is already reported.This matches a prior unresolved comment.
As per coding guidelines: "Always add a language identifier to fenced code blocks."
362-364: Directive-style note block issue is already reported.This is the same unresolved admonition component concern previously flagged.
As per coding guidelines: "Use
<Aside>components with mandatorytitleattribute for notes, tips, cautions, and dangers."
- Add step to set OAuth consent screen to External (not Internal) and add test users — prevents 403 org_internal during authorization - Add corresponding Common mistakes entry for the org_internal error
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx`:
- Line 7: The sidebar.label value ("Apify Actor with per-user OAuth") exceeds
the 30-character limit; update the frontmatter key sidebar.label in
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx to a shorter string
(≤30 chars), e.g., remove "with" to use "Apify Actor per-user OAuth" or another
concise option, ensuring the sidebar.label exists and is no longer than 30
characters.
- Around line 333-335: Replace the directive-style note block with the JSX Aside
component: add an import for Aside at the top of the file (ensure Aside is
available in the component imports) and convert the ":::note[...]" directive
into an <Aside title="Apify web view does not
auto-refresh">...content...</Aside> element containing the same text; keep the
original wording inside the Aside and include the mandatory title attribute to
satisfy the documentation guidelines and accessibility rules.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 31f3869c-c3bf-49ee-be83-0f5fd2d43e84
📒 Files selected for processing (1)
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Redirect rules - scalekit-starlight
- GitHub Check: Header rules - scalekit-starlight
- GitHub Check: Pages changed - scalekit-starlight
🧰 Additional context used
📓 Path-based instructions (8)
**/*.mdx
📄 CodeRabbit inference engine (.cursorrules)
**/*.mdx: Use clear, descriptive titles that explain the purpose of the document
Include comprehensive descriptions in frontmatter metadata
Organize content with logical heading hierarchy (H2, H3, H4)
Use tableOfContents property in frontmatter when content has multiple sections
Set appropriate sidebar labels for navigation in frontmatter
Use direct instruction writing style with phrases like 'This guide shows you how to...' and 'Create an authorization URL to...'
Use second person perspective ('your application', 'you receive', 'you must') in documentation
Keep sentences concise, aiming for under 25 words per sentence
Explain the 'why' in documentation with phrases like 'This prevents CSRF attacks by...' or 'Use this to validate that...'
Use action verbs in section headings: 'Store session tokens securely', 'Validate the state parameter', 'Exchange authorization code for tokens'
Use present tense for descriptions: 'Scalekit handles the complex authentication flow', 'The SDK provides methods to refresh tokens'
Use future tense for results: 'This will redirect users to...', 'You'll receive a JWT containing...', 'Scalekit returns an authorization code'
Use transition phrases between sections: 'After the user authenticates...', 'Once the state is validated...', 'Let's take a look at how to...'
Write 1-3 opening paragraphs that explain what users will accomplish, provide context about when/why, preview key concepts, and use direct instructional language
Begin introduction sections with a clear statement of what the guide covers and explain the problem being solved
Use collapsible sections in introduction for sequence diagrams, video demonstrations, data models, and JSON examples with appropriate icons
Use numbered format within Steps component:1. ## Titlewith all step content indented with exactly 3 spaces
Use action-oriented headings in step-by-step guides within Steps components
Include code examples in all 4 languages (Node.js, Python, Go, Java) within Steps co...
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
⚙️ CodeRabbit configuration file
**/*.mdx: You are reviewing Scalekit developer documentation written in MDX
(Astro + Starlight framework). Apply ALL of the following checks:Frontmatter
titleMUST be ≤ 60 characters and clearly state what the page does.descriptionMUST be ≤ 160 characters, action-oriented, unique per page.sidebar.labelMUST be present and ≤ 30 characters.sidebar.orderMUST be set on every page that lives inside a section
with siblings, to enforce the journey order in sidebar.config.ts.- Flag any missing
prev/nextlinks on pages that are clearly
part of a sequential flow (e.g., quickstart → implement-login →
complete-login → manage-session → logout).Voice & Style (CLAUDE.md standards)
- Voice: confident, direct, collaborative, instructional.
- Person: second person only ("you", "your application"). Reject "we",
"our", "the developer", "the user".- Tense: present tense for descriptions; imperative mood for instructions.
- Flag weasel words: "simply", "just", "easy", "straightforward",
"obviously", "of course", "note that".- Flag passive voice constructions where active voice is clearer.
- Headings must be sentence case, not Title Case (except proper nouns).
- No heading should end with a colon or period.
Content structure
- Journey how-to guides MUST contain numbered
<Steps>(Starlight
component). This does NOT apply tosrc/content/docs/cookbooks/**
(blog-style recipes — optional<Steps>,<Tabs>after</Steps>OK;
see cookbookspath_instructions).- Concept pages MUST NOT contain numbered steps — concepts explain, not instruct.
- API reference pages MUST list parameters in a table with Name / Type /
Required / Description columns.- Every page MUST end with a clear "what's next" signal — either a
next:frontmatter link, a<LinkCard>, or an explicit paragraph
pointing the reader forward in the sidebar journey.Code examples
- ALL code examples that show SDK usage MUST include all four language
tabs...
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
**/*.{yml,yaml,md,mdx}
📄 CodeRabbit inference engine (.cursor/rules/browsecentral-labels.mdc)
**/*.{yml,yaml,md,mdx}: BrowseCentral labels should be maximum 3-5 words - keep concise but add context when needed
BrowseCentral labels should be action-oriented - start with verbs when possible
BrowseCentral labels should be specific and clear - add context when simple labels are ambiguous
BrowseCentral labels should be outcome-focused - describe what users accomplish and the context
BrowseCentral labels should use 'Action + Object' pattern (e.g., 'Invite users', 'Restrict sign-up', 'Set up SCIM')
BrowseCentral labels should use feature names (e.g., 'Enterprise SSO', 'Passwordless quickstart')
BrowseCentral labels should describe task completion (e.g., 'Run migrations', 'Migrate auth', 'Merge identities')
BrowseCentral labels should include specific context when needed (e.g., 'Configure Scalekit MCP server', 'Validate incoming API requests')
BrowseCentral labels should use integration context when applicable (e.g., 'Build MCP auth with your existing auth system')
BrowseCentral labels should avoid instructional prefixes: 'How to', 'Guide to', 'Implement', 'Configure', 'Learn', 'Understand'
BrowseCentral labels should avoid verbose phrases: 'Step-by-step guide', 'Complete tutorial', 'Detailed documentation'
BrowseCentral labels should avoid weak verbs: 'Enable', 'Allow', 'Provide', 'Support'
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
**/*.{md,mdx}
📄 CodeRabbit inference engine (.cursor/rules/deno-docs-style.mdc)
**/*.{md,mdx}: Use sentence case for all titles and headings in MD/MDX documentation
Keep page titles short and descriptive (3–7 words when possible) in MD/MDX documentation
Use outcome-focused headings that describe results, not categories (e.g., 'Run a script' not 'Scripts')
Avoid gerunds in headings when an imperative works - prefer 'Configure proxies' over 'Configuring proxies'
Keep sidebar labels concise (1–3 words), use sentence case, and focus on outcomes or objects
Use sentence case in sidebar labels without punctuation
Set frontmatter title in sentence case with a clear outcome; description in one sentence (≤160 chars); sidebar.label as shorter form of title; enable tableOfContents on longer pages
Start documentation pages with a one-paragraph overview explaining what the page covers and when to use it
Present the primary use case (80% path) first in documentation, with edge cases later
Use numbered steps for task-focused sections in documentation, with each step beginning with a verb
Break up long documentation sections with subheadings every 3–6 paragraphs
Use asides for important notes, tips, cautions, and references in documentation
Provide runnable, minimal code examples that work as-is in documentation
Prefer CLI-first examples and show file layout when helpful in documentation
Label code blocks with titles for context (e.g., 'Terminal', 'main.ts') in documentation
Keep code block annotations brief and purposeful - annotate only what matters
Use consistent variable and file names across a documentation page
Use descriptive link text in documentation (e.g., 'See permission flags' not 'click here')
Prefer relative links for internal documentation pages and include anchors for section references
Reference APIs consistently using backticks for code, file names, CLI flags, and endpoints
Use backticks for code, file names, CLI flags, and endpoints in documentation
Use lists for options and features in documentation; tables only when comparisons are cleare...
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
src/content/docs/**/*.mdx
📄 CodeRabbit inference engine (.cursor/rules/starlight-steps-tabs-structure.mdc)
src/content/docs/**/*.mdx: In MDX documentation files,<Steps>must contain one continuous ordered list. Wrap<Steps>around a normal Markdown ordered list such as1. ## ...
In MDX documentation files, numbered step lines must start at column 0. Do not indent the1. ##,2. ##, etc.
In MDX documentation files, any content that belongs to a step must be indented with 3 spaces: paragraphs, bullets, images,<Tabs>,<TabItem>, and fenced code blocks
In MDX documentation files, prefer plain Markdown inside<Steps>. If the content is mostly<Tabs>or other JSX-heavy blocks, use normal section headings instead of<Steps>
In MDX documentation files, when<Tabs>is used inside a step, keep<Tabs>,<TabItem>,</TabItem>, and</Tabs>consistently nested under that step
In MDX documentation files, if a tabs block is not part of a numbered step, place it outside</Steps>
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
**/*.{ts,tsx,py,go,java,mdx,md}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{ts,tsx,py,go,java,mdx,md}: Use the exact SDK variable names: Node.js (scalekit), Python (scalekit_client), Go (scalekitClient), Java (scalekitClient)
Never hard-code secrets or API keys in code examples; use environment variables
Include security comments that state the threat, why the pattern is required, and what can go wrong if omitted
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
**/*.{mdx,md}
📄 CodeRabbit inference engine (CLAUDE.md)
**/*.{mdx,md}: All code examples must use<Tabs syncKey="tech-stack">format and include Node.js, Python, Go, and Java implementations (90% rule)
Use sentence case for all titles and headings in documentation
Use bold for first mention of important terms, UI elements, and dashboard paths (e.g., Dashboard > Authentication > Session Policy)
Use inline code for technical identifiers: variables, functions, endpoints, scopes, environment variables, file paths, and placeholders
Always include headers in tables; keep cell content concise and readable
Prefer fenced code blocks with language identifiers for all code; never use screenshots of code
Use descriptive link text; never use 'click here' or 'this' as link labels
Keep sentences simple, right-branching, and unambiguous; avoid ambiguous noun stacks and demonstrative pronouns
Use active voice; prefer 'Run the command' over 'The command should be run'
Use second person when giving instructions; address the reader as 'you'
Use present tense for procedures; 'This command installs…' not 'This command will install…'
Avoid hype, slang, and filler words like 'simply', 'just', 'obviously' in documentation
Use consistent terminology throughout; prefer standard names over synonyms
Explain security implications and threats for all security-related content
Use imperative verbs for procedure headings: 'Run a script' not 'Running a script'; 'Configure proxies' not 'Configuring proxies'
Headings must describe outcomes, not categories (good: 'Run a script'; bad: 'Scripts')
Split content into clear sections with descriptive, sentence-style titles that convey meaning without requiring the following paragraph
Keep paragraphs short; isolate critical points in their own short paragraphs
Begin sections and paragraphs with standalone topic sentences that preview content
Put the topic words at the beginning of topic sentences to support fast skimming
Put key takeaways and results at the top of documents and sections
Use bullets and tabl...
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
src/content/docs/**/*.{mdx,md}
📄 CodeRabbit inference engine (CLAUDE.md)
src/content/docs/**/*.{mdx,md}: Every documentation page must include frontmatter with at least:title,description, andsidebar.label
Page titles must be ≤60 characters and descriptions must be ≤160 characters
Sidebar labels must be concise (1-3 words) and use sentence case without punctuation
Use<Steps>component with single continuous ordered list; numbered steps start at column 0, continuation content indented with exactly 3 spaces
Use relative links for internal pages; include anchors for sections
Include a table of contents for documents with multiple sections; enabletableOfContents: truein frontmatter
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
src/content/docs/cookbooks/**/*.mdx
⚙️ CodeRabbit configuration file
src/content/docs/cookbooks/**/*.mdx: This file is a Scalekit cookbook: a standalone recipe under the
starlight-blog integration (prefix: cookbooksin astro.config.mjs).
Apply global MDX voice, style, links, and accessibility rules, but use
these cookbook-specific expectations:Overrides to global MDX checks
- Do NOT require
sidebar.order— ordering follows the blog plugin and
publication metadata, not sidebar.config.ts journey slots.- Do NOT require
prev/nextfrontmatter — cookbooks are not a
sequential product journey; cross-links and related docs are enough.tableOfContentsis optional — enable it when the post has many H2s.Frontmatter
titleanddescriptionfollow the same length and clarity rules as
global MDX.- Prefer
sidebar.labelfor navigation consistency; if absent, do not
treat it as a hard failure (older cookbooks may omit it).date,tags,authors,excerpt, andfeaturedare normal for
cookbooks — verify tags match the topic (e.g. MCP, SSO, FSA).Code examples
- Require all four SDK tabs (Node.js, Python, Go, Java) ONLY when the
snippet demonstrates Scalekit client SDK usage. For MCP setup, CLI,
shell, framework-only (e.g. Next.js), or IDE configuration recipes,
use the tabs or single-language blocks that fit the task. Do not
demand four SDK languages for bash, JSON, env files, or non-SDK code.- Minimal examples (single command, config block) do not need both
success and error paths unless the recipe is explicitly about errors.- Flag real-looking API keys or secrets — use placeholders such as
YOUR_API_KEYorYOUR_CLIENT_SECRET.
<Steps>(overrides global "how-to MUST use Steps")
- Do NOT require
<Steps>on cookbooks. The global rule targets journey
how-to pages; a cookbook may use H2 sections,<Tabs>, or prose.- Do NOT flag "missing Steps" when the procedure is already clear.
- If
<Steps>is used,<Tabs>or other blocks MAY appear after
</Steps>(e.g. per–IDE ...
Files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
🧠 Learnings (12)
📚 Learning: 2026-01-30T18:18:50.883Z
Learnt from: AkshayParihar33
Repo: scalekit-inc/developer-docs PR: 415
File: src/content/docs/authenticate/fsa/multiapp/manage-apps.mdx:31-49
Timestamp: 2026-01-30T18:18:50.883Z
Learning: In all Scalekit documentation files (MDX), treat the terms 'Applications', 'Single Page Application (SPA)', 'Native Application', and 'Web Application' as proper nouns and preserve their capitalization in headings and body text. Ensure these terms remain capitalized even when used in sentence case or within prose.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-02-04T12:47:16.544Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 412
File: src/content/docs/dev-kit/tools/scalekit-dryrun.mdx:1-23
Timestamp: 2026-02-04T12:47:16.544Z
Learning: In scalekit-inc/developer-docs, the MDX frontmatter field order is required only when the sidebar configuration points to a directory (for auto-generation). If the sidebar.config.ts references a specific file path, the order field is not required. Apply this check to all MDX files under src/content/docs: if a file contributes to an auto-generated sidebar (directory path), ensure order is present; if it’s linked to a concrete file, order can be omitted. Use sidebar.config.ts to determine whether a given MDX file falls under directory-based vs file-specific sidebar references.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-02-25T08:57:12.201Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 444
File: src/content/docs/agent-auth/quickstart.mdx:2-10
Timestamp: 2026-02-25T08:57:12.201Z
Learning: In Scalekit developer-docs (Astro Starlight), do not auto-suggest adding tableOfContents in frontmatter unless the user explicitly overrides the default behavior. The default enables tableOfContents with minHeadingLevel 2 and maxHeadingLevel 3. Only set tableOfContents when you want to customize heading levels or disable it entirely; otherwise omit it for other docs.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-02-25T13:04:27.491Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 444
File: src/content/docs/agent-auth/start-agent-auth-coding-agents.mdx:9-17
Timestamp: 2026-02-25T13:04:27.491Z
Learning: Allow page-level CSS overrides in MDX frontmatter (head: style) for readability and engagement, even if it customizes typography beyond defaults. This applies to per-page UX decisions, including heading sizes and style tweaks, but keep overrides purposeful, accessible, and within the repository's design guidelines. Use these overrides sparingly and document the rationale for maintainability.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-03-05T11:29:08.125Z
Learnt from: AkshayParihar33
Repo: scalekit-inc/developer-docs PR: 463
File: src/content/docs/agent-auth/providers.mdx:35-73
Timestamp: 2026-03-05T11:29:08.125Z
Learning: In src/content/docs/agent-auth/providers.mdx, the Card components intentionally use icon=" " (a space) to render consistent colored boxes since some Starlight icon names resolve to icons and others do not. Do not flag icon=" " as a placeholder issue for this file; treat this as a deliberate UX choice specific to this MDX page and avoid raising a placeholder-icon warning here.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-03-09T07:27:56.794Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 469
File: src/content/docs/guides/integrations/scim-integrations/azure-scim.mdx:95-107
Timestamp: 2026-03-09T07:27:56.794Z
Learning: Do not enforce the 3-space indentation rule for Steps component content as a hard style rule in MDX files under src/content/docs/**/*.mdx. Only flag/rectify it if it causes visible rendering problems in the UI. Otherwise, allow current formatting; apply this rule only when rendering issues are observed and document any fixes.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-03-09T07:32:38.426Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 467
File: src/content/docs/sso/guides/sso-user-attributes.mdx:108-148
Timestamp: 2026-03-09T07:32:38.426Z
Learning: In MDX code samples under src/content/docs (and similar conceptual snippets in scalekit-inc/developer-docs), when an example's sole purpose is to show how to access a specific value (e.g., reading JWT claims after token validation), omit error/non-happy-path handling to keep the snippet focused. Do not flag the absence of error paths in narrowly scoped conceptual snippets.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-03-17T16:01:50.487Z
Learnt from: dhaneshbs
Repo: scalekit-inc/developer-docs PR: 506
File: src/content/docs/authenticate/fsa/quickstart.mdx:851-853
Timestamp: 2026-03-17T16:01:50.487Z
Learning: In the Scalekit Python SDK docs, clarify that LogoutUrlOptions is not exported from the top-level scalekit package __init__.py. The correct import path in code samples or reviews is: from scalekit.common.scalekit import LogoutUrlOptions. Do not flag this import path as incorrect in documentation or code reviews; ensure examples reflect the proper import path to avoid confusion for users.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-02-25T03:34:41.147Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 444
File: src/content/docs/agent-auth/start-agent-auth-coding-agents.mdx:31-31
Timestamp: 2026-02-25T03:34:41.147Z
Learning: In MDX files, import { Code } from 'astrojs/starlight/components' only if the MDX content actually uses the <Code> component. If the file uses only fenced code blocks (```), the import is not required. Apply this guideline to all MDX files (e.g., src/content/docs/**/*.mdx) to avoid unnecessary imports and reduce bundle size.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-02-25T18:41:00.639Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 446
File: src/content/docs/authenticate/m2m/api-auth-quickstart.mdx:78-78
Timestamp: 2026-02-25T18:41:00.639Z
Learning: Preserve full URLs inside code comments in MDX code blocks (bash/python/js) when the URLs are part of copyable examples. Do not flag these in code examples. Use relative paths in prose and hyperlinks within MDX; only enforce relative paths for markdown prose links, not for URLs inside code comments.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-03-26T13:43:49.940Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 539
File: src/content/docs/cookbooks/search-scalekit-docs-in-your-ide.mdx:1-15
Timestamp: 2026-03-26T13:43:49.940Z
Learning: In scalekit-inc/developer-docs, cookbook pages under `src/content/docs/cookbooks/` use directory-based auto-generation for the sidebar (configured in `src/configs/sidebar.config.ts` with routes like `/cookbooks` and `/cookbooks/**/*`). For files in this directory, do not require or flag missing `sidebar.label` in the MDX frontmatter.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
📚 Learning: 2026-04-25T07:22:18.321Z
Learnt from: saif-at-scalekit
Repo: scalekit-inc/developer-docs PR: 633
File: src/components/templates/agent-connectors/_setup-heyreach.mdx:12-12
Timestamp: 2026-04-25T07:22:18.321Z
Learning: In this repo’s MDX documentation files, treat `@/...` paths as aliases that resolve to the `src/` directory (e.g., `@/assets/docs/foo/bar.png` -> `src/assets/docs/foo/bar.png`). When reviewing, do not flag `@`-prefixed image (or other asset) paths as broken; instead, verify that the corresponding physical file exists under `src/`.
Applied to files:
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
🪛 LanguageTool
src/content/docs/cookbooks/apify-actor-per-user-oauth.mdx
[style] ~22-~22: Consider using “who” when you are referring to a person instead of an object.
Context: ...omatically. This recipe builds an Actor that connects to Notion per-user and to YouT...
(THAT_WHO)
[uncategorized] ~64-~64: The official name of this popular video platform is spelled with a capital “T”.
Context: ...t. 5. Under Scopes, select at least youtube.readonly. Add youtube if your Actor ...
(YOUTUBE)
[uncategorized] ~64-~64: The official name of this popular video platform is spelled with a capital “T”.
Context: ...select at least youtube.readonly. Add youtube if your Actor needs write access (play...
(YOUTUBE)
- Shorten title to ≤60 chars, description to ≤160 chars, sidebar label to ≤30 chars - Replace unused TabItem/Tabs import with Aside - Add language identifiers to bare code blocks (bash, text) - Convert :::caution and :::note directives to <Aside> components
Summary
notion-youtube-agentactorWhat's in the cookbook
Actor.getEnv().userIdas the Scalekit connected-account identifier; no email field, no manual user inputACTOR_WEB_SERVER_PORT) so users click a button instead of a raw magic linktaskto end users; keep auth and config internal; note thatplaceholderis not a valid Apify schema propertyuserIdundefined locally, stale variable references,placeholderbuild failure, live view URL unavailable in local runsTest plan
/cookbooks/apify-actor-per-user-oauth/agentkit/connectors/,/agentkit/quickstart/) resolve🤖 Generated with Claude Code
Summary by CodeRabbit