Generated banner for API Gateway Openapi Spec Authoring
Generated logo for API Gateway Openapi Spec Authoring

API Gateway Openapi Spec Authoring

GoogleOfficialPublished by Google

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • Low risk
  • Has scripts

From the author

Writes, migrates, and fixes OpenAPI specs for Google Cloud API Gateway. Use when converting an OpenAPI 2.0 (Swagger) spec to OpenAPI 3.x, writing a new OpenAPI 3.x spec, or fixing a failed "gcloud api-gateway api-configs create", such as "extension is only supported in OpenAPI 2.x". Also use when quotas set with x-google-quota are never enforced, or when a backend receives path parameters as query parameters. Don't use for adding or debugging MCP tools (use api-gateway-mcp-server), backend lockdown or HTTP 429 tuning (use api-gateway-backend-security-and-rate-limiting), Cloud Endpoints, Apigee, or GKE Gateway API.
— the description by Google

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured approach to managing OpenAPI specifications for Google Cloud API Gateway. It supports the creation of new OpenAPI 3.x specs, the migration of legacy OpenAPI 2.0 (Swagger) configurations, and the resolution of common deployment errors encountered during the API configuration process. The skill includes a validation loop using a provided script to ensure specifications meet the requirements of the API Gateway service before deployment.

What it does

  • Converts OpenAPI 2.0 specifications to OpenAPI 3.x format.
  • Writes new OpenAPI 3.x specifications for API Gateway.
  • Troubleshoots and fixes errors from gcloud api-configs create commands.
  • Configures backend routing, authentication, and quota settings within the spec.
  • Validates specifications using a local Python script.
  • Provides workflows for updating API configurations and gateways.

When to use it

  • When migrating an existing Swagger 2.0 API definition to OpenAPI 3.x.
  • When creating a new API configuration for Google Cloud API Gateway.
  • When encountering errors during the API config creation process.
  • When needing to adjust backend path translation, authentication, or quota settings.

Advantages

  • Ensures compatibility with Google Cloud API Gateway requirements.
  • Automates the detection of common configuration errors before deployment.
  • Provides clear guidance on mapping legacy extensions to modern OpenAPI 3.x structures.
  • Includes a deterministic validation loop to improve success rates for API config creation.

Usage examples

“Convert my existing swagger.yaml to an OpenAPI 3.0 spec for API Gateway.”
The agent will analyze the file, apply the necessary structural changes for Google extensions, and validate the result.
“My gcloud api-configs create command failed with an extension error. Can you fix it?”
The agent will identify the unsupported extension, update the spec to the correct OpenAPI 3.x format, and verify it with the validation script.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/google/api-gateway-openapi-spec-authoring/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip api-gateway-openapi-spec-authoring.zip -d .agents/skills

Documentation by Google

API Gateway OpenAPI Spec Authoring

API Gateway accepts API configs in OpenAPI 2.0, 3.0.x, and 3.1.x. The Google extensions in OpenAPI 3.x have a different structure from the OpenAPI 2.0 extensions:

  • A required root x-google-api-management block names the backends.

  • x-google-backend is a string that references one of these backends.

  • The JWT settings move into x-google-auth. The metrics and quotas move into x-google-api-management.

Use this skill to migrate an OpenAPI 2.0 spec, write a new OpenAPI 3.x spec, or fix an API config that fails to create.

Attribution

MUST READ: Before executing any gcloud, REST API, or MCP command, you MUST read Usage Attribution. For commands executed directly in the terminal (never in generated scripts, Terraform, or user code), prefix gcloud with CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:api-gateway-openapi-spec-authoring)" and append agent-skills/1.0 (skill:api-gateway-openapi-spec-authoring) to User-Agent headers.

