Skip to content

feat: API specs update for version latest#62

Merged
ChiragAgg5k merged 1 commit intomainfrom
feat-latest-specs
May 6, 2026
Merged

feat: API specs update for version latest#62
ChiragAgg5k merged 1 commit intomainfrom
feat-latest-specs

Conversation

@appwrite-specs
Copy link
Copy Markdown

@appwrite-specs appwrite-specs Bot commented May 6, 2026

This PR contains API specification updates for version latest.

@ChiragAgg5k ChiragAgg5k merged commit a3bc36f into main May 6, 2026
2 checks passed
@greptile-apps
Copy link
Copy Markdown

greptile-apps Bot commented May 6, 2026

Greptile Summary

This PR updates all six API spec files (OpenAPI 3 and Swagger 2 variants for client, console, and server) to introduce a new consoleSuggestQueries endpoint, add Cookie and DevKey security scheme definitions, expand backup/project-policy scopes, and register new scope values in API key enumerations.

  • New GET /console/suggestions/queries endpoint: accepts a natural-language input and a resource type to generate Appwrite query objects via an AI-backed validator; the endpoint is console-only with a rate-limit of 10 per hour.
  • Scope field now accepts arrays: 87 backup/project-policy endpoints had their x-appwrite.scope changed from a plain string to an array (e.g. [\"policies.read\",\"backups.policies.read\"]), while the remaining ~490 endpoints still use a string — a type inconsistency that can break downstream tooling.
  • New Cookie security scheme: added across all three spec types as an apiKey sent via the Cookie header, intended for SDKs that forward browser cookies in server-side runtimes.

Confidence Score: 3/5

The spec changes introduce two issues that could cause incorrect behavior once consumed by SDK generators or server-side enforcement: the scope field type inconsistency and the mismatched scope on the new AI query endpoint.

The x-appwrite.scope type change from string to array affects 87 endpoints across all spec formats and could silently break any tooling that reads this custom extension as a string. The new consoleSuggestQueries endpoint carries a databases.read scope but supports resource types well beyond databases, which either wrongly gates the feature or misrepresents the access model.

The server and console specs (open-api3-latest-server.json, open-api3-latest-console.json, and their swagger2-latest-* mirrors) warrant the most attention due to the scope array migration and the new endpoint's access model.

Important Files Changed

Filename Overview
specs/latest/open-api3-latest-console.json Largest change: adds new consoleSuggestQueries endpoint, adds Cookie security scheme, migrates backup/project policy endpoint scopes from string to array, and increments many endpoint weights.
specs/latest/open-api3-latest-server.json Adds DevKey and Cookie security schemes, migrates backup/project policy endpoint scopes from string to array, adds new scope values to API key enum lists, increments endpoint weights.
specs/latest/swagger2-latest-console.json Mirror of open-api3-latest-console.json changes in Swagger 2.0 format; same scope-to-array migration and new consoleSuggestQueries endpoint.
specs/latest/swagger2-latest-server.json Mirror of open-api3-latest-server.json changes in Swagger 2.0 format; same scope-to-array migration, new DevKey/Cookie security schemes.
specs/latest/open-api3-latest-client.json Minimal changes: adds Cookie security scheme definition, adjusts two endpoint weights.
specs/latest/swagger2-latest-client.json Mirror of open-api3-latest-client.json in Swagger 2.0 format; same minimal weight and Cookie scheme changes.

Comments Outside Diff (1)

  1. specs/latest/open-api3-latest-console.json, line 9330-9395 (link)

    P2 Conditionally-required parameters databaseId and tableId marked required: false

    The parameter descriptions state that databaseId is "Required when type is tables or rows" and tableId is "Required when type is rows", but both are declared required: false in the schema. OpenAPI does not support conditional required, so the spec cannot enforce this contract. SDK generators will treat both as fully optional, and generated client code won't prompt users to provide them. Consider adding a note in the endpoint description or using a discriminator / oneOf to at least document the conditional dependency more prominently. The same applies to swagger2-latest-console.json.

Reviews (1): Last reviewed commit: "chore: update API specs and SDK examples" | Re-trigger Greptile

Comment on lines +6030 to +6033
"scope": [
"policies.read",
"backups.policies.read"
],
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P1 x-appwrite.scope silently changed type from string to array

The scope field inside x-appwrite was exclusively a JSON string in every previous endpoint definition. This PR converts 87 endpoints across server and console specs to emit an array instead (e.g. ["policies.read", "backups.policies.read"]), while the remaining ~490 endpoints still emit a string. Any SDK generator, documentation tool, or Appwrite server code that reads x-appwrite.scope with a string assumption — e.g. a direct equality check or .includes() call — will silently mishandle all array-scoped endpoints. The same inconsistency is present in swagger2-latest-server.json and the console variants.

"rate-limit": 10,
"rate-time": 3600,
"rate-key": "url:{url},ip:{ip}",
"scope": "databases.read",
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

P1 consoleSuggestQueries scope databases.read covers only a fraction of supported types

The consoleSuggestQueries endpoint accepts type values spanning all resource domains — users, functions, sites, deployments, sessions, identities, memberships, buckets, providers, etc. — yet its x-appwrite.scope is locked to databases.read. If the backend enforces this scope, a console session without database-read permission would be denied query suggestions for every resource type. Conversely, if the enforcement is relaxed because of this mismatch, the scope field is misleading. The same issue is present in swagger2-latest-console.json.

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