Update API specifications with fern api update #3971
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
WalkthroughA new OpenAPI endpoint Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
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. Comment |
![ellipsis-dev[bot]](https://avatars.githubusercontent.com/in/64358?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed everything up to 967d793 in 2 minutes and 4 seconds. Click for details.
- Reviewed
169lines of code in1files - Skipped
0files when reviewing. - Skipped posting
4draft 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:2677
- Draft comment:
Consider using an OpenAPI security scheme for API key authentication rather than defining 'x-api-key' as a header parameter. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% This is a code quality suggestion about OpenAPI best practices. The comment is technically correct - OpenAPI does support security schemes that can be defined once and reused across endpoints. However, I need to consider: 1) Is this obvious or unimportant? 2) Does it require seeing other parts of the codebase to validate? 3) Is it actionable? Looking at the diff, I can only see this one endpoint being added. I cannot see if other endpoints in the file use the same pattern or if there's already a security scheme defined elsewhere in the OpenAPI spec. Without seeing the full file or other endpoints, I cannot determine if this is consistent with the existing pattern or if it's actually an issue. The rules state "Ignore cross-file issues. Only think about the file you are reviewing" and "If you are not sure, or if understanding the comment requires more context (such as seeing other files or parts of the codebase), you should delete the comment." I might be missing that this is a standalone improvement that doesn't require context - it's a valid OpenAPI best practice regardless of what else exists in the file. The suggestion is actionable and clear, which the rules say is good for code quality refactors. While it's a valid best practice, I cannot verify from the diff alone whether this pattern is consistent with the rest of the API specification. If other endpoints use the same inline header parameter pattern, changing just this one would be inconsistent. The comment requires understanding the broader context of the OpenAPI spec to determine if it's the right change, which violates the "requires more context" rule. Delete this comment. While it's technically a valid OpenAPI best practice, determining whether to apply it requires seeing the rest of the OpenAPI specification to understand if there's already a security scheme defined or if other endpoints follow the same pattern. Without this context, I cannot verify if the suggestion is appropriate.
2. fern/openapi/skyvern_openapi.json:2675
- Draft comment:
Redundant description for the 'use-case' query parameter; consider consolidating the description to avoid duplication. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
3. fern/openapi/skyvern_openapi.json:8970
- Draft comment:
Consider adding a maxLength constraint to the 'prompt' field in ImprovePromptRequest to avoid excessively long input. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
4. fern/openapi/skyvern_openapi.json:9747
- Draft comment:
If 'browser_profile_id' is expected to follow a specific format (e.g., a UUID), consider adding a pattern validation. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
Workflow ID: wflow_uK76THUU0Vo0WSEL
You can customize 
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
fern/openapi/skyvern_openapi.json (3)
8970-8996: Strengthen request schema with examples.Add examples to ImprovePromptRequest to improve docs and SDK hints.
"ImprovePromptRequest": { "properties": { "context": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "title": "Context", - "description": "Additional context about the user's needs" + "description": "Additional context about the user's needs", + "examples": ["Audience: CFOs at mid-market SaaS; Tone: concise"] }, "prompt": { "type": "string", "minLength": 1, "title": "Prompt", - "description": "The original prompt to improve" + "description": "The original prompt to improve", + "examples": ["Draft an outreach email requesting a product demo."] } },
8998-9028: Clarify success vs. failure shape; avoid "error" in 200 payload.Returning an "error" field in a 200 response blurs semantics and complicates clients. Prefer 4xx for failures (422 already defined). If you keep an error field, make success/failure mutually exclusive with oneOf.
Simplest: drop "error" from the 200 schema:
"ImprovePromptResponse": { "properties": { - "error": { - "anyOf": [ { "type": "string" }, { "type": "null" } ], - "title": "Error", - "description": "Error message if prompt improvement failed" - }, "improved": { "type": "string", "title": "Improved", "description": "The improved version of the prompt" }, "original": { "type": "string", "title": "Original", "description": "The original prompt provided for improvement" } }, "type": "object", "required": [ "improved", "original" ],
2677-2749: Standardize query param naming and add Fern SDK method identifier.Query parameter
use-caseis the only hyphenated param in the API; all others use snake_case (e.g.,folder_id). Additionally, 23 other endpoints includex-fern-sdk-method-namefor stable SDK method naming—this endpoint is missing it.Apply this diff:
"/v1/prompts/improve": { "post": { "tags": [ "Prompts" ], "summary": "Improve prompt", "description": "Improve a prompt based on a specific use-case", "operationId": "improve_prompt_v1_prompts_improve_post", "parameters": [ { - "name": "use-case", + "name": "use_case", "in": "query", "required": true, "schema": { "type": "string", - "description": "The use-case for prompt improvement", - "title": "Use-Case" + "description": "The use case for prompt improvement", + "title": "Use Case" }, - "description": "The use-case for prompt improvement" + "description": "The use case for prompt improvement" }, { "name": "x-api-key", "in": "header", "required": false, "schema": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "description": "Skyvern API key for authentication. API key can be found at https://app.skyvern.com/settings.", "title": "X-Api-Key" }, "description": "Skyvern API key for authentication. API key can be found at https://app.skyvern.com/settings." } ], "requestBody": { "required": true, "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ImprovePromptRequest" } } } }, "responses": { "200": { "description": "Successful Response", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/ImprovePromptResponse" } } } }, "422": { "description": "Validation Error", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/HTTPValidationError" } } } } }, + "x-fern-sdk-method-name": "improve_prompt" } },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
fern/openapi/skyvern_openapi.json(3 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
🔇 Additional comments (1)
fern/openapi/skyvern_openapi.json (1)
9750-9761: Verify the precedence rules with backend implementation and product specification.The review comment's suggestions for documentation consistency are valid based on codebase patterns:
- Examples are inconsistent:
browser_session_idincludes examples ("examples": ["pbs_123456"]) at line 9735, butbrowser_profile_idat line 9750 omits them, while other ID fields in the schema include them.- Prefix information is missing: Other occurrences of
browser_profile_idin the schema (lines 1799, 1805) document that it "starts withbp_", but the field at line 9750 lacks this detail.- Field coexistence confirmed: All three fields (
browser_session_id,browser_profile_id,browser_address) coexist in the same request schema (lines 9735–9762), validating the question about their interaction.However, the proposed precedence rule ("profile takes precedence and a new session may be created from it") cannot be verified from the OpenAPI schema alone. This requires confirmation against the backend implementation and product specification to ensure accuracy before documenting it as a rule.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Update API specifications by running fern api update.
📋 This PR updates the API specifications by adding a new prompt improvement endpoint and browser profile support. The changes introduce a
/v1/prompts/improveendpoint that allows users to enhance prompts based on specific use-cases, along with corresponding request/response schemas and browser profile configuration options.🔍 Detailed Analysis
Key Changes
/v1/prompts/improvePOST endpoint with use-case query parameter and API key authenticationImprovePromptRequestandImprovePromptResponseschemas for the new endpoint functionalitybrowser_profile_idfield to enable reusing browser profiles for task runsTechnical Implementation
sequenceDiagram participant Client participant API participant PromptService Client->>API: POST /v1/prompts/improve Note over Client,API: Headers: x-api-key<br/>Query: use-case<br/>Body: ImprovePromptRequest API->>PromptService: Process improvement request PromptService->>API: Return improved prompt API->>Client: ImprovePromptResponse Note over API,Client: Contains original, improved,<br/>and optional error fieldsImpact
Created with Palmier
Important
Add new
/v1/prompts/improveendpoint and related schemas toskyvern_openapi.json./v1/prompts/improvewith POST method inskyvern_openapi.json.use-casequery parameter and optionalx-api-keyheader.ImprovePromptRequestschema withcontextandpromptproperties.ImprovePromptResponseschema witherror,improved, andoriginalproperties.browser_profile_idproperty to an existing schema inskyvern_openapi.json.This description was created by
for 967d793. You can customize this summary. It will automatically update as commits are pushed.
Summary by CodeRabbit