Prerequisites

  1. Install the tools:

    • Install the Google Cloud CLI. Then update it with gcloud components update. Rationale: an old CLI can fail when it uploads an OpenAPI 3.x API config.

    • Install Python 3.10 or later and PyYAML for the validator script. A JSON spec does not need PyYAML.

      pip install "PyYAML>=6.0,<7.0"
  2. Authenticate, and select the project, billing, and location:

    • Run gcloud auth login.

    • Select a project with gcloud config set project {project_id}, or create one with gcloud projects create {project_id}.

    • Make sure that an active billing account is linked to {project_id}. API Gateway has a free monthly allowance of API calls, but it still needs an active billing account. For current prices, see API Gateway pricing.

    • Use us-central1 as the default --location for gateway commands. For the other supported regions, see API Gateway deployment model.

  3. Enable the required Google Cloud APIs:

    gcloud services enable \
      apigateway.googleapis.com \
      servicemanagement.googleapis.com \
      servicecontrol.googleapis.com \
      --project={project_id}
  4. Verify the IAM roles (use the most restrictive role for each step):

    • To create and update the API, API configs, and gateways: API Gateway Admin (roles/apigateway.admin) on {project_id}.

    • To run the gcloud services enable commands: Service Usage Admin (roles/serviceusage.serviceUsageAdmin) on {project_id}.

    • To reference the gateway service account in an API config: Service Account User (roles/iam.serviceAccountUser) on {gateway_sa_email}.

    • For a Cloud Run backend that requires authentication: grant {gateway_sa_email} the Cloud Run Invoker role (roles/run.invoker) on the service.

Decision Matrix

TaskRequired MechanismCritical GuardrailDetailed Reference
Migrate an OpenAPI 2.0 (swagger: "2.0") configConvert the standard fields, then move each Google extension to its OpenAPI 3.x form.A converter such as Swagger Editor leaves every x-google-* extension in its OpenAPI 2.0 form. It also writes servers without x-google-endpoint, so the API loses its base path. Rationale: API Gateway rejects most OpenAPI 2.0 extensions in a 3.x spec with The '{extension}' extension is only supported in OpenAPI 2.x.OpenAPI 2.0 to 3.x Migration
Route requests to backendsRoot x-google-api-management.backends.{backend_name} + x-google-backend: {backend_name} at the root or on an operationSet pathTranslation on every backend. Rationale: the default is APPEND_PATH_TO_ADDRESS for a root x-google-backend, but CONSTANT_ADDRESS for an operation-level one. CONSTANT_ADDRESS sends every request to the address unchanged, and sends path parameters as query parameters. APPEND_PATH_TO_ADDRESS appends the full request path, with the base path. NEVER set x-google-backend on a path item: API Gateway rejects it.Extensions and Limits
Authenticate callersJWT: type: oauth2 scheme with x-google-auth (issuer, jwksUri, audiences). API key: type: apiKey scheme with x-api-key in a header, or key or api_key in the query.API Gateway does not check OAuth scopes. In a security list, put an API key in every alternative (OR) or in none. NEVER put two JWT schemes in one requirement object (AND). Rationale: API Gateway rejects these combinations. If the user asks for one of them, such as a JWT or an API key as alternatives, do not write it in the spec. Explain the rule, and write a supported option, such as an API key in every alternative or a separate path for each kind of caller.Extensions and Limits
Add quotasx-google-api-management.metrics and quota.limits + x-google-quota: {metric_name: cost} on each operationNEVER rely on x-google-quota at the root or path level. Rationale: in OpenAPI 3.x, API Gateway ignores it there without an error. Require an API key on each operation that has a quota, and keep each metric name the same in every API config.Extensions and Limits
Set the base path and CORSOne servers entry with x-google-endpoint, such as url: /v1API Gateway ignores servers entries without x-google-endpoint. allowCors: true only passes CORS requests to the backend. Rationale: the gateway does not add CORS headers, so the backend must answer them.Extensions and Limits
Fix a failed api-configs createMatch the error text to the error table, and fix the spec.Fix the spec before you retry, unless the error is about IAM or another api-configs create that runs. Rationale: API Gateway returns the same error for the same spec.API Config Errors
Expose operations as MCP toolsThe api-gateway-mcp-server skillMCP adds rules for tool names, descriptions, and tools/list security. If that skill is not installed, use this skill for the OpenAPI 3.x spec, and follow the Configure MCP guide for the MCP extensions.-

