Update API specifications with fern api update

[wintonzheng]

Update API specifications by running fern api update.

---

🔄 This PR updates API specifications by running the fern api update command to synchronize the project's API definitions with the latest schema changes. The update ensures that the API documentation and generated code remain consistent with current specifications.

🔍 Detailed Analysis

Key Changes

• API Specification Update: Automated update of API specifications using Fern's tooling
• Schema Synchronization: Ensures API definitions are aligned with the latest requirements
• Documentation Refresh: Updates generated documentation and type definitions

Technical Implementation

flowchart TD
    A[Fern API Update Command] --> B[Parse Current API Specs]
    B --> C[Fetch Latest Schema Changes]
    C --> D[Update API Definitions]
    D --> E[Regenerate Documentation]
    E --> F[Update Type Definitions]
    F --> G[Commit Changes]

Loading

Impact

• API Consistency: Maintains alignment between API specifications and implementation
• Developer Experience: Ensures accurate documentation and type safety for API consumers
• Maintenance Automation: Reduces manual effort in keeping API specs up-to-date

Analysis Limitations

Note: The patch content is empty in the provided information, which limits the ability to analyze specific file changes. This appears to be an automated update that may involve generated files or configuration changes that weren't captured in the patch diff.

Created with Palmier

---

Important

Update API specifications with new TypeScript SDK samples, new action schemas, and refined response handling.

• Code Samples:
  • Add TypeScript SDK code samples for various actions in skyvern_openapi.json.
  • Update existing Python SDK code samples to include more detailed parameters.
• Schema Changes:
  • Introduce new schema components: ClickAction, ExtractAction, InputTextAction, SelectOptionAction.
  • Remove redundant schema definitions for actions and consolidate them.
• Response and Error Handling:
  • Update response descriptions, e.g., change "Successfully executed SDK action" to "Successful Response".
  • Remove some error responses like 403, 404, and 400 from certain endpoints.

^{This description was created by for 57fe233. You can customize this summary. It will automatically update as commits are pushed.}

Summary by CodeRabbit

• New Features

  • Added new SDK action types: Click, Extract, InputText, and SelectOption for enhanced API interaction capabilities.
  • Enhanced API response structure with improved typing and consistency.

• Documentation

  • Expanded code examples with TypeScript SDK samples across multiple endpoints, including task management, workflow operations, and authentication workflows.

[coderabbitai]

Walkthrough

Updated the OpenAPI specification with new TypeScript code samples across multiple endpoints, introduced five new public action schemas (ClickAction, InputTextAction, SelectOptionAction, ExtractAction, ClickContext), and refactored RunSdkActionRequest to use a discriminated union pattern based on action type.

Changes

Cohort / File(s)	Summary
OpenAPI Specification Updates fern/openapi/skyvern_openapi.json	Added TypeScript SDK code samples to multiple endpoints; introduced 5 new public action schemas; refactored RunSdkActionRequest to use discriminated oneOf union with type discriminator; updated RunSdkActionResponse with required workflow_run_id field; restored RunStatus as public enum; added YAML schema variants; updated endpoint descriptions to use generalized success messaging.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20-25 minutes

• Discriminator mapping validation: Verify that the oneOf discriminator on the type field correctly maps to all specified action schemas (ClickAction, InputTextAction, SelectOptionAction, ExtractAction)
• Schema structure coherence: Confirm that RunSdkActionRequest and RunSdkActionResponse properly enforce required fields and types
• OpenAPI specification correctness: Ensure all YAML variants align with JSON definitions and that endpoint examples are properly formatted
• TypeScript sample consistency: Validate that all added TS samples follow the correct SDK pattern and mirror Python equivalents where applicable

Possibly related PRs

• Fern: add TypeScript code examples #3839: Adds TypeScript code samples to OpenAPI examples, extending single-language examples to include both Python and TS variants
• Fern: generated SDK post processing  #3840: Modifies SDK action type surface, introducing new ActionType variants that complement the concrete action schemas added in this PR
• Update API specifications with fern api update #3651: Updates action-related schemas in the OpenAPI specification, providing context for prior action modeling iterations

Suggested reviewers

