Skip to content

docs(consumer-apis): Add Open API specification for consumer api endpoints#1105

Open
kalpadhwaryu wants to merge 2 commits intomainfrom
consumer-OpenApiSpec
Open

docs(consumer-apis): Add Open API specification for consumer api endpoints#1105
kalpadhwaryu wants to merge 2 commits intomainfrom
consumer-OpenApiSpec

Conversation

@kalpadhwaryu
Copy link
Contributor

@kalpadhwaryu kalpadhwaryu commented Oct 14, 2025

Description

Add Open API specification for consumer api endpoints.

Summary by CodeRabbit

  • Documentation
    • Added a comprehensive OpenAPI 3.1 specification for consumer-facing APIs.
    • Documents /api/consumer endpoints with API key authentication.
    • Covers Agents (create/update/delete), Chat (send messages, streaming and non‑streaming, stop, history), and Collections (create/list/search, file uploads, item deletion).
    • Specifies detailed request/response schemas, status codes, pagination metadata, and unified error/ok responses.

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @kalpadhwaryu, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a new OpenAPI 3.1 specification document for the consumer-facing API endpoints. This specification provides a comprehensive and machine-readable description of all available endpoints, their request/response structures, security requirements, and error handling. Its purpose is to enhance API discoverability, facilitate client development, and improve documentation for external consumers interacting with the platform's agent, chat, and knowledge base functionalities.

Highlights

  • New OpenAPI Specification: A comprehensive OpenAPI 3.1 specification has been added for all consumer-facing API endpoints, providing a machine-readable and human-friendly description of the API surface.
  • Agent Management Endpoints: The specification includes detailed definitions for Agent-related operations, such as creating, updating, deleting agents, and handling chat interactions with them, including stopping streaming chats.
  • Chat and Collection APIs: Endpoints for managing chat history and Knowledge Base (KB) collections are now fully documented. This includes creating, listing, searching, and deleting collections, as well as uploading and deleting items within collections.
  • Standardized Responses and Security: The specification defines common error responses (e.g., BadRequest, Unauthorized, NotFound) and explicitly states that all consumer API endpoints require an API key for authentication.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 14, 2025

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

Walkthrough

Adds a new OpenAPI 3.1 specification file describing consumer-facing endpoints under /api/consumer with ApiKeyAuth, covering Agents (CRUD), chat (streaming via SSE and non‑streaming), chat stop/history, Collections (create/list/search), file uploads, and detailed schemas and responses (200/201/202/4xx/5xx).

Changes

Cohort / File(s) Summary
OpenAPI spec (consumer API)
docs/consumer-api-keys/open_api_spec.yml
Adds a full OpenAPI 3.1 specification defining the consumer API surface: ApiKeyAuth security, Agent endpoints (create/update/delete, chat, stop, history), chat streaming (SSE) and non‑streaming responses, Collections/KB endpoints (create/list/search), file upload endpoints (multipart), standardized response/error schemas, and comprehensive component schemas and pagination models.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant C as Client
  participant API as Consumer API (/api/consumer)
  participant AG as Agent Runtime
  note over API: Secured via ApiKeyAuth

  rect rgba(220,235,255,0.4)
  C->>API: POST /agents/{id}/chat (non-streaming)
  API->>AG: Deliver message payload
  AG-->>API: AgentChatResponse (200)
  API-->>C: 200 AgentChatResponse
  end

  rect rgba(220,255,220,0.4)
  C->>API: POST /agents/{id}/chat?stream=true (SSE)
  API-->>C: 200 text/event-stream (open)
  API->>AG: Start streaming session
  loop streaming
    AG-->>API: delta/event
    API-->>C: SSE event
  end
  API-->>C: SSE event: done
  end

  opt Stop
    C->>API: POST /agents/{id}/chat/stop
    API->>AG: Terminate session
    AG-->>API: ChatStop (202)
    API-->>C: 202 ChatStop
  end
Loading
sequenceDiagram
  autonumber
  participant C as Client
  participant API as Consumer API (/api/consumer)
  participant COL as Collections Service

  rect rgba(255,245,220,0.6)
  C->>API: POST /collections (CreateCollection)
  API->>COL: Create collection record
  COL-->>API: Collection (201)
  API-->>C: 201 Collection
  end

  rect rgba(240,240,255,0.6)
  C->>API: POST /collections/{id}/items/upload (multipart)
  API->>COL: Store files, index items
  COL-->>API: UploadAccepted (202) + item metadata
  API-->>C: 202 UploadAccepted
  end

  C->>API: GET /collections/{id}/search?query=...
  API->>COL: Execute search
  COL-->>API: SearchResults (200)
  API-->>C: 200 SearchResults (paginated)
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

