Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Veja nesta página informações sobre solução de problemas de cada versão das seguintes APIs da infraestrutura de serviços:
API Service Management
API Service Control
API Service Consumer Management
Como processar erros da API Service Control em geral?
A API Service Control fornece funcionalidade de plano de controle, como registro e monitoramento, para serviços gerenciados. Portanto, os chamadores da API Service Control costumam ser aplicativos de servidor. Veja algumas recomendações gerais de como processar erros no nível da API REST/RPC:
O servidor precisa registrar todos os erros retornados pela API Service Control, e é possível usar os dados para solucionar problemas do seu serviço gerenciado.
Se o servidor receber erros 429 da API Service Control, ele retornará erros 429 aos clientes.
Se o servidor não conseguir acessar a API Service Control, as opções serão "fail-open" (ignorar o erro) ou "fail-close" (retornar 503 ao cliente).
Se o servidor receber erros 500 da API Service Control, ele retornará o erro 500 aos clientes. Esses erros costumam indicar bugs na API Service Control.
Se o servidor receber outros erros da API Service Control, ele retornará o erro 500 aos clientes. Esses erros costumam indicar bugs no seu serviço gerenciado.
O que significa o erro "serviço não ativado"?
Para usar qualquer serviço de API do Google, você precisa ter um projeto Google Cloud , ativar o serviço para esse projeto e transmitir uma chave de API ou um token de acesso OAuth associado ao projeto para cada solicitação de API. Consulte o
Guia de autenticação para mais detalhes. Para corrigir esse erro, você precisa
ativar o serviço do projeto usando o Google Cloud console,
a CLI do Google Cloud ou a API Service Usage. Para saber como ativar um serviço, consulte
Como ativar e desativar serviços.
Como corrigir erros de permissão negada?
Esses erros tipicamente significam que o chamador não tem a permissão certa de gerenciamento de identidade e acesso em determinados recursos. Para informações sobre as permissões necessárias para cada uma das seguintes APIs da infraestrutura de serviços, consulte a respectiva página "Controle de acesso":
Uma nova tentativa é recomendada com intervalos exponenciais somados à aleatoriedade.
O intervalo mínimo para uma nova tentativa deve ser de 30s para erros de cota 429 e de 1s para os erros de servidor 500 e 503. Para outros erros, uma nova tentativa deve ser feita somente com base em informações adicionais sobre o erro. Consulte google.rpc.Code para mais detalhes.
Como solicitar uma cota maior da API?
Para saber como se inscrever para uma cota mais alta para cada uma das seguintes APIs da infraestrutura de serviços, visite a seção respectiva da página Cotas e limites:
Como corrigir os erros "Não é possível verificar a propriedade do nome de domínio"?
Esse erro indica que o autor da chamada não tem a propriedade do nome de domínio usado no serviço gerenciado especificado em uma configuração de serviço.
Siga o guia para usar um domínio válido.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-03 UTC."],[],[],null,["# Troubleshooting\n\nThis page contains troubleshooting information for each version of the following\nService Infrastructure APIs:\n\n- The Service Management API\n- The Service Control API\n- The Service Consumer Management API\n\n| **Note:** For Service Infrastructure troubleshooting information for the Service Usage API, see [Troubleshooting](/service-usage/docs/troubleshooting).\n\n### How do I handle Service Control API errors in general?\n\nThe Service Control API provides control plane functionality, such as\nlogging, monitoring, to managed services. Therefore, the callers of the\nService Control API typically are server applications. Here are general\nrecommendations on how to handle errors at the REST/RPC API level:\n\n- Your server should log all errors returned by the Service Control API and you can use the data to toubleshoot your [managed service](/service-infrastructure/docs/glossary#managed).\n- If your server receives `429` errors from the Service Control API, it should return `429` errors to its clients.\n- If your server cannot access the Service Control API, it can choose to either fail-open (ignore the error) or fail-close (return `503` to its client).\n- If your server receives `500` errors from the Service Control API, it should return `500` error to its clients. Such errors typically mean bugs within the Service Control API.\n- If your server receives other errors from the Service Control API, it should return `500` error to its clients. Such errors typically mean bugs within your managed service.\n\n### What does the \"service not enabled\" error mean?\n\nTo use any Google API service, you need to have a Google Cloud project,\nenable the service for that project, and pass an API key or an OAuth access\ntoken associated with the project for each API request. See\n[Auth Guide](/docs/authentication) for details. To fix this error, you need\nto enable the service for your project using the Google Cloud console,\nGoogle Cloud CLI, or Service Usage API. To learn how to enable a service, see\n[Enabling and Disabling Services](/service-usage/docs/enable-disable).\n\n### How do I fix permission denied errors?\n\nSuch errors typically mean the caller doesn't have the right\n[Identity and Access Management](/iam) permission on certain resources. For information on the\nrequired permissions for each of the following Service Infrastructure APIs, see the\nrespective Access Control page:\n\n- [Service Control API Access Control](/service-infrastructure/docs/service-control/access-control)\n- [Service Management API Access Control](/service-infrastructure/docs/service-management/access-control)\n\n### How do I perform a retry on API errors?\n\nIt is recommended to perform a retry with exponential intervals plus randomness.\nThe minimum retry interval should be 30s for `429` quota errors; 1s for `500`\nand `503` server errors. For other errors, retry should only be performed based\non additional error information. See\n[`google.rpc.Code`](https://github.com/googleapis/googleapis/blob/master/google/rpc/code.proto)\nfor more details.\n\n### How do I request higher API quota?\n\nTo learn how to apply for higher quota for each of the following\nService Infrastructure APIs, visit the respective section of the\n[Quotas and Limits](/service-infrastructure/docs/quotas) page:\n\n- [Service Control API Quota](/service-infrastructure/docs/quotas#control)\n- [Service Consumer Management API Quota](/service-infrastructure/docs/quotas#consumer)\n- [Service Management API Quota](/service-infrastructure/docs/quotas#management)\n\n### How do I fix \"Ownership for domain name cannot be verified\" errors?\n\nThis error indicates the caller does not have the ownership of the domain\nname used for the [managed service](/service-infrastructure/docs/glossary#managed) name\nspecified in a\n[service configuration](/service-infrastructure/docs/service-management/reference/rpc/google.api#google.api.Service).\nFollow the [guide](/endpoints/docs/custom-domain) to use a valid domain."]]