• suchintan
• pedrohsdb
• jomido

Poem

🐰 TypeScript hops into the fern,
New action schemas we discern—
Click, Input, Extract unite,
Discriminated unions shining bright!
YAML twins now harmonize,
SDK examples on the rise! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title is vague and generic, using non-descriptive language like 'fern api update' that doesn't clearly convey the specific changes made to the API specification.	Consider using a more descriptive title that highlights the main changes, such as 'Add TypeScript SDK examples and discriminated union for SDK actions' or similar to clarify the primary modifications.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch update-openapi-spec-2025-11-05T00-32-30-765Z

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 57fe233 in 3 minutes and 44 seconds. Click for details.

• Reviewed 1104 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 19 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. fern/openapi/skyvern_openapi.json:92

• Draft comment:
  New TypeScript code sample for runTask added. Verify that the method name and parameter shape (i.e. using { body: { prompt: ... } }) match backend expectations.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to verify that the method name and parameter shape match backend expectations. This falls under asking the author to confirm their intention or to double-check things, which is against the rules.

2. fern/openapi/skyvern_openapi.json:214

• Draft comment:
  TypeScript code samples for runWorkflow, getRun, cancelRun, createWorkflow, etc. have been added consistently. Confirm that the camelCase method names (runWorkflow, getRun, etc.) align with backend implementation.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

3. fern/openapi/skyvern_openapi.json:2275

• Draft comment:
  The x-user-agent header parameter has been removed from the parameters list. Confirm that this is intentional and that no client depends on it.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

4. fern/openapi/skyvern_openapi.json:2314

• Draft comment:
  Error response definitions (403, 404, 400) have been removed. Confirm that this change aligns with the intended API error handling and that clients won’t rely on these documented responses.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

5. fern/openapi/skyvern_openapi.json:2778

• Draft comment:
  A new 'click_context' property has been added. Verify that the provided schema in ClickContext fully captures the additional context needed for click actions.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

6. fern/openapi/skyvern_openapi.json:4407

• Draft comment:
  New ClickAction schema added with a default timeout of 10000ms. Note that previous versions used 30000ms; confirm that this lower default is intentional.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

7. fern/openapi/skyvern_openapi.json:5197

• Draft comment:
  Added new ExtractAction schema. Check that the anyOf definitions for extract_schema and error_code_mapping cover all expected data types.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

8. fern/openapi/skyvern_openapi.json:7913

• Draft comment:
  Introduced a new InputTextAction schema and updated the LoginBlock schema. Confirm that the separation between text input actions and login-related actions is clear and that field names (e.g., 'selector', 'value') are consistent.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to confirm the separation and consistency of field names in the new schema. This falls under asking the author to confirm their intention or to ensure the behavior is intended, which is against the rules.

9. fern/openapi/skyvern_openapi.json:9743

• Draft comment:
  The SdkAction reference in RunSdkActionRequest has been updated to use a oneOf with a discriminator. Ensure that client code generators support this new structure for action typing.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% This comment is asking the PR author to ensure that client code generators support the new structure, which violates the rule against asking the author to ensure compatibility or test changes. It does not provide a specific suggestion or point out a specific issue with the code.

10. fern/openapi/skyvern_openapi.json:9382

• Draft comment:
  A large block of duplicate legacy schema definitions has been removed. Verify that removal of these older definitions (e.g., extra RunStatus, ClickAction, etc.) does not break backward compatibility for existing integrations.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

11. fern/openapi/skyvern_openapi.json:9783

• Draft comment:
  The 'result' property in RunSdkActionResponse now uses a permissive schema (empty object plus null). Confirm that downstream consumers can properly handle this dynamic typing.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to confirm that downstream consumers can handle the change in schema. This violates the rule against asking the author to confirm their intention or ensure behavior is intended. The comment does not provide a specific code suggestion or ask for a specific test to be written.

12. fern/openapi/skyvern_openapi.json:9970

• Draft comment:
  New SelectOptionAction schema added. Check that its default timeout and field names are consistent with other action schemas (e.g., ClickAction, InputTextAction).
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

13. fern/openapi/skyvern_openapi.json:1804