I hop through specs with whiskers bright,
Keys and streams that twinkle light.
Chats that flow and files that stay,
Collections gardened, indexed, play.
A rabbit’s nibble on routes anew—🥕✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check ✅ Passed The title succinctly and accurately describes the primary change of adding an OpenAPI specification for consumer API endpoints, aligns with the file-level and PR objectives, and uses clear, concise phrasing without unnecessary detail.
Docstring Coverage ✅ Passed No functions found in the changes. Docstring coverage check skipped.
✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch consumer-OpenApiSpec

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 57940b5 and 65b379a.

📒 Files selected for processing (1)
  • docs/consumer-api-keys/open_api_spec.yml (1 hunks)
🧰 Additional context used
🪛 Checkov (3.2.334)
docs/consumer-api-keys/open_api_spec.yml

[medium] 282-286: Ensure that arrays have a maximum number of items

(CKV_OPENAPI_21)


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

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

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request introduces an OpenAPI specification for the consumer-facing API endpoints. The specification is well-structured and comprehensive. My review focuses on improving consistency, adhering to OpenAPI 3.1 best practices, and tightening the schema definitions for a more robust API contract. Key suggestions include standardizing HTTP status codes for DELETE operations, using correct data types for parameters and properties, avoiding the exposure of internal error details, and making schemas stricter by disallowing additional properties where appropriate.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Nitpick comments (9)
docs/consumer-api-keys/open_api_spec.yml (9)

260-273: Use boolean types for query flags (ownOnly, includeItems).

These are flags; modelling as strings invites misuse.

-        - name: ownOnly
+        - name: ownOnly
           in: query
           required: false
           schema:
-            type: string
-          description: If present, filter to collections owned by the caller (string flag)
+            type: boolean
+          description: Filter to collections owned by the caller
-        - name: includeItems
+        - name: includeItems
           in: query
           required: false
           schema:
-            type: string
-          description: If present, include items in response (string flag)
+            type: boolean
+          description: Include items in response

190-197: page should be integer; description mentions string.

Paginated index should be numeric.

-        - name: page
+        - name: page
           in: query
           required: false
           schema:
-            type: string
-            default: "0"
-          description: Zero-based page index (as string)
+            type: integer
+            minimum: 0
+            default: 0
+          description: Zero-based page index

Also consider returning pagination metadata rather than a raw array (see separate comment below).


182-216: Chat history returns a raw array but advertises paging.

Endpoint accepts page yet response schema is a plain array (ChatHistoryPage). Consider wrapping results with metadata (total, page, pageSize, hasMore) or removing paging params.


360-369: Use 204 No Content for delete.

Delete collection currently returns 200; align with 204 as used for item deletion.

-      responses:
-        "200":
-          description: Collection deleted
+      responses:
+        "204":
+          description: No Content
         "401":
           $ref: "#/components/responses/Unauthorized"

Optionally apply similar change to DELETE /agent/{agentExternalId}.


388-397: Multipart array of files: add encoding for files.

Clarifies content type for each part of the array.

           multipart/form-data:
             schema:
               $ref: "#/components/schemas/UploadFilesForm"
+            encoding:
+              files:
+                contentType: application/octet-stream

640-649: String-typed booleans (isReasoningEnabled, streamOff).

If backend expects real booleans, switch to type: boolean. If strings are required for compatibility, keep as-is but document accepted values ("true"/"false").

-        isReasoningEnabled:
-          type: string
-          description: Whether reasoning is enabled (string boolean)
+        isReasoningEnabled:
+          type: boolean
+          description: Whether reasoning is enabled
...
-        streamOff:
-          type: string
-          description: Whether to disable streaming (string boolean)
+        streamOff:
+          type: boolean
+          description: Whether to disable streaming

830-838: Required fields for heterogeneous search results.

required: [id, name, type, createdAt, updatedAt] may not hold for all result types (e.g., folders/files vs collections; legacy data). Confirm all types provide both timestamps; otherwise relax requirements or split per-type schemas.


486-495: detail vs details inconsistency in error example.

Schema defines details, example uses detail. Align for clarity (or keep example but rely on additionalProperties: true).

               generic:
                 value:
                   message: "Could not create agent"
-                  detail: "…(internal error message)…"
+                  details:
+                    internal: "…(internal error message)…"

121-140: Agent identifier naming consistency (agentExternalId vs agentId).

Path uses agentExternalId while chat payload requires agentId. If both refer to the same external identifier, rename for consistency or document the distinction.

Also applies to: 621-649

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9ca2530 and 57940b5.

📒 Files selected for processing (1)
  • docs/consumer-api-keys/open_api_spec.yml (1 hunks)
🧰 Additional context used
🪛 YAMLlint (1.37.1)
docs/consumer-api-keys/open_api_spec.yml

[error] 654-654: syntax error: mapping values are not allowed here

(syntax)

🔇 Additional comments (1)
docs/consumer-api-keys/open_api_spec.yml (1)

1-20: Overall structure is solid.

OAS 3.1, security, tagging, and components are well organized. After fixing the YAML block scalar and minor schema tweaks, this will be in good shape.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant