feat: API specs update for version 1.9.x

[ChiragAgg5k]

This PR contains API specification updates for version 1.9.x (client, server, console platforms), generated from the current cloud main.

Synced manually because the "Generate Specs" workflow's examples step currently fails with Class "Appwrite\SDK\Language\AgentSkills" not found (server-ce references a class no sdk-generator release ships) — the spec generation step itself succeeded. Examples are unchanged.

Needed to unblock appwrite/sdk-generator#1653 validation, which generates the console CLI/web SDKs from these specs.

[greptile-apps]

Greptile Summary

This PR updates all three OpenAPI 3 spec files (client, server, console) for Appwrite 1.9.x, generated from cloud main. The changes introduce real rate limits on previously unlimited endpoints, rename the locale schema to cloudLocale, and substantially expand the OAuth2 and organization-management API surface.

• Client spec: Rate limits activated on /apps/* and OAuth2 endpoints; OAuth2 authorize parameters (client_id, redirect_uri, response_type, scope) changed from required to optional to support the new PAR request_uri flow; new scope parameter on the approve endpoint.
• Server spec: New OAuth2 endpoints (oauth2CreatePAR, oauth2ListOrganizations, oauth2ListProjects, oauth2Revoke), new organization/membership management endpoints, dedicatedDatabaseId replaced by specification, resource renamed to resourceType in usageDataPoint, four messaging-log operations and healthGetQueueLogs removed, deno-1.21/1.24/1.35 runtimes dropped, a new Bearer HTTP security scheme added (currently unreferenced by any operation).
• Console spec: Large restructuring — all compute* database-management operations replaced by a new databases* API surface (net +76 operations); messaging-log and VectorsDB/TablesDB usage endpoints removed.

Confidence Score: 4/5

Safe to merge as a spec-only update; the changes reflect intentional 1.9.x API decisions generated from cloud main with no example modifications.

The Bearer security scheme is added to securitySchemes but is not wired into any operation's security array — including the OAuth2 endpoints that conceptually require it — so either those operations are missing the scheme or the definition is dead weight that will confuse SDK generators. All other changes (rate-limit activations, locale→cloudLocale, resource→resourceType, dedicatedDatabaseId→specification, endpoint removals) appear intentional and consistent across all three spec files, though they collectively represent several breaking changes that warrant clear migration documentation.

The server spec deserves a second look on the Bearer security scheme wiring and the new OAuth2/organization endpoint security requirements.

Important Files Changed

Filename	Overview
specs/1.9.x/open-api3-1.9.x-client.json	Rate limits activated on all /apps/* and OAuth2 endpoints (previously 0/3600, now real limits); locale schema renamed to cloudLocale with all $refs updated; OAuth2 authorize endpoint params (client_id, redirect_uri, response_type, scope) changed from required to optional to support PAR request_uri flow; new scope consent parameter on approve and new request_uri query param on authorize.
specs/1.9.x/open-api3-1.9.x-server.json	Large update: new OAuth2 endpoints (PAR, organization/project listing, revoke), new organization membership management endpoints, new health endpoints, dedicatedDatabaseId replaced by specification, resource renamed to resourceType in usageDataPoint, locale renamed to cloudLocale, messaging log operations removed (messagingListMessageLogs, etc.), healthGetQueueLogs removed, deno-1.21/1.24/1.35 runtimes removed, Bearer security scheme defined but unreferenced.
specs/1.9.x/open-api3-1.9.x-console.json	Major restructuring: 439 operations removed (all compute* database management, messaging log endpoints, TablesDB/VectorsDB usage ops) and 515 operations added (new databases* API surface, console utility endpoints, staging/OAuth2 project ops); locale renamed to cloudLocale throughout.

Comments Outside Diff (1)

1. specs/1.9.x/open-api3-1.9.x-server.json, line 73600-73604 (link)

   resource field renamed to resourceType in usageDataPoint — breaking schema change

   The usageDataPoint response schema renames the field resource to resourceType. Clients that destructure or map this field by name will silently get undefined/null after the upgrade. This is also reflected in the required array and the schema example. Worth surfacing explicitly in the 1.9.x changelog, particularly for users of the usage-stats / analytics endpoints who may have built dashboards or automations on this field.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: specs/1.9.x/open-api3-1.9.x-server.json
   Line: 73600-73604
   
   Comment:
   **`resource` field renamed to `resourceType` in `usageDataPoint` — breaking schema change**
   
   The `usageDataPoint` response schema renames the field `resource` to `resourceType`. Clients that destructure or map this field by name will silently get `undefined`/`null` after the upgrade. This is also reflected in the `required` array and the schema example. Worth surfacing explicitly in the 1.9.x changelog, particularly for users of the usage-stats / analytics endpoints who may have built dashboards or automations on this field.
   
   How can I resolve this? If you propose a fix, please make it concise.

   

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
specs/1.9.x/open-api3-1.9.x-server.json:83398-83403
**Bearer security scheme defined but never referenced**

The new `Bearer` HTTP security scheme (`type: http, scheme: bearer`) is added to `securitySchemes` but is not included in the `security` array of any operation. The new OAuth2 endpoints that semantically require an OAuth2 access token — `oauth2ListOrganizations`, `oauth2ListProjects` — list `ProjectPath + Session + JWT + Key` instead. If callers are expected to pass their access token via a standard `Authorization: Bearer <token>` header to these endpoints, those operations need `Bearer` added to their `security` requirements; otherwise the security scheme entry is dead and can be removed to avoid confusion in generated SDKs.

### Issue 2 of 3
specs/1.9.x/open-api3-1.9.x-server.json:16528-16536
**`dedicatedDatabaseId` replaced by `specification` — breaking parameter rename**

The database-create body parameter previously named `dedicatedDatabaseId` (an opaque ID string) is replaced by `specification` (a slug like `"serverless"`). Any existing server SDK user passing `dedicatedDatabaseId` will silently have that field ignored by the 1.9 server, placing the new database on the wrong compute tier without an error. This is consistent across the create-database call in the server spec, but is worth calling out explicitly in the migration notes for 1.9.x so SDK generators can emit a deprecation or compile-time warning for callers on older generated SDKs.

### Issue 3 of 3
specs/1.9.x/open-api3-1.9.x-server.json:73600-73604
**`resource` field renamed to `resourceType` in `usageDataPoint` — breaking schema change**

The `usageDataPoint` response schema renames the field `resource` to `resourceType`. Clients that destructure or map this field by name will silently get `undefined`/`null` after the upgrade. This is also reflected in the `required` array and the schema example. Worth surfacing explicitly in the 1.9.x changelog, particularly for users of the usage-stats / analytics endpoints who may have built dashboards or automations on this field.

_{Reviews (1): Last reviewed commit: "(chore): update 1.9.x API specs" | Re-trigger Greptile}

[greptile-apps]

Bearer security scheme defined but never referenced

The new Bearer HTTP security scheme (type: http, scheme: bearer) is added to securitySchemes but is not included in the security array of any operation. The new OAuth2 endpoints that semantically require an OAuth2 access token — oauth2ListOrganizations, oauth2ListProjects — list ProjectPath + Session + JWT + Key instead. If callers are expected to pass their access token via a standard Authorization: Bearer <token> header to these endpoints, those operations need Bearer added to their security requirements; otherwise the security scheme entry is dead and can be removed to avoid confusion in generated SDKs.

Prompt To Fix With AI

This is a comment left during a code review.
Path: specs/1.9.x/open-api3-1.9.x-server.json
Line: 83398-83403

Comment:
**Bearer security scheme defined but never referenced**

The new `Bearer` HTTP security scheme (`type: http, scheme: bearer`) is added to `securitySchemes` but is not included in the `security` array of any operation. The new OAuth2 endpoints that semantically require an OAuth2 access token — `oauth2ListOrganizations`, `oauth2ListProjects` — list `ProjectPath + Session + JWT + Key` instead. If callers are expected to pass their access token via a standard `Authorization: Bearer <token>` header to these endpoints, those operations need `Bearer` added to their `security` requirements; otherwise the security scheme entry is dead and can be removed to avoid confusion in generated SDKs.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

dedicatedDatabaseId replaced by specification — breaking parameter rename

The database-create body parameter previously named dedicatedDatabaseId (an opaque ID string) is replaced by specification (a slug like "serverless"). Any existing server SDK user passing dedicatedDatabaseId will silently have that field ignored by the 1.9 server, placing the new database on the wrong compute tier without an error. This is consistent across the create-database call in the server spec, but is worth calling out explicitly in the migration notes for 1.9.x so SDK generators can emit a deprecation or compile-time warning for callers on older generated SDKs.

Prompt To Fix With AI

This is a comment left during a code review.
Path: specs/1.9.x/open-api3-1.9.x-server.json
Line: 16528-16536

Comment:
**`dedicatedDatabaseId` replaced by `specification` — breaking parameter rename**

The database-create body parameter previously named `dedicatedDatabaseId` (an opaque ID string) is replaced by `specification` (a slug like `"serverless"`). Any existing server SDK user passing `dedicatedDatabaseId` will silently have that field ignored by the 1.9 server, placing the new database on the wrong compute tier without an error. This is consistent across the create-database call in the server spec, but is worth calling out explicitly in the migration notes for 1.9.x so SDK generators can emit a deprecation or compile-time warning for callers on older generated SDKs.

How can I resolve this? If you propose a fix, please make it concise.