• Draft comment:
  Multiple TypeScript login examples have been added for different credential types (skyvern, bitwarden, onepassword). Ensure that all required parameters for each credential type are clearly documented and match backend requirements.
• Reason this comment was not posted:
  Comment did not seem useful. Confidence is useful = 0% <= threshold 50% The comment is asking the PR author to ensure that all required parameters for each credential type are clearly documented and match backend requirements. This falls under the category of asking the author to double-check things, which is against the rules.

14. fern/openapi/skyvern_openapi.json:1548

• Draft comment:
  Two TypeScript examples for createCredential have been added (one for a password and one for a credit card). Confirm that these examples accurately reflect the endpoint’s requirements and that naming differences (e.g., 'My Credential' vs. 'My Credit Card') are intentional.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

15. fern/openapi/skyvern_openapi.json:473

• Draft comment:
  Typographical note (Python block): In the "Extract_Email" block, the value for "data_extraction_goal" ends with an extra space ("Extract a company email if available "). Please remove the trailing whitespace.
• Reason this comment was not posted:
  Comment was on unchanged code.

16. fern/openapi/skyvern_openapi.json:477

• Draft comment:
  Typographical note (TypeScript block): In the "Extract_Email" block, the value for "data_extraction_goal" ends with an extra space ("Extract a company email if available "). Please remove the trailing whitespace.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment is about a trailing whitespace in a newly added TypeScript code example. This is a code quality issue pointing out unnecessary whitespace. However, I need to consider: 1) Is this about unchanged code? No, the TypeScript example is new. 2) Is this actionable? Yes, removing trailing whitespace is clear. 3) Is this important? It's a minor formatting issue in example code. 4) Looking more carefully, the trailing space also exists in the Python example that was already there (line 471 in the context), so this might be intentionally matching the Python version. The comment is technically correct but very minor - it's about whitespace in documentation/example code, not functional code. This is a very minor formatting issue in example code documentation. The trailing space might be intentional to match the existing Python example. Also, this falls into the category of "obvious or unimportant" comments - a trailing space in a string literal in example code is unlikely to cause any real issues. The comment is technically correct but may not be worth the PR author's time. While the trailing space might be intentional for consistency with Python, it's still a quality issue. However, given the rules that comments should not be "obvious or unimportant," and this is just whitespace in example documentation code (not production code), this comment is likely too minor to be useful. The PR author is adding TypeScript examples, and nitpicking about trailing spaces in string literals is not a valuable use of review time. This comment should be deleted. It's pointing out a trailing space in example documentation code, which falls under "obvious or unimportant" comments. While technically correct, it's too minor to warrant the PR author's attention, especially since the same trailing space exists in the Python example.

17. fern/openapi/skyvern_openapi.json:714

• Draft comment:
  Typo: In the 'data_extraction_goal' field of the 'Extract_Email' block (in both the Python and TypeScript examples), there is a trailing whitespace at the end of the description string. Please remove the extra space.
• Reason this comment was not posted:
  Comment was on unchanged code.

18. fern/openapi/skyvern_openapi.json:7974

• Draft comment:
  Typographical inconsistency: The title for 'totp_identifier' is written as 'Totp Identifier' while the description uses 'TOTP identifier'. Please consider standardizing the capitalization (e.g. 'TOTP Identifier').
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a very minor stylistic issue about capitalization consistency. While technically correct that there's an inconsistency, this type of comment falls under "obvious or unimportant" issues. The comment is about a very minor formatting detail that doesn't affect functionality. It's also not clear from the diff whether this inconsistency was introduced in this PR or already existed. Looking at the diff, I don't see the actual change to the "totp_identifier" field - it appears to be existing code, not something that was changed in this PR. The rules state I should only comment on changes made by the diff, and I should not make comments that are obvious or unimportant. I might be missing context about whether this field was actually modified in this PR. However, looking carefully at the diff markers, the totp_identifier field appears to be in unchanged sections of the schema. The actual changes in the diff are primarily adding TypeScript code examples and some schema modifications, but I don't see this specific field being changed. Even if this field was changed, this is an extremely minor stylistic issue about capitalization that falls under "obvious or unimportant" comments. Additionally, the field appears to be in unchanged code based on the diff markers, which means the comment violates the rule about only commenting on changes made by the diff. This comment should be deleted because it appears to be about unchanged code (the totp_identifier field doesn't show as being modified in the diff), and even if it were changed, it's too minor and stylistic to warrant a PR comment.

