packages/backend/src/api/resources/OAuthApplication.ts (1)

90-90: Add explicit return type to public static factory

Project guidelines require explicit return types for public APIs.

-static fromJSON(data: OAuthApplicationJSON) {
+static fromJSON(data: OAuthApplicationJSON): OAuthApplication {

packages/backend/src/api/resources/JSON.ts (1)

323-327: Add TSDoc for the newly added OAuthApplicationJSON fields

These types are exported and part of the public API surface. Adding brief comments will improve generated docs and keep parity with the class docs added in OAuthApplication.ts.

Apply something along these lines:

   client_id: string;
-  client_uri: string | null;
-  client_image_url: string | null;
-  dynamically_registered: boolean;
-  consent_screen_enabled: boolean;
-  pkce_required: boolean;
+  /** The public-facing URL of the OAuth application, often shown on consent screens. */
+  client_uri: string | null;
+  /** URL to the application's icon/logo. */
+  client_image_url: string | null;
+  /** Whether this application was created via dynamic client registration (RFC 7591). */
+  dynamically_registered: boolean;
+  /** Whether a consent screen is shown in the auth flow. Cannot be disabled for dynamically registered apps. */
+  consent_screen_enabled: boolean;
+  /** Whether PKCE is required for this application. */
+  pkce_required: boolean;

packages/backend/src/api/resources/OAuthApplication.ts (5)

3-5: Good addition of the class-level docs

Nice, concise overview. Consider linking to the BAPI reference for discoverability.

Example tweak:

 /**
- * The Backend `OAuthApplication` object holds information about an OAuth application.
+ * The Backend `OAuthApplication` object holds information about an OAuth application.
+ * See: https://clerk.com/docs/reference/backend-api/tag/oauth-applications
 */

---

16-18: Remove “new” from property descriptions

These properties describe an OAuth application resource in any state, not just right after creation. The “new” qualifier is misleading.

- * The name of the new OAuth application.
+ * The name of the OAuth application.
@@
- * Scopes for the new OAuth application.
+ * Scopes configured for the OAuth application.
@@
- * An array of redirect URIs of the new OAuth application.
+ * The list of redirect URIs configured for the OAuth application.

Also applies to: 48-51, 52-55

---

44-47: Clarify relationship between public clients and PKCE

The current text suggests PKCE can be used if the client is public, which is true but underspecified given the new pkceRequired flag. Tighten the language to avoid confusion.

- * Indicates whether the client is public. If true, the Proof Key of Code Exchange (PKCE) flow can be used.
+ * Indicates whether the client is public (cannot safely keep a client secret).
+ * Public clients must use PKCE; confidential clients may also use PKCE.

---

96-101: Defensive defaults for newly added fields (back-compat with older backends)

If any existing installations don’t yet return these properties, the runtime values would be undefined. Default them to safe values.

-      data.client_uri,
-      data.client_image_url,
-      data.dynamically_registered,
-      data.consent_screen_enabled,
-      data.pkce_required,
+      data.client_uri ?? null,
+      data.client_image_url ?? null,
+      data.dynamically_registered ?? false,
+      data.consent_screen_enabled ?? false,
+      data.pkce_required ?? false,

If the BAPI guarantees they’re always present, keeping the current mapping is fine. Otherwise, these defaults prevent undefined from leaking into the public API at runtime.

---

90-113: Add unit tests for JSON mapping of new fields

No tests in this PR. Add a test that feeds an OAuthApplicationJSON with the new fields and asserts the resulting instance properties, plus a test where the new fields are omitted (if you adopt defensive defaults).

I can scaffold a Jest test like:

• constructs a minimal OAuthApplicationJSON,
• calls OAuthApplication.fromJSON,
• asserts clientUri/clientImageUrl/dynamicallyRegistered/consentScreenEnabled/pkceRequired mapping.
  Would you like me to draft it?

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.