Execution Workflow and Validation Loop

  1. Get the current spec:

    • Use the spec file in the user's repository. If there is no file, find the active API config of the gateway:

      gcloud api-gateway gateways describe {gateway_id} --location={region} --project={project_id} --format="value(apiConfig)"
    • The output is projects/{project}/locations/global/apis/{api_id}/configs/{config_id}. Print the spec of that config:

      gcloud api-gateway api-configs describe {config_id} --api={api_id} --project={project_id} --view=FULL \
        --format="value(openapiDocuments[0].document.contents)" | tr '_-' '/+' | base64 --decode
    • gcloud prints the contents in URL-safe base64, so tr changes two characters before base64 --decode. If the config has more than one OpenAPI document, change [0] to [1], [2], and so on.

  2. Write the OpenAPI 3.x spec:

    • For an OpenAPI 2.0 spec, follow OpenAPI 2.0 to 3.x Migration, and compare your result with its complete converted example.

    • For a new spec, start from the template in Extensions and Limits.

    • Set openapi to a 3.0.x or 3.1.x version. The examples use 3.0.4. In OpenAPI 3.1, give each schema one type. Rationale: API Gateway rejects a type list such as type: ["string", "null"].

    • Give every operation a unique operationId and a responses object, and use only local $ref values. Rationale: API Gateway rejects an operation without operationId or responses, two operationId values that give the same method name, such as getItem and get-Item, and a $ref to a URL.

  3. Run the deterministic validation loop on every spec that you write or change, before you answer or create the API config:

    python3 scripts/validate_apigw_openapi.py --spec={spec_file}
    • The script path is relative to the directory of this skill. If you only return the spec in your reply, write it to a temporary file, and run the script on that file before you answer.

    • If the script exits with code 1 ("status": "FAIL"), fix every error in {spec_file}, and run the script again. Continue until it exits with code 0 ("status": "PASS").

    • If the script exits with code 2, fix the file path or the YAML/JSON syntax error that stderr shows, or install PyYAML.

    • Read every warning, such as a backend without pathTranslation, a quota on an operation without an API key, or allowCors. Fix it, or tell the user why you keep it.

    • The script does not check every rule. A PASS means that it found none of the API Gateway problems that this skill describes. It does not check general OpenAPI validity, such as a $ref to a schema that does not exist. Rationale: only api-configs create in step 5 shows that API Gateway accepts the spec. Do not tell the user that the spec deploys because the script passed.

  4. Summarize the spec for the user, and get approval before you deploy. State each of these points:

    • Each OpenAPI 2.0 extension that you moved or removed, such as x-google-allow, which OpenAPI 3.x does not support. Also state each other change, such as an added operationId or a fixed address.

    • The pathTranslation of each backend (backend_path_translation in the script output), and each operation whose path parameters now go to the backend as query parameters (path_parameters_as_query). With APPEND_PATH_TO_ADDRESS, the backend also receives the base path.

    • Which operations need a JWT or an API key, which backends receive an ID token and with which audience, and that API Gateway does not check OAuth scopes.

    • The quota metrics and limits, and that each metric name matches the current API config.

  5. Create a new API config and update the gateway (request human approval before you update a production gateway):

    gcloud api-gateway api-configs create {new_config_id} \
      --api={api_id} \
      --openapi-spec={spec_file} \
      --backend-auth-service-account={gateway_sa_email} \
      --project={project_id}
    
    gcloud api-gateway gateways update {gateway_id} \
      --api={api_id} \
      --api-config={new_config_id} \
      --location={region} \
      --project={project_id}
    • For a new gateway, run gcloud api-gateway gateways create {gateway_id} with the same flags instead of gateways update. api-configs create creates the API if it does not exist.

    • If an operation requires an API key, enable the managed service of the API. Get its name with gcloud api-gateway apis describe {api_id} --project={project_id} --format="value(managedService)", and then run gcloud services enable {managed_service} --project={project_id}. Also enable it in each project that creates API keys for the API.

    • Use a new config ID for each change, because you cannot change the spec of an existing API config.

    • Run one api-configs create at a time for each API, and wait for it to finish. A large API config can take up to ten minutes to create.

    • If api-configs create fails, find the error text in API Config Errors, fix the spec, and go back to step 3.

    • Keep the previous API config until the new one serves traffic. To roll back, run gateways update with the previous config ID.

  6. Verify the gateway:

    • Run gcloud api-gateway gateways describe {gateway_id} --location={region} --project={project_id} --format="value(state,defaultHostname)", and wait until the state is ACTIVE.

    • Send a request to each changed path at https://{default_hostname}{base_path}{path}, with the credential that the operation requires. Check that the backend receives the path and parameters that you expect.

    • An HTML 404 Page not found means that the gateway is not ready. Check that the last create or update finished, and retry before you change the config. During a gateway update, some requests can still reach the previous API config. A JSON 404 (The current request is not defined by this API.) means that the active API config does not define the path.