19. fern/openapi/skyvern_openapi.json:7977

• Draft comment:
  Typographical inconsistency: The title for 'totp_url' is written as 'Totp Url' with mixed capitalization, whereas the description uses 'TOTP URL'. It would be clearer to standardize this (e.g. 'TOTP URL').
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a comment about code quality and consistency in an OpenAPI schema definition. The comment is technically correct - there is an inconsistency between the title and description capitalization. However, I need to consider: 1) Is this about changed code? Looking at the diff, the InputTextAction schema appears to be modified/added in this PR. 2) Is this obvious or unimportant? This is a very minor stylistic issue about capitalization in a title field. 3) Does it require a code change? Yes, but it's extremely minor. The rules state "Do NOT make comments that are obvious or unimportant" and this seems to fall into that category - it's a very minor stylistic inconsistency that doesn't affect functionality. While consistency is good, this is an extremely minor stylistic issue in metadata (a title field). It doesn't affect API functionality or behavior. The comment might be considered too pedantic for a PR review, especially since both forms are understandable and the inconsistency is very minor. Even though it's minor, consistency in documentation and schema definitions is valuable for professional API specifications. However, given the rules explicitly state not to make obvious or unimportant comments, and this is purely cosmetic with no functional impact, it likely falls below the threshold for keeping. This comment should be deleted. While technically correct, it's an unimportant stylistic issue about capitalization in a title field that has no functional impact. The rules explicitly state not to make obvious or unimportant comments, and this falls into that category.

Workflow ID: wflow_WoIieR9usVEo6Dib

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[coderabbitai]

Actionable comments posted: 4

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (3)

fern/openapi/skyvern_openapi.json (3)

1958-1961: Python login sample: fix stray parenthesis/comma (syntax error).

The example has an extra ), then ), which breaks Python. Replace with a single closing ).

Suggested corrected snippet:

# Login with password saved in Skyvern
from skyvern import Skyvern

skyvern = Skyvern(api_key="YOUR_API_KEY")
await skyvern.login(
    url="https://example.com",
    credential_type="skyvern",
    credential_id="cred_123",
)

---

4867-4874: Proxy locations in description are out of sync with enum.

ProxyLocation enum includes RESIDENTIAL_BR, RESIDENTIAL_TR, RESIDENTIAL_CA, RESIDENTIAL_MX, RESIDENTIAL_IT, RESIDENTIAL_NL (Lines 9652-9681) but they’re missing here.

Update the description list to include the new locations to avoid user confusion and mismatched docs. Repeat the same fix in TaskRunRequest (Lines 11020-11033) and WorkflowRunRequest (Lines 14458-14469).

---

1566-1574: Fix incorrect enum casing in CreateCredential example (line 1568).

The example at line 1568 uses "credential_type": "PASSWORD" (uppercase), but the CredentialType enum (lines 5191–5193) defines valid values as lowercase: "password" and "credit_card". All code examples throughout the file correctly use lowercase values.

Change line 1568 from "credential_type": "PASSWORD" to "credential_type": "password".

🧹 Nitpick comments (3)

fern/openapi/skyvern_openapi.json (3)

9773-9796: RunSdkActionResponse.result typed as “any” via {}; consider explicit union for better SDKs.

anyOf: [ {}, { "type": "null" } ] effectively yields any (nullable), which degrades client typings.

Prefer a clearer union to improve generated SDK types:

- "result": { "anyOf": [ {}, { "type": "null" } ], "title": "Result", ... }
+ "result": {
+   "oneOf": [
+     { "type": "object", "additionalProperties": true },
+     { "type": "array", "items": {} },
+     { "type": "string" },
+     { "type": "number" },
+     { "type": "boolean" },
+     { "type": "null" }
+   ],
+   "title": "Result",
+   "description": "The result from the action (e.g., selector, value, extracted data)"
+ }

