> ## Documentation Index > Fetch the complete documentation index at: https://docs.x.com/llms.txt > Use this file to discover all available pages before exploring further. # Fazendo Requisições Autenticadas > Como fazer requisições autenticadas à X Ads API sobre HTTPS usando OAuth 1.0a, incluindo configuração do Twurl, verbos HTTP, parâmetros in-line e regras de URL encoding. Acessar os endpoints da X Ads API requer que sua aplicação envie requisições web autenticadas com segurança usando TLS para [https://ads-api.x.com](https://ads-api.x.com). As seções a seguir fornecerão uma visão geral de como fazer requisições autenticadas à API, configurar o [Twurl](https://github.com/twitter/twurl#getting-started) para interagir com a API e estender sua aplicação para suportar OAuth 1.0a e fazer requisições à sua conta Ads. ## Requisitos Antes de fazer requisições autenticadas à X Ads API, você precisará de: * uma [conta de desenvolvedor aprovada](/resources/fundamentals/developer-portal) * uma aplicação que tenha sido [aprovada para acesso à Ads API](/x-ads-api/introduction) * API key e secret obtidos através da [UI de gerenciamento de apps](/resources/fundamentals/developer-apps) e * [access tokens](/resources/fundamentals/authentication#obtaining-access-tokens-using-3-legged-oauth-flow) para um usuário com acesso a uma conta X Ads ## Usando a API A Advertising API é acessada em [https://ads-api.x.com](https://ads-api.x.com). A [REST API padrão](https://developer.x.com/en/docs/x-api/v1/tweets/post-and-engage/overview) e a Advertising API podem ser usadas juntas com o mesmo app cliente. A Advertising API impõe HTTPS, portanto, tentativas de acessar um endpoint com HTTP resultarão em uma mensagem de erro. A Ads API retorna JSON. Todos os identificadores são strings e todas as strings são UTF-8. A Advertising API é [versionada](/x-ads-api/fundamentals/versioning) e a versão é especificada como o primeiro elemento do path de qualquer URL de recurso. `https://ads-api.x.com//accounts` ## Verbos HTTP e códigos de resposta típicos Existem quatro verbos HTTP usados na Ads API: * **GET** recupera dados * **POST** cria novos dados, como campanhas * **PUT** atualiza dados existentes, como line items * **DELETE** remove dados. Enquanto as exclusões são permanentes, os dados excluídos ainda podem ser visualizados a partir da maioria dos métodos baseados em GET, incluindo um parâmetro explícito `with_deleted=true` ao solicitar o recurso. Caso contrário, registros excluídos retornarão um HTTP 404. Uma requisição bem-sucedida retornará uma resposta HTTP na faixa 200 junto com a resposta JSON representando o objeto ao criar, excluir ou atualizar um recurso. Ao atualizar dados com HTTP PUT, apenas os campos especificados serão atualizados. Você pode remover um valor opcional especificando o parâmetro com uma string vazia. Como exemplo, este grupo de parâmetros removeria qualquer `end_time` já especificado: `&end_time=&paused=false`. Consulte [Códigos de Erro e Respostas](/x-ads-api/fundamentals/error-codes-and-responses) para mais detalhes sobre respostas de erro. ## Parâmetros in-line A maioria das URLs de recursos possui um ou mais parâmetros in-line. Muitas URLs também aceitam parâmetros declarados explicitamente na query string ou, para requisições POST ou PUT, no body. Parâmetros in-line são indicados por dois pontos ":" prefixados na seção **Resource Path** de cada recurso. Por exemplo, se a conta em que você estava trabalhando fosse identificada como `"abc1"` e você estivesse [recuperando as campanhas associadas a uma conta](/x-ads-api/campaign-management/reference#campaigns), você acessaria essa lista usando a URL `https://ads-api.x.com/6/accounts/abc1/campaigns`. Ao especificar o parâmetro in-line `account_id` descrito na URL do recurso (`https://ads-api.x.com/6/accounts/:account_id/campaigns`), você restringiu a requisição a objetos associados apenas a essa conta. ## Usando access tokens A X Ads API usa requisições HTTPS assinadas para validar a identidade de uma aplicação e também obter as permissões concedidas ao usuário final em nome do qual a aplicação está fazendo a requisição à API, representado pelo access token do usuário. Todas as chamadas HTTP à Ads API devem incluir um header de Authorization (usando OAuth 1.0a) sobre o protocolo HTTPS. Você precisará adicionar suporte para gerar headers de Authorization OAuth 1.0a à sua aplicação para se integrar à X Ads API. No entanto, devido à complexidade de gerar requisições assinadas, recomendamos fortemente que os parceiros usem uma biblioteca existente que suporte a X API ou implemente o tratamento de requisições OAuth 1.0a - aqui está uma lista de [bibliotecas OAuth recomendadas](/resources/fundamentals/authentication#oauth-1-0a-2) e [exemplos de código de autenticação](/resources/fundamentals/authentication#oauth-1-0a-2). Observe que podemos ajudar parceiros que encontrarem erros de autenticação ao usar uma biblioteca conhecida, mas não podemos oferecer suporte a implementações OAuth personalizadas. ## HTTP e OAuth Como a X REST API v1.1, a Advertising API requer o uso de [OAuth 1.0A](/resources/fundamentals/authentication) e HTTPS. As API keys podem ser obtidas através do [console de gerenciamento de apps](/resources/fundamentals/developer-apps). Access tokens também devem ser usados para representar o "current user". O current user é uma conta X com capacidades de publicidade. Recomendamos fortemente que os parceiros usem uma biblioteca OAuth em vez de escrever a própria. Podemos oferecer suporte à depuração ao usar uma biblioteca conhecida, mas não se você criar sua própria implementação OAuth. Consulte as [bibliotecas](/resources/fundamentals/authentication#oauth-1-0a-2) que você pode usar. A API é rigorosa com HTTP 1.1 e OAuth. Certifique-se de estar [codificando caracteres reservados](https://tools.ietf.org/html/rfc3986#section-2.2) apropriadamente dentro de URLs e bodies POST antes de preparar strings de base de assinatura OAuth. A Advertising API em particular usa caracteres ":" ao especificar tempo e caracteres "," ao fornecer uma coleção de opções. Ambos os caracteres estão entre este conjunto reservado: | Símbolo | URL Encoded | | :------ | :---------- | | ! | %21 | | # | %23 | | \$ | %24 | | & | %26 | | ' | %27 | | ( | %28 | | ) | %29 | | \* | %2A | | + | %2B | | , | %2C | | / | %2F | | : | %3A | | ; | %3B | | = | %3D | | ? | %3F | | @ | %40 | | \[ | %5B | | ] | %5D | ## Fazendo sua primeira requisição à API com Twurl O X ajuda a manter uma ferramenta de linha de comando, [Twurl](https://developer.x.com/en/docs/tutorials/using-twurl), que suporta headers de autorização OAuth 1.0a como alternativa ao [cURL](https://en.wikipedia.org/wiki/CURL). O Twurl fornece uma forma simples de fazer requisições autenticadas à API e explorar a Ads API antes de adicionar autenticação à sua aplicação. Depois de [instalar e autorizar o Twurl](https://github.com/twitter/twurl#getting-started), você pode gerar rapidamente access tokens e fazer requisições autenticadas à Ads API. ```bash theme={null} twurl -H "ads-api.x.com" "/5/accounts/" ``` Reserve um tempo para se familiarizar com o Twurl e a API seguindo este [tutorial passo a passo](/x-ads-api/campaign-management/reference#creating-a-campaign-step-by-step) para criar uma campanha através da API. ## Testando com Postman Para aqueles que não estão familiarizados com uma ferramenta de linha de comando, também fornecemos uma coleção Postman para os endpoints da X Ads API. [Postman](https://www.getpostman.com/products) é uma das ferramentas de desenvolvimento de API mais populares que existem atualmente na indústria. É um cliente HTTP com uma ótima interface de usuário que facilita fazer uma requisição de API complexa e aumenta a produtividade. Para instalar o Postman e começar a usar a coleção Postman da Ads API, consulte nosso [guia de configuração](https://github.com/xdevplatform/postman-twitter-ads-api#installation). ### Estendendo sua aplicação para fazer requisições autenticadas Depois de se familiarizar com fazer requisições à Ads API usando o Twurl, é hora de adicionar suporte para criar headers de autenticação OAuth 1.0a à sua aplicação. Os headers de autenticação [OAuth 1.0a](/resources/fundamentals/authentication) incluem informações que verificam tanto a identidade da aplicação quanto do usuário e também previnem adulteração da requisição. Sua aplicação precisará criar um novo header de Authorization para cada requisição à API. Muitas linguagens têm bibliotecas open source que suportam a criação desse header de autorização para fazer requisições à API do X. Aqui estão alguns exemplos usando C#, PHP, Ruby e Python - [exemplos de código](/resources/fundamentals/authentication#oauth-1-0a-2). ## Implementação personalizada Existem alguns cenários que exigem implementar autenticação OAuth 1.0a sem o suporte de uma biblioteca open-source. [Autorizando uma requisição](/resources/fundamentals/authentication#authorizing-a-request) fornece instruções detalhadas para implementar suporte para criar o header de Authorization. Recomendamos fortemente usar uma biblioteca suportada pela comunidade. Esboço geral: 1. Colete 7 pares chave/valor para o header - começando com oauth\_ 2. Gere uma [assinatura OAuth 1.0a HMAC-SHA1](/resources/fundamentals/authentication#creating-a-signature) usando esses pares chave/valor 3. Construa o [header de Authorization](/resources/fundamentals/authentication#authorizing-a-request) usando os valores acima