Google Maps Platform provides a range of options for controlling your consumption and ensuring that your usage aligns with your budget. Options include: - Stop charges by capping the number of billing events your app triggers. - Get notified when your usage approaches specific budget or API limits. - Build your apps more cost effectively. The following table shows your options. |---|---|---| | Stop Charges | Get Notified | Build for Lower Cost | | [Modify quota limits](https://developers.google.com/maps/billing-and-pricing/manage-costs.md.txt#quotas) | [Create budgets and budget alerts](https://developers.google.com/maps/billing-and-pricing/manage-costs.md.txt#creating-budgets-and-set-alerts) | [Follow cost-efficient implementation strategies](https://developers.google.com/maps/billing-and-pricing/manage-costs.md.txt#cost-management-strategies) | > [!CAUTION] > **Your responsibility for charges:** You are financially responsible for charges caused by abuse of unrestricted API keys. As a best practice, [restrict your API keys](https://docs.cloud.google.com/docs/authentication/api-keys#api_key_restrictions), or [authenticate using > OAuth 2.0](https://developers.google.com/identity/protocols/oauth2), if supported. ## Quotas Quotas restrict how much of a Google Maps Platform service can be used by your Google Cloud project. Quotas are intended to ensure fairness and reduce spikes in resource use and availability. For more information, see [Cloud Quotas overview](https://docs.cloud.google.com/docs/quotas/overview). > [!IMPORTANT] > **Important:** The [Quotas](https://console.cloud.google.com/project/_/google/maps-apis/quotas) page reflects real-time usage for service resilience but is not a source of truth for billing. For precise budget management and to view finalized charges, always use the [Cloud > Billing Dashboard](https://console.cloud.google.com/billing/), which may have up to 48 hours of latency. The following count against quota: - Successful requests - Requests that cause server errors The following **don't** count against quota: - Requests that fail authentication You can set up quota alerts to be notified when your API usage is approaching the limit. For more information, see [Set up quota alerts and monitoring](https://docs.cloud.google.com/docs/quotas/set-up-quota-alerts). Quota limits help you control your API usage and prevent unexpected charges by capping the number of requests your project can make. While quota limits are set by default, they can be increased or decreased by [submitting an adjustment request](https://docs.cloud.google.com/docs/quotas/view-manage#managing_your_quota_console). For more information on managing quotas, see [View and manage quotas](https://docs.cloud.google.com/docs/quotas/view-manage). A quota sets the most your project can use an API, so it also sets the most you can be charged for that API. Lowering a quota lowers that ceiling. Raising a quota raises it, which means your project can make more billable requests before the API stops responding. A quota increase doesn't cap your spending or protect you from unexpected charges. For example, suppose a bug in your pagination code keeps requesting the next page of results with no stop condition. With a quota of 10,000 requests per day, the API rejects the loop's requests after the first 10,000. If you raise the quota to 100,000 requests per day, the same loop can make 10 times as many billable requests before the API rejects them. A quota also limits the cost of unwanted traffic, such as requests from automated crawlers or from someone else using your API key, but it isn't your main protection against that traffic. To block unwanted traffic, [restrict your API keys](https://developers.google.com/maps/api-security-best-practices) to your apps and to the APIs they use. Use quotas as a backstop. Request a quota increase only when your app needs more capacity for expected traffic, such as a product launch or a seasonal peak. > [!CAUTION] > **Caution:** Setting a quota too low can affect your ability to use the API, which could cause a user-facing outage in your application. ### Set quota limits To put a hard cap on usage of an API, lower its per-day quota. When your project reaches the limit, requests to that API fail for the rest of the day. The limit applies again each day, because daily quotas reset at midnight Pacific time. Set the limit high enough for your app's normal traffic. For example, if your app usually makes about 2,000 requests per day and up to 3,000 on busy days, a limit of 4,000 requests per day covers your busiest days and stops a runaway loop at 4,000 requests. To change a limit, open the [Quotas](https://console.cloud.google.com/project/_/google/maps-apis/quotas) page in the Cloud console, select the API, and edit the quota. For detailed steps, see [View and manage quotas](https://docs.cloud.google.com/docs/quotas/view-manage). To stay within a SKU's monthly [free usage cap](https://developers.google.com/maps/billing-and-pricing/pricing-categories), divide the free usage cap by 31 (the most days in a month) and round down. Set the result as the daily limit on the quota that counts what the SKU bills for. For example, if a SKU has a free usage cap of 1,000 billable events per month, divide 1,000 by 31 to get about 32.3. A daily limit of 32 keeps usage at or below 992 in any month. Free usage caps can change, so check the current cap for each SKU before you set a limit. Before you set a daily limit, check how the SKU is billed: - **Billing unit:** Some SKUs bill per element or per map load, not per request. For example, [`computeRouteMatrix`](https://developers.google.com/maps/documentation/routes/reference/rest/v2/TopLevel/computeRouteMatrix.md.txt) requests are [billed per element](https://developers.google.com/maps/documentation/routes/usage-and-billing), which is the number of origins multiplied by the number of destinations. A request with 5 origins and 10 destinations is billed for 50 elements. If you set a limit of 32 requests per day, your app can still use 1,600 elements per day. For these SKUs, lower the per-day quota that counts the same unit, such as elements per day, not requests per day. - **No matching quota:** Some billing units, such as sessions, don't have a matching quota. A requests quota still caps that usage, because each session includes at least one request, but it can block traffic before you reach the free usage cap. - **More than one SKU per API:** If requests to an API can trigger more than one SKU, base the limit on the SKU with the lowest free usage cap. - **More than one API per SKU:** If more than one API in your project bills to the same SKU, split the daily limit across those APIs. > [!NOTE] > **Note:** Because of the technical separation between the quota and billing systems, discrepancies may exist between these metrics. If you are using quotas to stay within a specific budget, consider setting your quota limits slightly lower than your absolute maximum. ### Adjust quota as needed Regularly review and adjust your API quotas to optimize usage and costs while finding a balance between preventing excessive spending and ensuring your application functions properly. - **Monitor your API usage patterns** in the Google Cloud Console. Set quotas that align with your budget and prevent overspending. - **Ensure quotas can handle peak usage periods**. - **Make gradual adjustments** and test your application thoroughly after each change to avoid disruptions. ## Budgets and alerts If you have a specific budget for your Google Maps Platform use, you can avoid surprises in your bill by creating Cloud Billing budgets and alerts. > [!IMPORTANT] > **Key Point:** In Google Cloud, a *budget* is a target amount of money you want to spend over a specific time period, such as per month. Budgets can apply globally at the organizational level, the project level, or the service level. You can set budget alerts to notify you when you've reached a certain percentage of your total budget, so that you can see how your usage costs are trending over time. For more information, see [Create, edit, or delete a budget alert](https://docs.cloud.google.com/billing/docs/how-to/budgets). > [!CAUTION] > **Remember:** Setting a budget does *not* automatically cap Google Cloud or Google Maps Platform usage or spending. Budget alert emails might prompt you to take action to control your costs, but they don't automatically prevent the use or billing of your services when the budget amount or threshold rules are met or exceeded. ## Strategic cost management Effective budgeting involves using free or lower-cost options whenever possible. This section explores various strategies for minimizing costs. ### Use Maps Static API whenever possible The following situations work well with static maps, which support simple map displays that only need a single marker: - **You are starting with a prototype** that doesn't yet have a lot of features. - **You don't have any map customizations**. - **You use at most one marker**. - **You don't need to support user interaction** using dynamic maps or dynamic street view. ### Lazy-load using thumbnails Thumbnails (small map images) are a good use for the Maps Static API. These items are billed at a lower rate than dynamic map loads and upon user interaction can take users to a dynamic version of Google Maps on-click, so that you only pay for dynamic map loads for engaged users. ### Use cheaper pricing categories Google provides a different number of free usage events for each pricing category. You can optimize your application to use capabilities in the "Essentials" or "Pro" categories, where you have more free monthly usage events. [Learn more about pricing categories](https://developers.google.com/maps/billing-and-pricing/overview#pricing-categories). ### Consolidate multiple maps If you have an implementation that displays multiple maps, follow these guidelines: - **Load maps only when necessary**, minimizing unnecessary resources. - **Reuse a single map** by updating its viewport, zoom, and markers as needed. - **Use the [Store Locator Plus solution](https://developers.google.com/maps/architecture/store-locator)** if you're displaying multiple maps to show store locations. - **Use a single map per user-interface screen**, as users generally only interact with one map at a time. ### Cache content when permitted Most Google Maps Platform products prohibit caching content. However, some exceptions allow you to cache their results for up to 30 days. See the Google Maps Platform [terms for details](https://cloud.google.com/maps-platform/terms/maps-service-terms).