Optionally, return an action‑specific result discriminated by the action type for maximum clarity.

---

4498-4518: Timeout fields use number; prefer integer milliseconds for consistency.

Actions define timeouts as number with millisecond semantics. Many other timeouts in the spec are integers.

Change type to "integer" for timeout fields across action schemas to align with other endpoints and reduce float ambiguity.

Also applies to: 7990-7994, 10016-10020

---

1516-1521: Minor: samples embed realistic PII; ensure placeholders where needed.

john.doe@example.com is fine, but consider using clearly fake placeholders consistently across samples (e.g., user@example.com, +15555550123) to avoid accidental copy/paste to production.

Replace with more generic placeholders where appropriate.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 8288c97 and 57fe233.

📒 Files selected for processing (1)

• fern/openapi/skyvern_openapi.json (30 hunks)

⏰ 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). (1)

• GitHub Check: Run tests and pre-commit hooks

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

credential_type value should be "1password", not "onepassword".

Enum skyvern__schemas__run_blocks__CredentialType allows "1password". The Python and TypeScript examples use "onepassword", which will fail validation.

Apply change in both examples:

• Python: credential_type="1password"
• TypeScript: credential_type: "1password"

Also applies to: 1978-1980

---

🏁 Script executed:

#!/bin/bash
# Find invalid occurrences to update
rg -n '"credential_type"[^"\n]*"onepassword"|credential_type:\s*"onepassword"' fern/openapi/skyvern_openapi.json -C2

Length of output: 0

---

🏁 Script executed:

#!/bin/bash
# Check if file exists and examine lines 1966-1968 and 1978-1980
echo "=== Lines 1966-1968 ==="
sed -n '1966,1968p' fern/openapi/skyvern_openapi.json

echo ""
echo "=== Lines 1978-1980 ==="
sed -n '1978,1980p' fern/openapi/skyvern_openapi.json

echo ""
echo "=== All occurrences of 'onepassword' ==="
rg -n "onepassword" fern/openapi/skyvern_openapi.json

echo ""
echo "=== All occurrences of '1password' ==="
rg -n "1password" fern/openapi/skyvern_openapi.json

Length of output: 3592

---

🏁 Script executed:

#!/bin/bash
# Examine line 14966 and surrounding context
echo "=== Context around line 14966 ==="
sed -n '14960,14975p' fern/openapi/skyvern_openapi.json

echo ""
echo "=== Search for CredentialType enum/schema definition ==="
rg -n "CredentialType|\"enum\"|\"const\":" fern/openapi/skyvern_openapi.json | grep -A5 -B5 "credential" | head -40

Length of output: 2042

---

Change credential_type value from "onepassword" to "1password" in both code examples.

The CredentialType enum (defined at line 14961) only accepts: "skyvern", "bitwarden", "1password", "azure_vault". Both the Python and TypeScript examples currently use the invalid value "onepassword" and must be corrected to "1password".

• Python example: credential_type="1password"
• TypeScript example: credential_type: "1password"

🤖 Prompt for AI Agents

In fern/openapi/skyvern_openapi.json around lines 1966 to 1968, the code
examples use an invalid credential_type value "onepassword"; update both
examples so the credential_type is "1password" (change the Python example to
credential_type="1password" and the TypeScript example to credential_type:
"1password") to match the CredentialType enum.

[coderabbitai]

🛠️ Refactor suggestion | 🟠 Major

ClickAction: require selector or intention (or both).

As defined, a ClickAction can be sent with neither, making it under‑specified.

Add validation:

 "ClickAction": {
   "type": "object",
   "properties": { ... },
+  "anyOf": [
+    { "required": ["selector"] },
+    { "required": ["intention"] }
+  ],
   "title": "ClickAction",
   "description": "Click action parameters."
 }