Pre-Deployment Checklist

  • [ ] openapi is 3.0.x or 3.1.x, and the spec has no OpenAPI 2.0 extension, such as x-google-management, x-google-endpoints, x-google-api-name, x-google-allow, or x-google-issuer on a security scheme.

  • [ ] x-google-api-management.backends defines every backend, every x-google-backend is a string that names one, and no path item sets x-google-backend.

  • [ ] Every backend sets pathTranslation.

  • [ ] Every operation has a unique operationId and a responses object, and each path variable has a parameter with in: path and required: true.

  • [ ] Every x-google-quota is on an operation that requires an API key, and every metric name matches the current API config.

  • [ ] At most one servers entry has x-google-endpoint, and its URL has no custom port.

  • [ ] python3 scripts/validate_apigw_openapi.py --spec={spec_file} returns "status": "PASS" (exit code 0).

Resource Cleanup

To avoid ongoing charges when you tear down a test environment, request human approval, and delete the resources in dependency order:

gcloud api-gateway gateways delete {gateway_id} --location={region} --project={project_id}
gcloud api-gateway api-configs delete {config_id} --api={api_id} --project={project_id}
gcloud api-gateway apis delete {api_id} --project={project_id}

Files

LICENSE


                                 Apache License
                           Version 2.0, January 2004
                        http://www.apache.org/licenses/

   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

   1. Definitions.

      "License" shall mean the terms and conditions for use, reproduction,
      and distribution as defined by Sections 1 through 9 of this document.

      "Licensor" shall mean the copyright owner or entity authorized by
      the copyright owner that is granting the License.

      "Legal Entity" shall mean the union of the acting entity and all
      other entities that control, are controlled by, or are under common
      control with that entity. For the purposes of this definition,
      "control" means (i) the power, direct or indirect, to cause the
      direction or management of such entity, whether by contract or
      otherwise, or (ii) ownership of fifty percent (50%) or more of the
      outstanding shares, or (iii) beneficial ownership of such entity.

      "You" (or "Your") shall mean an individual or Legal Entity
      exercising permissions granted by this License.

      "Source" form shall mean the preferred form for making modifications,
      including but not limited to software source code, documentation
      source, and configuration files.

      "Object" form shall mean any form resulting from mechanical
      transformation or translation of a Source form, including but
      not limited to compiled object code, generated documentation,
      and conversions to other media types.

      "Work" shall mean the work of authorship, whether in Source or
      Object form, made available under the License, as indicated by a
      copyright notice that is included in or attached to the work
      (an example is provided in the Appendix below).

      "Derivative Works" shall mean any work, whether in Source or Object
      form, that is based on (or derived from) the Work and for which the
      editorial revisions, annotations, elaborations, or other modifications
      represent, as a whole, an original work of authorship. For the purposes
      of this License, Derivative Works shall not include works that remain
      separable from, or merely link (or bind by name) to the interfaces of,
      the Work and Derivative Works thereof.

      "Contribution" shall mean any work of authorship, including
      the original version of the Work and any modifications or additions
      to that Work or Derivative Works thereof, that is intentionally
      submitted to Licensor for inclusion in the Work by the copyright owner
      or by an individual or Legal Entity authorized to submit on behalf of
      the copyright owner. For the purposes of this definition, "submitted"
      means any form of electronic, verbal, or written communication sent
      to the Licensor or its representatives, including but not limited to
      communication on electronic mailing lists, source code control systems,
      and issue tracking systems that are managed by, or on behalf of, the
      Licensor for the purpose of discussing and improving the Work, but
      excluding communication that is conspicuously marked or otherwise
      designated in writing by the copyright owner as "Not a Contribution."

      "Contributor" shall mean Licensor and any individual or Legal Entity
      on behalf of whom a Contribution has been received by Licensor and
      subsequently incorporated within the Work.

   2. Grant of Copyright License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      copyright license to reproduce, prepare Derivative Works of,
      publicly display, publicly perform, sublicense, and distribute the
      Work and such Derivative Works in Source or Object form.

   3. Grant of Patent License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      (except as stated in this section) patent license to make, have made,
      use, offer to sell, sell, import, and otherwise transfer the Work,
      where such license applies only to those patent claims licensable
      by such Contributor that are necessarily infringed by their
      Contribution(s) alone or by combination of their Contribution(s)
      with the Work to which such Contribution(s) was submitted. If You
      institute patent litigation against any entity (including a
      cross-claim or counterclaim in a lawsuit) alleging that the Work
      or a Contribution incorporated within the Work constitutes direct
      or contributory patent infringement, then any patent licenses
      granted to You under this License for that Work shall terminate
      as of the date such litigation is filed.

   4. Redistribution. You may reproduce and distribute copies of the
      Work or Derivative Works thereof in any medium, with or without
      modifications, and in Source or Object form, provided that You
      meet the following conditions:

      (a) You must give any other recipients of the Work or
          Derivative Works a copy of this License; and

      (b) You must cause any modified files to carry prominent notices
          stating that You changed the files; and

      (c) You must retain, in the Source form of any Derivative Works
          that You distribute, all copyright, patent, trademark, and
          attribution notices from the Source form of the Work,
          excluding those notices that do not pertain to any part of
          the Derivative Works; and

      (d) If the Work includes a "NOTICE" text file as part of its
          distribution, then any Derivative Works that You distribute must
          include a readable copy of the attribution notices contained
          within such NOTICE file, excluding those notices that do not
          pertain to any part of the Derivative Works, in at least one
          of the following places: within a NOTICE text file distributed
          as part of the Derivative Works; within the Source form or
          documentation, if provided along with the Derivative Works; or,
          within a display generated by the Derivative Works, if and
          wherever such third-party notices normally appear. The contents
          of the NOTICE file are for informational purposes only and
          do not modify the License. You may add Your own attribution
          notices within Derivative Works that You distribute, alongside
          or as an addendum to the NOTICE text from the Work, provided
          that such additional attribution notices cannot be construed
          as modifying the License.

      You may add Your own copyright statement to Your modifications and
      may provide additional or different license terms and conditions
      for use, reproduction, or distribution of Your modifications, or
      for any such Derivative Works as a whole, provided Your use,
      reproduction, and distribution of the Work otherwise complies with
      the conditions stated in this License.

   5. Submission of Contributions. Unless You explicitly state otherwise,
      any Contribution intentionally submitted for inclusion in the Work
      by You to the Licensor shall be under the terms and conditions of
      this License, without any additional terms or conditions.
      Notwithstanding the above, nothing herein shall supersede or modify
      the terms of any separate license agreement you may have executed
      with Licensor regarding such Contributions.

   6. Trademarks. This License does not grant permission to use the trade
      names, trademarks, service marks, or product names of the Licensor,
      except as required for reasonable and customary use in describing the
      origin of the Work and reproducing the content of the NOTICE file.

   7. Disclaimer of Warranty. Unless required by applicable law or
      agreed to in writing, Licensor provides the Work (and each
      Contributor provides its Contributions) on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
      implied, including, without limitation, any warranties or conditions
      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
      PARTICULAR PURPOSE. You are solely responsible for determining the
      appropriateness of using or redistributing the Work and assume any
      risks associated with Your exercise of permissions under this License.

   8. Limitation of Liability. In no event and under no legal theory,
      whether in tort (including negligence), contract, or otherwise,
      unless required by applicable law (such as deliberate and grossly
      negligent acts) or agreed to in writing, shall any Contributor be
      liable to You for damages, including any direct, indirect, special,
      incidental, or consequential damages of any character arising as a
      result of this License or out of the use or inability to use the
      Work (including but not limited to damages for loss of goodwill,
      work stoppage, computer failure or malfunction, or any and all
      other commercial damages or losses), even if such Contributor
      has been advised of the possibility of such damages.

   9. Accepting Warranty or Additional Liability. While redistributing
      the Work or Derivative Works thereof, You may choose to offer,
      and charge a fee for, acceptance of support, warranty, indemnity,
      or other liability obligations and/or rights consistent with this
      License. However, in accepting such obligations, You may act only
      on Your own behalf and on Your sole responsibility, not on behalf
      of any other Contributor, and only if You agree to indemnify,
      defend, and hold each Contributor harmless for any liability
      incurred by, or claims asserted against, such Contributor by reason
      of your accepting any such warranty or additional liability.

   END OF TERMS AND CONDITIONS

   APPENDIX: How to apply the Apache License to your work.

      To apply the Apache License to your work, attach the following
      boilerplate notice, with the fields enclosed by brackets "[]"
      replaced with your own identifying information. (Don't include
      the brackets!)  The text should be enclosed in the appropriate
      comment syntax for the file format. We also recommend that a
      file or class name and description of purpose be included on the
      same "printed page" as the copyright notice for easier
      identification within third-party archives.

   Copyright [yyyy] [name of copyright owner]

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs an API key, Needs a command-line tool, Needs Python

Security

What our scanner noticed· Low risk

  • Instructions that use the network
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Google
Publisher
Google (Official)
Source
google/skills · skills/cloud/api-gateway-openapi-spec-authoring · commit 2194d3b
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Google.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download api-gateway-openapi-spec-authoring.zip