This page provides recommendations for naming conventions of the Cloud projects
that you may need to create in addition to the Cloud project for your production
backend.
Depending on the purpose of the environment or the stage in the API lifecycle,
you may want to:
Change the API name or the Cloud Endpoints service name. See
Configuring Endpoints for more
information.
Create a different project.
Change the path that the API is served from.
Following are some common patterns you may want to use:
Versioning the API: When you think you may need to make backwards-incompatible
changes in the future, plan ahead and add the version number in the path where
the API is served from. For example:
my-api.endpoints.my‐project.cloud.goog/v1/echo
Development/test instances: Each developer stands up their own version of the
service, in their own project. For example, Dan the developer uses:
Running a private alpha: When you want to test a new version of your
service with some customers, but not all, the easiest approach is to put the
alpha version in its own project, which provides the highest level of isolation
from production. For example:
Alternatively, you could put the alpha version in the same project but
configure it as a separate service. Since it is a separate service, you can
restrict access to only the alpha customers. For example:
Running an open alpha: When you want to release an alpha version that
is available to all customers, you can put it in the same service and project as
the existing version, and change the path. For example:
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-04 UTC."],[[["\u003cp\u003eThis page offers guidelines for naming conventions of Cloud projects related to API management, beyond just the production backend project.\u003c/p\u003e\n"],["\u003cp\u003eConsider creating different Cloud projects for development, staging, and alpha testing environments to isolate and manage API versions.\u003c/p\u003e\n"],["\u003cp\u003eVersioning APIs by including version numbers in the path (e.g., \u003ccode\u003e/v1/\u003c/code\u003e, \u003ccode\u003e/v2alpha/\u003c/code\u003e) is recommended to facilitate backward-incompatible changes.\u003c/p\u003e\n"],["\u003cp\u003eRunning private alpha tests of APIs is suggested to use a separate Cloud project for enhanced isolation, or alternatively, a distinct service within the same project with restricted access.\u003c/p\u003e\n"],["\u003cp\u003eOpen alpha tests can be done within the existing service and project, by simply altering the API path to indicate the alpha version.\u003c/p\u003e\n"]]],[],null,["# Planning Your Cloud Projects\n\nOpenAPI \\| [gRPC](/endpoints/docs/grpc/planning-cloud-projects \"View this page for the Cloud Endpoints gRPC docs\")\n\n\u003cbr /\u003e\n\nThis page provides recommendations for naming conventions of the Cloud projects\nthat you may need to create in addition to the Cloud project for your production\nbackend.\n\nDepending on the purpose of the environment or the stage in the API lifecycle,\nyou may want to:\n\n- Change the API name or the Cloud Endpoints service name. See [Configuring Endpoints](/endpoints/docs/openapi/configure-endpoints#service_name) for more information.\n- Create a different project.\n- Change the path that the API is served from.\n\nFollowing are some common patterns you may want to use:\n\n- **Versioning the API**: When you think you may need to make backwards-incompatible\n changes in the future, plan ahead and add the version number in the path where\n the API is served from. For example:\n\n - `my-api.endpoints.my‐project.cloud.goog/`**v1**`/echo`\n- **Development/test instances**: Each developer stands up their own version of the\n service, in their own project. For example, Dan the developer uses:\n\n - `my-api.endpoints.`**dan-dev-project**`.cloud.goog/v1/echo`\n- **Staging**: Before you deploy to production, you test your APIs on your\n staging backend, which is in its own project. For example:\n\n - `my-api.endpoints.`**my‐project-staging**`.cloud.goog/v1/echo`\n- **Running a private alpha**: When you want to test a new version of your\n service with some customers, but not all, the easiest approach is to put the\n alpha version in its own project, which provides the highest level of isolation\n from production. For example:\n\n - `my-api.endpoints.`**my‐project-alpha** `.cloud.goog/`**v2alpha**`/echo`\n\n Alternatively, you could put the alpha version in the same project but\n configure it as a separate service. Since it is a separate service, you can\n restrict access to only the alpha customers. For example:\n - **my-api-alpha** `.endpoints.my-project.cloud.goog/`**v2alpha**`/echo`\n- **Running an open alpha**: When you want to release an alpha version that\n is available to all customers, you can put it in the same service and project as\n the existing version, and change the path. For example:\n\n - `my-api.endpoints.my-project.cloud.goog/`**v2alpha**`/echo`\n\nSee also:\n\n\u003cbr /\u003e\n\n- [API lifecycle management](/endpoints/docs/openapi/lifecycle-management)\n- [Versioning an API](/endpoints/docs/openapi/versioning-an-api)"]]