Also consider aligning selector typing with InputTextAction (allow null) or standardize across actions.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	"properties": {
	"type": {
	"type": "string",
	"const": "ai_click",
	"title": "Type",
	"default": "ai_click"
	},
	"selector": {
	"type": "string",
	"title": "Selector",
	"description": "CSS selector for the element",
	"default": ""
	},
	"intention": {
	"type": "string",
	"title": "Intention",
	"description": "The intention or goal of the click",
	"default": ""
	},
	"data": {
	"anyOf": [
	{
	"type": "string"
	},
	{
	"additionalProperties": true,
	"type": "object"
	},
	{
	"type": "null"
	}
	],
	"title": "Data",
	"description": "Additional context data"
	},
	"timeout": {
	"type": "number",
	"title": "Timeout",
	"description": "Timeout in milliseconds",
	"default": 10000
	}
	},
	"type": "object",
	"title": "ClickAction",
	"description": "Click action parameters."
	},
	"properties": {
	"type": {
	"type": "string",
	"const": "ai_click",
	"title": "Type",
	"default": "ai_click"
	},
	"selector": {
	"type": "string",
	"title": "Selector",
	"description": "CSS selector for the element",
	"default": ""
	},
	"intention": {
	"type": "string",
	"title": "Intention",
	"description": "The intention or goal of the click",
	"default": ""
	},
	"data": {
	"anyOf": [
	{
	"type": "string"
	},
	{
	"additionalProperties": true,
	"type": "object"
	},
	{
	"type": "null"
	}
	],
	"title": "Data",
	"description": "Additional context data"
	},
	"timeout": {
	"type": "number",
	"title": "Timeout",
	"description": "Timeout in milliseconds",
	"default": 10000
	}
	},
	"anyOf": [
	{ "required": ["selector"] },
	{ "required": ["intention"] }
	],
	"type": "object",
	"title": "ClickAction",
	"description": "Click action parameters."
	},

🤖 Prompt for AI Agents

In fern/openapi/skyvern_openapi.json around lines 4478-4523 the ClickAction
schema currently allows both selector and intention to be omitted; add a
schema-level constraint so at least one of selector or intention must be present
(use anyOf with required arrays for ["selector"] and ["intention"] or anyOf +
required combinations) and update selector's type to match InputTextAction
(e.g., allow null in addition to string) or otherwise standardize selector
typing across action schemas; ensure the new anyOf/oneOf constraint is placed at
the same object level as "properties" so validation enforces the presence of at
least one field.

[coderabbitai]

🛠️ Refactor suggestion | 🟠 Major

InputTextAction: add minimum field requirements and align selector typing.

Currently neither selector nor intention is required.

• Add anyOf requiring at least one of selector or intention.
• Keep selector as string | null if intended; otherwise standardize to string to match ClickAction.

Example:

 "InputTextAction": {
   "type": "object",
   "properties": { ... },
+  "anyOf": [
+    { "required": ["selector"] },
+    { "required": ["intention"] }
+  ],
   "title": "InputTextAction",
   "description": "Input text action parameters."
 }

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In fern/openapi/skyvern_openapi.json around lines 7917-7999, InputTextAction
currently neither requires selector nor intention and selector is typed as
string|null; update the schema so at least one of selector or intention must be
present by adding an anyOf at the object level that requires either a non-empty
selector or an intention, and standardize selector to a plain string (remove the
null variant) to match ClickAction; ensure selector retains its
title/description/default and intention stays as a requiredable string, and
adjust examples/tests if they relied on selector being nullable.

[coderabbitai]

🛠️ Refactor suggestion | 🟠 Major

SelectOptionAction: enforce presence of selector or intention.

Same under‑specification as above.

Add:

 "SelectOptionAction": {
   "type": "object",
   "properties": { ... },
+  "anyOf": [
+    { "required": ["selector"] },
+    { "required": ["intention"] }
+  ],
   "title": "SelectOptionAction",
   "description": "Select option action parameters."
 }

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In fern/openapi/skyvern_openapi.json around lines 9974 to 10025, the
SelectOptionAction schema currently allows both "selector" and "intention" to be
omitted; update the schema to enforce that at least one of them is present by
adding an anyOf (or oneOf) constraint that requires either "selector" or
"intention" (i.e., include clauses like { "required": ["selector"] } and {
"required": ["intention"] }); ensure the constraint sits alongside existing
properties so the validator requires one of these fields when validating
SelectOptionAction.