Account Activity API: Enterprise

Este endpoint foi atualizado para incluir metadados de edição de Post. Saiba mais sobre esses metadados na “página de fundamentos de Edit Posts”. Este endpoint é frequentemente usado com os endpoints de Mensagens diretas. Lançamos novos endpoints de Mensagens diretas v2. Observe que as Account Activity APIs Enterprise e Premium oferecem suporte a mensagens v2 um para um, mas ainda não oferecem suporte a conversas em grupo.

Visão geral Enterprise A Account Activity API oferece a capacidade de assinar atividades em tempo real relacionadas a uma conta de usuário via webhooks. Isso significa que você pode receber Posts, Mensagens diretas e outros eventos de conta em tempo real de uma ou mais contas de sua propriedade ou às quais esteja inscrito, por meio de uma única conexão. Você receberá todas as atividades relacionadas abaixo para cada inscrição de usuário no seu registro de webhook:

Tipos de atividade
* Posts (pelo usuário) * Exclusões de Post (pelo usuário) * @menções (do usuário) * Respostas (para ou do usuário) * Retweets (pelo usuário ou do usuário) * Quote Tweets (pelo usuário ou do usuário) * Retweets de Quote Tweets (pelo usuário ou do usuário) * Likes (pelo usuário ou do usuário) * Seguir (pelo usuário ou do usuário) * Deixar de seguir (pelo usuário)	* Bloqueios (pelo usuário) * Desbloqueios (pelo usuário) * Silenciamentos (pelo usuário) * Remoções de silêncio (pelo usuário) * Mensagens diretas enviadas (pelo usuário) * Mensagens diretas recebidas (pelo usuário) * Indicadores de digitação (para o usuário) * Confirmações de leitura (para o usuário) * Revogações de inscrição (pelo usuário)

Atenção - Não entregamos dados da linha do tempo inicial por meio da Account Activity API. Use o GET statuses/home_timeline para obter esses dados.

Série de vídeos

Confira nossa série de quatro vídeos sobre a Account Activity API para se atualizar rapidamente!

Resumo de recursos

Nível	Preço	Número de assinaturas exclusivas	Número de webhooks	Confiabilidade e recuperação de atividade
Enterprise	Fale com o time de vendas	Até 500+	3+	Novas tentativas e reprodução

Tem dúvidas? Encontrando erros?
- Leia nossas perguntas frequentes ou o guia de solução de erros.
Explore nosso Exemplo de código:
- Enterprise Account Activity API dashboard, um app web em Node que exibe eventos de webhook usando o nível Enterprise da Account Activity API e inclui a funcionalidade de reprodução.
- O chatbot SnowBot, um app web em Ruby criado com as APIs Enterprise Account Activity e Direct Message.

Gerenciar webhooks e usuários inscritos

⏱ leitura de 10 min A Account Activity API Enterprise fornece mensagens JSON via webhook sempre que houver eventos associados a contas do X inscritas no seu serviço. O X entrega essas atividades ao seu webhook registrado. Nas etapas a seguir, você aprenderá a gerenciar webhooks e usuários inscritos. Você aprenderá como registrar, visualizar e remover webhooks e usuários inscritos. Usaremos comandos simples do cURL para fazer solicitações aos vários endpoints da API. O cURL é uma ferramenta de linha de comando para enviar ou obter solicitações usando a sintaxe de URL. Você vai precisar de:

Uma X App registrada - registre-se aqui
Um Bearer Token - saiba mais
Um webhook que passe no Challenge-Response Check (CRC) - saiba mais
Uma conta Enterprise - inscreva-se aqui

Antes de começar, recomendamos que você confira nosso repositório no GitHub, que fornece um app web de exemplo e scripts auxiliares para começar a usar a Account Activity API do X

Gerenciando um webhook:

Usar um webhook permite assinar atividades em tempo real relacionadas a uma conta de usuário por meio de uma única conexão.

Adicionando um webhook
Visualizando um webhook
Removendo um webhook

Vamos começar registrando uma nova URL de webhook para o contexto de aplicação fornecido.A URL será validada por meio de uma solicitação CRC antes de ser salva. Depois de registrar um webhook, certifique-se de anotar o ID do webhook, pois você precisará dele mais tarde.Copie a seguinte solicitação cURL no seu terminal após ajustar os seguintes valores:

URL <URL> por exemplo, https://yourdomain.com/webhooks/twitter/
Consumer key <CONSUMER_KEY> por exemplo, xvz1evFS4wEEPTGEFPHBog

Access token <ACCESS_TOKEN> por exemplo, 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb

curl --request POST --url 'https://api.x.com/1.1/account_activity/webhooks.json?url=<URL>' --header 'authorization: OAuth oauth_consumer_key="<CONSUMER_KEY>", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="<ACCESS_TOKEN>", oauth_version="1.0"'

Gerenciando usuários inscritos:

Depois de registrar um webhook, você pode adicionar um usuário inscrito à Account Activity API para começar a receber as atividades da conta dele.

Adicionando uma inscrição
Visualizando inscrições
Removendo uma inscrição

Vamos começar inscrevendo um usuário para que você receba todos os tipos de eventos.Copie a solicitação cURL a seguir no seu terminal após fazer as seguintes alterações:

Webhook ID <:WEBHOOK_ID>, por exemplo, 1234567890
Nome da consumer key <CONSUMER_KEY>, por exemplo, xvz1evFS4wEEPTGEFPHBog

Access token do usuário a ser inscrito <SUBSCRIBING_USER'S_ACCESS_TOKEN>, por exemplo, 370773112-GmHxMAgYyLbNEtIKZeRNFsMKPR9EyMZeS9weJAEb

curl --request POST --url https://api.x.com/1.1/account_activity/webhooks/<:WEBHOOK_ID>/subscriptions/all.json --header 'authorization: OAuth oauth_consumer_key="<CONSUMER_KEY>", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="<SUBSCRIBING_USER'S_ACCESS_TOKEN>", oauth_version="1.0"'

Ótimo trabalho! Agora você deve conseguir gerenciar seus webhooks e usuários inscritos.

Um walkthrough em vídeo da Account Activity API

Neste walkthrough em vídeo, você vai conhecer os recursos dos níveis Premium e Enterprise da Account Activity API. Ao final deste vídeo, você terá aprendido os seguintes recursos:

Registrar um webhook
Adicionar uma assinatura de usuário
Remover uma assinatura de usuário
Receber atividades da conta
Reproduzir atividades da conta

Tem dúvidas? Encontrou erros?
- Leia nossas perguntas frequentes ou o guia de solução de erros.
Explore nosso Exemplo de código:
- Enterprise Account Activity API dashboard, um app web em Node que exibe eventos de webhook usando o nível Enterprise da Account Activity API e inclui a funcionalidade de Replay.
- O SnowBot chatbot, um app web em Ruby desenvolvido com as APIs Enterprise Account Activity e Direct Message.

Enterprise

Introdução ao uso de webhooks

A Account Activity API é uma API baseada em webhooks que envia eventos de conta para um aplicativo web que você desenvolve, implanta e hospeda. Há vários detalhes de infraestrutura que exigem atenção antes que você possa começar a receber eventos de webhook no seu aplicativo consumidor de eventos. Conforme descrito abaixo, você precisará criar uma X App, obter acesso à Account Activity API e desenvolver um aplicativo web que consuma eventos de webhook.

1. Crie um X App.

Crie um X app com uma conta de desenvolvedor aprovada no portal do desenvolvedor. Se você estiver criando o app em nome da sua empresa, recomenda-se criá-lo com uma conta corporativa do X. Para solicitar uma conta de desenvolvedor, clique aqui.
Habilite “Read, Write and Access direct messages” na guia permissions da página do seu app.
Na guia “Keys and Access Tokens”, anote o Consumer Key (API Key) e o Consumer Token (API Secret) do seu app.
Na mesma guia, gere o Access Token and Access Token Secret do seu app. Você precisará desses Access Tokens para registrar a URL do seu webhook, que é para onde o X enviará eventos da conta.
Se você não estiver familiarizado com o X Sign-in e com o funcionamento de contextos de usuário na X API, consulte Obtaining Access Tokens. Ao adicionar contas para as quais deseja receber eventos, você irá assiná-las usando os access tokens dessa conta.
Anote o id numérico do seu app, conforme visto na página “Apps” do portal do desenvolvedor. Ao solicitar acesso à Account Activity API, você precisará desse app id.

2. Obter acesso à Account Activity API

Após criar uma X App, o próximo passo é solicitar acesso à Account Activity API. A Account Activity API está disponível somente no Enterprise, portanto, você precisará enviar uma solicitação usando o link abaixo.

3. Desenvolver app consumidora de webhook

Depois que você receber acesso à Account Activity API, será necessário desenvolver, implantar e hospedar um app web que receba eventos de webhook do X.

Crie um app web com uma URL para usar como seu webhook para receber eventos. Este é o endpoint implantado no seu servidor para escutar eventos de webhook do X.
- O caminho (path) da URI fica totalmente a seu critério. Este exemplo seria válido: https://mydomain.com_/service/listen_
- Se você estiver recebendo webhooks de várias fontes, um padrão comum é: https://mydomain.com/webhook/twitter
- Observe que a URL especificada não pode incluir uma porta (https://mydomain.com:5000/NoWorkie).
Conforme descrito em nosso guia Securing Webhooks, um primeiro passo é escrever código que receba uma solicitação GET de X Challenge Response Check (CRC) e responda com um JSON devidamente formatado.
Registre a URL do seu webhook. Você fará uma solicitação POST para o endpoint /webhooks.json?url=. Ao fazer essa solicitação, o X enviará uma solicitação CRC para seu app web. Quando um webhook for registrado com sucesso, a resposta incluirá um webhook id. Esse webhook id será necessário posteriormente ao fazer algumas solicitações para a Account Activity API.
O X enviará eventos de webhook de conta para a URL que você registrou. Certifique-se de que seu app web ofereça suporte a solicitações POST para eventos recebidos. Esses eventos serão codificados em JSON. Veja AQUI exemplos de payloads JSON de webhook.
Quando seu app web estiver pronto, o próximo passo é adicionar contas para as quais deseja receber atividades. Ao adicionar (ou excluir) contas, você fará solicitações POST referenciando o id da conta. Consulte nosso guia sobre como adicionar assinaturas para mais informações.

4. Validar configuração

Para validar que sua App e o webhook estão configurados corretamente, marque como favorito um Post publicado por uma das contas do X às quais sua App está inscrita. Você deverá receber um favorite_events via uma solicitação POST para a URL do seu webhook para cada favorito que seus assinantes receberem.
Observe que pode levar até 10 segundos para que os eventos comecem a ser entregues após a adição de uma assinatura.

Notas importantes

Ao registrar a URL do seu webhook, seu aplicativo web deve se autenticar com o token e o segredo de consumidor e também com o access token e o segredo de usuário do proprietário da App.
Todas as Mensagens diretas recebidas serão entregues via webhooks. Todas as Mensagens diretas enviadas via POST direct_messages/events/new (message_create) também serão entregues via webhooks. Isso permite que seu aplicativo web tenha visibilidade de Mensagens diretas enviadas por um cliente diferente.
Observe que cada evento de webhook inclui um user ID for_user_id que indica para qual assinatura o evento foi entregue.
Se você tiver dois usuários usando seu aplicativo web para Mensagens diretas na mesma conversa, seu webhook receberá dois eventos duplicados (um para cada usuário). Seu aplicativo web deve levar isso em conta.
Se você tiver mais de um aplicativo web compartilhando a mesma URL de webhook e o mesmo usuário mapeado para cada App, o mesmo evento será enviado ao seu webhook várias vezes (uma por aplicativo web).
Em alguns casos, seu webhook pode receber eventos duplicados. Seu aplicativo de webhook deve ser tolerante a isso e fazer deduplicação pelo ID do evento.
Não espere que a resposta de Quick Reply siga imediatamente uma solicitação. Um usuário pode ignorar uma solicitação de Quick Reply e responder via Mensagem direta tradicional. O usuário também pode fornecer uma resposta de Quick Reply a uma solicitação à qual não tenha respondido anteriormente na conversa.
Veja código de exemplo:
- Enterprise Account Activity API dashboard, um aplicativo web em Node que exibe eventos de webhook usando o nível Enterprise da Account Activity API e inclui funcionalidade de Replay.
- O chatbot SnowBot, um aplicativo web em Ruby desenvolvido com as APIs Account Activity e Mensagens diretas. Esta base de código inclui um script para ajudar a configurar webhooks da Account Activity API.

Protegendo webhooks

As APIs baseadas em webhook da X oferecem dois métodos para confirmar a segurança do seu servidor de webhook:

As verificações de desafio e resposta permitem que a X confirme a propriedade do aplicativo web que recebe eventos de webhook.
O cabeçalho de assinatura em cada solicitação POST permite que você confirme que a X é a origem dos webhooks recebidos.

Verificações de Desafio-Resposta

Para verificar que você é o proprietário da App e da URL do webhook, a X executará uma Verificação de Desafio-Resposta (CRC), que não deve ser confundida com uma verificação de redundância cíclica. Quando um CRC for enviado, a X fará uma solicitação GET ao seu app da web com um parâmetro crc_token. Ao receber essa solicitação, seu app da web precisará gerar um response_token criptografado com base no parâmetro crc_token e no Consumer Secret da sua App (detalhes abaixo). O response_token deve ser codificado em JSON (veja o exemplo abaixo) e retornado em até três segundos. Quando bem-sucedido, um id de webhook será retornado. Um CRC será enviado quando você registrar sua URL de webhook; portanto, implementar o código de resposta ao CRC é um primeiro passo fundamental. Depois que seu webhook estiver estabelecido, a X acionará um CRC aproximadamente a cada 24 horas a partir da última vez em que recebemos uma resposta bem-sucedida. Sua App também pode acionar um CRC quando necessário, fazendo uma solicitação PUT com o id do webhook. Acionar um CRC é útil durante o desenvolvimento da sua aplicação de webhook, após implantar novo código e reiniciar seu serviço. O crc_token deve ser diferente a cada solicitação de CRC recebida e deve ser usado como a mensagem no cálculo, em que o seu Consumer Secret é a chave. Caso a resposta não seja enviada em até 3 segundos ou se torne inválida, os eventos deixarão de ser enviados para o webhook registrado.

A solicitação de CRC ocorrerá:

Quando uma URL de webhook for registrada.
Aproximadamente a cada hora para validar sua URL de webhook.
Você pode acionar um CRC manualmente fazendo uma requisição PUT. À medida que desenvolve seu cliente de webhook, planeje acionar manualmente o CRC enquanto desenvolve sua resposta ao CRC.

Requisitos da resposta:

Um hash HMAC SHA-256 codificado em base64, criado a partir do crc_token e do Consumer Secret da sua App.
response_token válido e em formato JSON.
Latência inferior a 3 segundos.
Código de resposta HTTP 200.

Bibliotecas HMAC específicas de cada linguagem:

Exemplo de geração de token de resposta em Python:

O trecho a seguir define uma rota em um web app Flask para Python 2.7 que responderá corretamente à verificação de challenge-response.

import base64
import hashlib
import hmac
import json


\# Define uma rota para a requisição GET
@app.route('/webhooks/twitter', methods=\['GET'\])
def webhook_challenge():

  # cria hash HMAC SHA-256 a partir do token de entrada e seu consumer secret
  sha256\_hash\_digest = hmac.new(TWITTER\_CONSUMER\_SECRET, msg=request.args.get('crc_token'), digestmod=hashlib.sha256).digest()

  # constrói dados de resposta com hash codificado em base64
  response = {
    'response\_token': 'sha256=' + base64.b64encode(sha256\_hash_digest)
  }

  # retorna resposta JSON formatada corretamente
  return json.dumps(response)

Exemplo de resposta JSON:

Com a rota definida como acima, sua webapp deve retornar uma resposta semelhante à abaixo ao acessar https://your-app-domain/webhooks/twitter?crc_token=foo no seu navegador.

{
  "response_token": "sha256=x0mYd8hz2goCTfcNAaMqENy2BFgJJfJOb4PdvTffpwg="
}

Outros exemplos:

AQUI há um exemplo de método de resposta CRC escrito em Node/JS.
AQUI há um exemplo de método de resposta CRC escrito em Ruby (consulte generate_crc_response e a rota GET que recebe eventos CRC).

Validação opcional do cabeçalho de assinatura

Ao receber uma solicitação POST de X, ao enviar uma solicitação GET para criar um webhook ou ao enviar uma solicitação GET para realizar um CRC manual, uma assinatura de hash será enviada nos cabeçalhos como x-twitter-webhooks-signature. Essa assinatura pode ser usada para validar que a origem dos dados é X. A assinatura de hash do POST começa com sha256=, indicando o uso de HMAC SHA-256 para assinar seu X App Consumer Secret e o payload. O hash do GET é calculado a partir da string do parâmetro query crc_token=

token&amp;nonce=

nonce. Etapas para validar uma solicitação

Crie um hash usando seu consumer secret e o corpo do payload recebido.
Compare o hash criado com o valor x-twitter-webhooks-signature codificado em base64. Use um método como compare_digest para reduzir a vulnerabilidade a ataques por timing.

Diretrizes de segurança adicionais

A seguir estão diretrizes de segurança adicionais para considerar na sua aplicação web. A falta de implementação dessas diretrizes não impedirá o funcionamento do seu webhook, mas elas são altamente recomendadas pela equipe de Segurança da Informação da X. Se você não estiver familiarizado com as recomendações abaixo, consulte o administrador do seu servidor.

Blocos agregados de rede do X

Para maior segurança, você pode adicionar os seguintes blocos de rede agregados a uma lista de permissão:

199.59.148.0/22
199.16.156.0/22
192.133.77.0/26
64.63.15.0/24
64.63.31.0/24
64.63.47.0/24
202.160.128.0/24
202.160.129.0/24
202.160.130.0/24

Configurações de servidor recomendadas

Classificação “A” no teste do ssllabs.com
Habilite TLS 1.2
Habilite Forward Secrecy
Desative SSLv2
Desative SSLv3 (devido ao POODLE)
Desative TLS 1.0
Desative TLS 1.1
Desative a compactação TLS
Desative Session Tickets, a menos que você faça a rotação das chaves de session ticket.
Defina a opção “ssl_prefer_server_ciphers” ou “SSLHonorCipherOrder” na configuração de SSL como “on”.
Garanta que a lista de cifras seja moderna, por exemplo: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA

Gerenciamento de webhooks e assinaturas

Criando e alterando webhooks

Para alterar URLs de webhook, você deve excluir o webhook existente e então criar um novo. Observe que, ao fazer isso, será necessário readicionar as assinaturas de usuários ao novo webhook.

Endpoints de gerenciamento de configuração de webhook:


Método	Enterprise
Registra uma URL de webhook / Gera um webhook_id	POST webhooks
Retorna todas as URLs de webhook e seus statuses	GET webhooks
Exclui a configuração de webhook atual da App	DELETE webhooks/:webhook_id
Aciona manualmente uma solicitação de CRC	PUT webhooks/:webhook_id

Por que não posso simplesmente atualizar a URL do webhook?

Por que as configurações de webhook são imutáveis? A X leva a segurança muito a sério. Se a URL do seu webhook for alterada, existe a possibilidade de que a consumer key e a consumer secret da sua aplicação tenham sido comprometidas. Ao exigir a criação de uma nova configuração de webhook, você também precisa renovar a assinatura dos eventos do seu usuário. Isso exige o uso de access tokens, que é menos provável que uma parte mal-intencionada possua. Como resultado, reduz-se a probabilidade de outra parte receber informações privadas do seu usuário.

Adicionar e remover assinaturas de usuário

O suporte para milhares de assinaturas está disponível no plano Enterprise. Se você já tem um gerente de contas, entre em contato com essa pessoa em caso de dúvidas. Para solicitar acesso às APIs Enterprise, clique aqui.

Endpoints de gerenciamento de assinaturas


Método	Enterprise
Adicionar nova assinatura de usuário	POST webhooks/:webhook_id/subscriptions/all
Recuperar uma assinatura de usuário	GET webhooks/:webhook_id/subscriptions/all
Retorna uma lista de todas as assinaturas ativas	GET webhooks/:webhook_id/subscriptions/all/list
Desativa uma assinatura de usuário usando OAuth somente para aplicativo	DELETE webhooks/:webhook_id/subscriptions/:user_id/all.json

Account Activity API: Enterprise

Atenção: A X precisa habilitar o acesso à Account Activity API para sua App de desenvolvedor antes que você possa começar a usar a API. Para isso, certifique-se de compartilhar o id da App que você pretende usar para autenticação com seu gerente de conta ou equipe de suporte técnico.

A Account Activity API consiste em um conjunto de endpoints que permitem criar e gerenciar assinaturas de usuário para receber atividades de conta em tempo real de todas as suas contas assinantes por meio de uma única conexão. Há dois métodos de autenticação disponíveis com a Account Activity API (OAuth 1.0a e OAuth 2.0 Bearer Token). O método de autenticação a ser usado dependerá do endpoint que você estiver utilizando.


Descrição	Endpoint	OAuth 1.0a (contexto do usuário)	OAuth 2.0 Bearer Token (somente aplicação)
Registrar uma nova URL de webhook para o contexto de aplicação fornecido	POST account_activity/webhooks	✓
Retornar todas as URLs e seus status para a aplicação fornecida	GET account_activity/webhooks		✓
Acionar uma verificação de challenge-response (CRC) para a URL de um webhook específico	PUT account_activity/webhooks/:webhook_id	✓
Inscrever a aplicação nos eventos da conta de um usuário	POST account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Retornar a contagem de assinaturas ativas no momento	GET account_activity/subscriptions/count		✓
Verificar se uma configuração de webhook está inscrita nos eventos de um usuário	GET account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Retornar uma lista das assinaturas ativas no momento	GET account_activity/webhooks/:webhook_id/subscriptions/all/list		✓
Excluir um webhook	DELETE account_activity/webhooks/:webhook_id	✓
[OBSOLETO] Desativar uma assinatura para o contexto de usuário e aplicação fornecidos	DELETE account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Desativar uma assinatura usando OAuth somente para aplicação	DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json		✓
Reentregar atividades para um webhook	POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json		✓

*_ A autenticação requer os access tokens do usuário assinante. _ Para os endpoints que exigem autenticação com contexto de usuário do OAuth 1.0a, você precisará fornecer as seguintes credenciais para autenticar a requisição:

Consumer Keys (API Key e Secret)
Access Tokens (Access Token e Secret)

No caso dos três endpoints a seguir, você executa ações de escrita no contexto da sua aplicação (nenhum usuário do X está envolvido). Portanto, os Access Tokens que você precisa fornecer são os que pertencem à sua App de desenvolvedor. Eles podem ser gerados diretamente no portal do desenvolvedor, na aba “Keys and tokens” da sua App.

POST account_activity/webhooks: Registrar uma nova URL de webhook para o contexto de aplicação fornecido
PUT account_activity/webhooks/:webhook_id: Acionar uma verificação de resposta a desafio (CRC) para a URL de um webhook
DELETE account_activity/webhooks/:webhook_id: Excluir um webhook

Por outro lado, nos três endpoints a seguir, você faz uma solicitação que permite à sua aplicação acessar dados protegidos em nome de um usuário do X (por exemplo, Mensagens diretas). Portanto, você deve fornecer os Access Tokens pertencentes ao usuário assinante em questão. Os Access Tokens necessários podem ser obtidos usando o fluxo OAuth de 3 etapas (consulte OAuth 1.0a: how to obtain a user’s Access Tokens). Esses endpoints foram marcados com um asterisco na tabela acima (*).

POST account_activity/webhooks/:webhook_id/subscriptions/all: Assinar os eventos da conta de um usuário para a aplicação
GET account_activity/webhooks/:webhook_id/subscriptions/all: Verificar se uma configuração de webhook está inscrita nos eventos de um usuário
DELETE account_activity/webhooks/:webhook_id/subscriptions/all: Desativar uma assinatura para o contexto de usuário e de aplicação fornecidos [DESCONTINUADO]

Please note: Certifique-se de que seu App de desenvolvedor esteja habilitado para “Read, Write, and Direct Messages”. Você pode alterar essa configuração na seção Projects & Apps da sua conta de desenvolvedor, em “App permissions” para o App de desenvolvedor selecionado. Você precisará regenerar as credenciais do seu App após alterar as configurações de permissões.

Uma lista de todos os endpoints disponíveis na Account Activity API, incluindo as descrições e exemplos de solicitações cURL com exemplos de implementação de autenticação, pode ser encontrada na documentação de referência da API. Para mais informações, confira o aplicativo web de exemplo e scripts auxiliares da XDev para começar a usar a Enterprise Account Activity API.

Please note: A X precisa habilitar o acesso à Account Activity API para o seu App de desenvolvedor antes que você possa começar a usar a API. Para isso, certifique-se de compartilhar o App id que você pretende usar para fins de autenticação com seu gerente de conta ou equipe de suporte técnico.

A Account Activity API consiste em um conjunto de endpoints que permitem criar e gerenciar assinaturas de usuários para receber atividades de conta em tempo real de todas as suas contas inscritas por meio de uma única conexão. Há dois métodos de autenticação disponíveis na Account Activity API (OAuth 1.0a e OAuth 2.0 Bearer Token). O método de autenticação a ser usado depende do endpoint que você está utilizando.


Descrição	Endpoint	OAuth 1.0a (Contexto de Usuário)	OAuth 2.0 Bearer Token (somente aplicativo)
Registrar uma nova URL de webhook para o contexto de aplicativo fornecido	POST account_activity/webhooks	✓
Retornar todas as URLs e seus statuses para o aplicativo fornecido	GET account_activity/webhooks		✓
Acionar uma verificação de resposta ao desafio (CRC) para a URL de um webhook específico	PUT account_activity/webhooks/:webhook_id	✓
Inscrever o aplicativo nos eventos da conta de um usuário	POST account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Retornar a contagem de assinaturas ativas no momento	GET account_activity/subscriptions/count		✓
Verificar se uma configuração de webhook está inscrita nos eventos de um usuário	GET account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Retornar uma lista de assinaturas ativas no momento	GET account_activity/webhooks/:webhook_id/subscriptions/all/list		✓
Excluir um webhook	DELETE account_activity/webhooks/:webhook_id	✓
[DESCONTINUADO] Desativar uma assinatura para o contexto de usuário e aplicativo fornecidos	DELETE account_activity/webhooks/:webhook_id/subscriptions/all	✓ *
Desativar uma assinatura usando OAuth somente para aplicativo	DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json		✓
Reentregar atividades a um webhook	POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json		✓

*_ A autenticação requer os Access Tokens do usuário assinante. _ Para os endpoints que exigem autenticação com Contexto de Usuário do OAuth 1.0a, você precisará fornecer as seguintes credenciais para autenticar a solicitação:

Consumer Keys (API Key e Secret)
Access Tokens (Access Token e Secret)

Nos três endpoints a seguir, você executa ações de gravação no contexto do seu aplicativo (nenhum usuário do X está envolvido). Portanto, os Access Tokens que você precisa fornecer são os pertencentes à sua App de desenvolvedor. Eles podem ser gerados diretamente no portal do desenvolvedor, na guia “Keys and tokens” da sua App.

POST account_activity/webhooks: Registrar uma nova URL de webhook para o contexto de aplicação fornecido
PUT account_activity/webhooks/:webhook_id: Acionar uma verificação de resposta a desafio (CRC) para a URL de um webhook específico
DELETE account_activity/webhooks/:webhook_id: Excluir um webhook

Por outro lado, nos três endpoints a seguir, você faz uma solicitação que permite que sua aplicação acesse dados protegidos em nome de um usuário do X (por exemplo, Mensagens diretas). Portanto, você deve fornecer os Access Tokens pertencentes ao usuário assinante em questão. Os Access Tokens necessários podem ser obtidos usando o fluxo OAuth de 3 etapas (consulte OAuth 1.0a: how to obtain a user’s Access Tokens). Esses endpoints foram marcados com um asterisco na tabela acima (*).

POST account_activity/webhooks/:webhook_id/subscriptions/all: Inscrever a aplicação nos eventos da conta de um usuário
GET account_activity/webhooks/:webhook_id/subscriptions/all: Verificar se uma configuração de webhook está inscrita nos eventos de um usuário
DELETE account_activity/webhooks/:webhook_id/subscriptions/all: Desativar uma assinatura para o contexto de usuário e aplicação fornecidos [DESCONTINUADO]

Observe: Certifique-se de que seu App de desenvolvedor esteja habilitado para “Read, Write, and Direct Messages”. Você pode alterar essa configuração na seção Projects & Apps da sua conta de desenvolvedor, em “App permissions” para o App de desenvolvedor selecionado. Você precisará regerar as credenciais do seu App após alterar as configurações de permissões.

Uma lista de todos os endpoints disponíveis na Account Activity API, incluindo a descrição correspondente e exemplos de solicitações cURL com exemplos de implementação de autenticação, pode ser encontrada na documentação de referência da API. Para mais informações, confira o aplicativo web de exemplo e scripts auxiliares da XDev para começar a usar a Enterprise Account Activity API.

Tentativas

Enterprise Um dos benefícios do nível Enterprise da Account Activity API é um mecanismo de repetição para eventos de webhook. Se um código de resposta HTTP 200 “success” não for recebido, o servidor da X iniciará novas tentativas, reenviando o evento de webhook até três vezes em um período de cinco minutos. Esse serviço de repetição de eventos de webhook ajuda a garantir confiabilidade e recuperar eventos quando ocorrem problemas de rede e durante interrupções do serviço no lado do cliente e implantações.

O que são novas tentativas?

A Account Activity API oferece um recurso de repetição quando o app web do cliente não retorna uma resposta 200 “success” para um evento de webhook de atividade de conta. Quando o cliente não confirma o recebimento bem-sucedido de um evento, a X presume que o evento não foi recebido. Se uma resposta diferente de 200 for recebida, se não houver resposta em até três segundos ou se não recebermos resposta alguma, repetimos a solicitação e a mantemos aberta por três segundos. Isso significa que você tem aproximadamente cinco segundos, em duas tentativas, para responder e receber a atividade que estamos tentando enviar para a sua URL de webhook. Caso o seu servidor não responda ou retorne um erro transitório, faremos novas tentativas por cinco minutos. Haverá um total de três tentativas de repetição para confirmar a validação. Isso oferece redundância e garante que você receba todos os eventos de webhook. Observe que assinaturas com repetição receberão eventos reenviados para quaisquer/todas as atividades de todos os usuários assinados em seu webhook. Se você não confirmar a validação dentro dessas oito tentativas, a atividade não estará mais disponível via Account Activity API.

Cronograma de novas tentativas

A Account Activity API tentará novamente até três vezes ao longo de um período de cinco minutos, até que uma resposta 200 seja recebida. Consulte a tabela abaixo para mais detalhes. Após cerca de cinco minutos, a atividade não poderá ser reenviada pela Account Activity API. Você precisará usar outros endpoints do X para coletar os dados perdidos. Por exemplo, as search APIs podem ser usadas para recuperar Posts relevantes, Retweets, Quote Tweets, menções e respostas. Mensagens diretas perdidas podem ser recuperadas com este endpoint.

Linha do tempo de novas tentativas


Atividade criada, POST para a URL do webhook pela Account Activity API e ocorre timeout em três segundos.
Aguarde três segundos após o término do timeout anterior, então faça POST para a URL do webhook pela Account Activity API; ocorre timeout em três segundos.
Aguarde 27 segundos após o término do timeout anterior, então faça POST para a URL do webhook pela Account Activity API; ocorre timeout em três segundos.
Aguarde 242 segundos após o término do timeout anterior, então faça POST para a URL do webhook pela Account Activity API; ocorre timeout em três segundos.
A Account Activity API deixará de tentar fazer POST após isso. O cliente deve usar outros endpoints do X para recuperar data.

Estrutura do objeto de dados de Atividade de Conta

Objeto	Detalhes
for_user_id	Identifica o usuário assinante ao qual o evento está relacionado.
is_blocked_by	(condicional) Exibido apenas quando outro usuário menciona o seu usuário inscrito. Incluído se true apenas para eventos de menção a Post.
source	O usuário que está executando a atividade. Por exemplo, o usuário que está seguindo, bloqueando ou silenciando é o usuário de origem.
target	O usuário ao qual a atividade se aplica. Por exemplo, o usuário que está sendo seguido, bloqueado ou silenciado é o usuário de destino.

Atividades disponíveis

Tipo de mensagem	Detalhes
tweet_create_events	Payload de status de Post quando qualquer uma das seguintes ações é realizada pelo usuário da assinatura ou em relação a ele: Posts, Retweets, Respostas, @menções, QuoteTweets, Retweet de QuoteTweets.
favorite_events	Evento de favorito (like) com o usuário e o destino.
follow_events	Evento de seguir com o usuário e o destino.
unfollow_events	Evento de deixar de seguir com o usuário e o destino.
block_events	Evento de bloquear com o usuário e o destino.
unblock_events	Evento de desbloquear com o usuário e o destino.
mute_events	Evento de silenciar com o usuário e o destino.
unmute_events	Evento de reativar som com o usuário e o destino.
user_event	Eventos de revogação enviados quando um usuário remove a autorização do aplicativo e a assinatura é excluída automaticamente.
direct_message_events	Status de mensagem direta com o usuário e o destino quando uma mensagem direta é enviada ou recebida.
direct_message_indicate_typing_events	Evento de indicação de digitação em mensagem direta com o usuário e o destino.
direct_message_mark_read_events	Evento de marcação de leitura de mensagem direta com o usuário e o destino.
tweet_delete_events	Aviso de Posts excluídos para facilitar a manutenção de conformidade.

Exemplos de payload Veja abaixo exemplos de payload para cada evento de Atividade de Conta descrito na tabela acima.

tweet_create_events (Posts, Retweets, Respostas, Quote Tweets)

{
	"for_user_id": "2244994945",
	"tweet_create_events": [
	  {
		<Objeto Tweet>
	  }
	]
}

tweet_create_events (@menções)

{
	"for_user_id": "2244994945",
	"user_has_blocked": "false",
	"tweet_create_events": [
	  {
		<Objeto Tweet>
	  }
	]
}

eventos_favoritos

{
	"for_user_id": "2244994945",
	"favorite_events": [{
		"id": "a7ba59eab0bfcba386f7acedac279542",
		"created_at": "Mon Mar 26 16:33:26 +0000 2018",
		"timestamp_ms": 1522082006140,
		"favorited_status": {
			<Objeto Tweet>
		},
		"user": {
			<Objeto de Usuário>
		}
	}]
}

follow_events

{
	"for_user_id": "2244994945",
	"follow_events": [{
			"type": "follow",
			"created_timestamp": "1517588749178",
			"target": {
				<Objeto de Usuário>
			},
			"source": {
				<Objeto de Usuário>
			}
		]
	}
}

eventos_de_unfollow

{
	"for_user_id": "2244994945",
	"follow_events": [{
			"type": "unfollow",
			"created_timestamp": "1517588749178",
			"target": {
				<Objeto de Usuário>
			},
			"source": {
				<Objeto de Usuário>
			}
		]
	}
}

block_events

{
	"for_user_id": "2244994945",
	"block_events": [{
		"type": "block",
		"created_timestamp": "1518127020304",
		"source": {
			<Objeto de Usuário>
		},
		"target": {
			<Objeto de Usuário>
		}
	}]
}

unblock_events

{
	"for_user_id": "2244994945",
	"block_events": [{
		"type": "unblock",
		"created_timestamp": "1518127020304",
		"source": {
			<Objeto de Usuário>
		},
		"target": {
			<Objeto de Usuário>
		}
	}]
}

mute_events

{
	"for_user_id": "2244994945",
	"mute_events": [
		{
			"type": "mute",
		  	"created_timestamp": "1518127020304",
			"source": {
				<Objeto de Usuário>
			},
			"target": {
				<Objeto de Usuário>
			}
		}
	]
}

unmute_events

{
	"for_user_id": "2244994945",
	"mute_events": [
		{
			"type": "unmute",
		  	"created_timestamp": "1518127020304",
			"source": {
				<Objeto de Usuário>
			},
			"target": {
				<Objeto de Usuário>
			}
		}
	]
}

user_event

{
	"user_event": {
		"revoke": {
			"date_time": "2018-05-24T09:48:12+00:00",
			"target": {
				"app_id": "13090192"
			},
			"source": {
				"user_id": "63046977"
			}
		}
	}
}

direct_message_events

{
  	"for_user_id": "4337869213",
	"direct_message_events": [{
		"type": "message_create",
		"id": "954491830116155396",
		"created_timestamp": "1516403560557",
		"message_create": {
			"target": {
				"recipient_id": "4337869213"
			},
			"sender_id": "3001969357",
			"source_app_id": "13090192",
			"message_data": {
				"text": "Olá, mundo!",
				"entities": {
					"hashtags": [],
					"symbols": [],
					"user_mentions": [],
					"urls": []
				}
			}
		}
	}],
	"apps": {
		"13090192": {
			"id": "13090192",
			"name": "FuriousCamperTestApp1",
			"url": "https://x.com/furiouscamper"
		},
		"users": {},
		"3001969357": {
			"id": "3001969357",
			"created_timestamp": "1422556069340",
			"name": "Jordan Brinks",
			"screen_name": "furiouscamper",
			"location": "Boulder, CO",
			"description": "Alter Ego - X PE opiniões são minhas",
			"url": "https://t.co/SnxaA15ZuY",
			"protected": false,
			"verified": false,
			"followers_count": 22,
			"friends_count": 45,
			"statuses_count": 494,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
		},
		"4337869213": {
			"id": "4337869213",
			"created_timestamp": "1448312972328",
			"name": "Harrison Test",
			"screen_name": "Harris_0ff",
			"location": "Burlington, MA",
			"protected": false,
			"verified": false,
			"followers_count": 8,
			"friends_count": 8,
			"profile_image_url": "null",
			"statuses_count": 240,
			"profile_image_url_https": "https://abs.twimg.com/sticky/default_profile_images/default_profile_normal.png"
		}
	}
}

direct_message_indicate_typing_events

{
	"for_user_id": "4337869213",
	"direct_message_indicate_typing_events": [{
		"created_timestamp": "1518127183443",
		"sender_id": "3284025577",
		"target": {
			"recipient_id": "3001969357"
		}
	}],
	"users": {
		"3001969357": {
			"id": "3001969357",
			"created_timestamp": "1422556069340",
			"name": "Jordan Brinks",
			"screen_name": "furiouscamper",
			"location": "Boulder, CO",
			"description": "Alter Ego - X PE opiniões são minhas",
			"url": "https://t.co/SnxaA15ZuY",
			"protected": false,
			"verified": false,
			"followers_count": 23,
			"friends_count": 47,
			"statuses_count": 509,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
		},
		"3284025577": {
			"id": "3284025577",
			"created_timestamp": "1437281176085",
			"name": "Bogus Bogart",
			"screen_name": "bogusbogart",
			"protected": true,
			"verified": false,
			"followers_count": 1,
			"friends_count": 4,
			"statuses_count": 35,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/763383202857779200/ndvZ96mE_normal.jpg"
		}
	}
}

direct_message_mark_read_events

{
	"for_user_id": "4337869213",
	"direct_message_mark_read_events": [{
		"created_timestamp": "1518452444662",
		"sender_id": "199566737",
		"target": {
			"recipient_id": "3001969357"
		},
		"last_read_event_id": "963085315333238788"
	}],
	"users": {
		"199566737": {
			"id": "199566737",
			"created_timestamp": "1286429788000",
			"name": "Le Braat",
			"screen_name": "LeBraat",
			"location": "Denver, CO",
			"description": "dados de dia @X, design de noite",
			"protected": false,
			"verified": false,
			"followers_count": 299,
			"friends_count": 336,
			"statuses_count": 752,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/936652894371119105/YHEozVAg_normal.jpg"
		},
		"3001969357": {
			"id": "3001969357",
			"created_timestamp": "1422556069340",
			"name": "Jordan Brinks",
			"screen_name": "furiouscamper",
			"location": "Boulder, CO",
			"description": "Alter Ego - X PE opiniões são minhas",
			"url": "https://t.co/SnxaA15ZuY",
			"protected": false,
			"verified": false,
			"followers_count": 23,
			"friends_count": 48,
			"statuses_count": 510,
			"profile_image_url": "null",
			"profile_image_url_https": "https://pbs.twimg.com/profile_images/851526626785480705/cW4WTi7C_normal.jpg"
		}
	}
}

tweet_delete_events

{
    "for_user_id": "930524282358325248",
    "tweet_delete_events": [
{
        "status": {
            "id": "1045405559317569537",
            "user_id": "930524282358325248"
        },
        "timestamp_ms": "1432228155593"
    }
   ]
}

API de Reprodução de Atividade da Conta

Enterprise A API de Reprodução de Atividade da Conta é uma ferramenta de recuperação de dados que permite obter eventos de até cinco dias atrás. Ela deve ser utilizada para recuperar dados em cenários em que o seu servidor de webhook perde eventos — seja devido a desconexões que duram mais do que a janela de novas tentativas, seja em cenários de recuperação de desastres em que você precisa de alguns dias para restaurar seu sistema ao normal. A API de Reprodução de Atividade da Conta foi desenvolvida para qualquer cenário em que você deixe de ingerir atividades por um período. Ela entrega as atividades ao mesmo webhook usado para a entrega original em tempo real. Este produto é uma ferramenta de recuperação, e não de preenchimento retroativo, o que significa que os eventos só serão reproduzidos se uma tentativa de entrega anterior tiver ocorrido. A API de Reprodução de Atividade da Conta não pode entregar eventos referentes a um período anterior ao momento de criação da assinatura.

Usando a Account Activity Replay API

Se sua conta estiver configurada com a funcionalidade Replay, você pode fazer solicitações de forma semelhante às solicitações para a Account Activity API. É importante observar que sua solicitação deve especificar um parâmetro webhook id para indicar quais atividades do webhook você deseja reproduzir. Em outras palavras, uma solicitação de Replay pede à Account Activity Replay API que recupere eventos de uma data e hora de início até uma data e hora de término com base no webhook id e no application id. Observe que o horário deve estar em UTC. Essas atividades são entregues por meio do webhook registrado associado ao id, a uma taxa de até 2.500 eventos por segundo. Lembre-se também de que apenas um job de Replay por webhook pode estar em execução por vez, embora todas as assinaturas que estavam ativas durante a data/hora especificada nesse webhook sejam reproduzidas. Os eventos são entregues começando pelo primeiro (mais antigo) minuto do período especificado, seguindo em ordem cronológica (na medida do possível) até que o minuto final seja entregue. Nesse ponto, o Replay enviará um evento de conclusão do job ao webhook. Como trabalhamos de forma cronológica na entrega das atividades, se houver poucos ou nenhum resultado correspondente próximo ao horário de início, provavelmente haverá um intervalo antes que os primeiros resultados sejam entregues.

Limitações

Replay é uma ferramenta para recuperar facilmente atividades de até cinco dias atrás, mas não entregará eventos anteriores ao momento de criação de uma assinatura. Por exemplo, se há três dias você adicionou uma nova assinatura e executou um job de Replay com uma janela de cinco dias anteriores a hoje, você receberia apenas dados dos três dias em que essa nova assinatura esteve ativa.

Disponibilidade e tipos de dados

As atividades da Account Activity Replay API ficam disponíveis por cinco dias a partir do início da solicitação, e novos dados ficam disponíveis cerca de 10 minutos após a criação de uma determinada atividade. Você pode fazer solicitações especificando um período dentro dessa janela de cinco dias usando os parâmetros from_date e to_date na solicitação. Eventos que foram originalmente entregues antes de você ter acesso ao Replay não podem ser reproduzidos. Por exemplo, se sua conta foi habilitada para acesso à Account Activity Replay API em 1º de junho de 2019 às 15h30 (UTC), você não poderá usar o Replay para recuperar eventos anteriores a essa data e hora. Continue para a referência da Account Activity Replay API

Introdução à migração

Descontinuamos os produtos Site Streams, User Streams e a versão beta padrão do Account Activity API - DM Only em 2018. Se você usava esses produtos, certifique-se de migrar para a versão premium ou Enterprise do Account Activity API. Também descontinuamos os endpoints legados de Mensagens diretas. Se você usava esses endpoints, certifique-se de migrar para os novos endpoints de DM ou para a versão premium ou Enterprise do Account Activity API. Consulte este anúncio para saber mais. Aqui estão os endpoints que serão afetados por essas mudanças:

User Streams
Site Streams
GET direct_messages
GET direct_messages/sent
GET direct_messages/show
POST direct_messages/new
POST direct_messages/destroy

Temos novos endpoints e serviços disponíveis que oferecem acesso semelhante e, para Mensagens diretas, funcionalidades adicionais:

Account Activity API Enterprise e premium
GET direct_messages/events/list
GET direct_messages/events/show
POST direct_messages/events/new
POST direct_messages/events/destroy

Para ajudar você a realizar uma migração tranquila para esses novos endpoints e serviços, temos dois guias de migração:

Guia de migração do Account Activity API para quem está migrando de User Streams e Site Streams para nosso novo serviço baseado em webhooks
Guia de migração de Mensagens diretas para quem está migrando entre endpoints REST de Mensagens diretas

Além disso, temos uma série de vídeos sobre o Account Activity API e como começar. E, por fim, temos exemplos de código para aprofundar seu entendimento e ajudar você a começar rapidamente:

O Account Activity Dashboard é um app web de exemplo em Node.js, com scripts auxiliares para começar a usar o Account Activity API.
O SnowBot é um chatbot de exemplo que usa o Account Activity API e endpoints REST de Mensagens diretas. Ele é escrito em Ruby, usa o framework web Sinatra e é implantado no Heroku.

Guia de migração: da User Streams/Site Streams para a Account Activity API

Em 23 de agosto de 2018, aposentamos as Site Streams e as User Streams. Certifique-se de migrar para a Account Activity API. Consulte este anúncio para saber mais. Este guia foi elaborado para ajudá-lo a migrar das APIs legadas User Streams e Site Streams para sua substituta, a Account Activity API. Abaixo, você encontrará um resumo das alterações, uma lista de novos recursos, além das principais diferenças e considerações para facilitar a transição. Para obter orientações sobre a migração a partir de endpoints básicos de DM, consulte o guia de migração de Direct Message.

Resumo das alterações

A Account Activity API entregará eventos para contas autenticadas e assinadas via webhooks, em vez de uma conexão de stream, como em User Streams e Site Streams.

APIs descontinuadas

GET user GET site (incluindo streams de controle: GET site/c/:stream_id, GET site/c/:stream_id/info.json, GET site/c/:stream_id/friends/ids.json, POST site/c/:stream_id/add_user.json, POST /site/c/:stream_id/remove_user.json)

APIs substitutas

Enterprise Account Activity API - Todas as atividades

Diferenças e considerações de migração

Formato da API: A nova Account Activity API funciona de maneira diferente de User Streams e Site Streams. Você precisará ajustar seu aplicativo web para receber dados por meio de webhooks. Você pode encontrar mais informações sobre webhooks aqui. Dados disponíveis: Outra diferença importante que você notará diz respeito aos dados entregues. A X não enviará mais eventos de pessoas que você segue na X (ou seja, sua home timeline). Essa foi uma mudança intencional e não é algo que planejamos alterar daqui para frente. Confiabilidade: Diferentemente de stream, os webhooks permitem confirmação de entrega e opções de nova tentativa para atividades enviadas via POST que não chegam à URL do webhook. Isso oferece maior garantia de que o App está recebendo todas as atividades aplicáveis, mesmo que haja breves desconexões ou períodos de indisponibilidade.

Novos recursos

A Account Activity API oferece diversos novos recursos, destacando-se o fato de que agora os dados são entregues via webhooks, em vez de stream. Webhooks oferecem muitos benefícios em comparação com stream, sendo os principais a velocidade e a confiabilidade. A API enviará os dados na forma de eventos JSON assim que estiverem disponíveis, e você não precisará mais manter uma conexão ativa nem consultar o endpoint. Isso reduz a necessidade de mecanismos de redundância e aumenta a eficiência geral. Mais informações sobre webhooks podem ser encontradas na documentação técnica.

Gerenciando assinaturas de usuários

A Account Activity API permite várias assinaturas para um único webhook registrado. Isso possibilita que atividades de usuários com assinaturas sejam entregues ao mesmo local, semelhante à arquitetura de Site Streams, usando webhooks. Isso significa que você pode acompanhar as assinaturas, no que diz respeito aos seus limites de assinatura, de forma independente da conexão do webhook. Isso também permite escalar de apenas uma ou algumas assinaturas para milhares de assinaturas em um único webhook.

Como migrar

Siga as etapas abaixo para migrar facilmente da Site Streams API para a Account Activity API

Etapa 1: Decida por um pacote Dependendo de como você está operando atualmente com User Streams ou Site Streams, considere migrar para a versão Enterprise ou Premium da Account Activity API. Considere o número de apps ou usuários autorizados que você oferece suporte atualmente e dimensione adequadamente para o volume e a confiabilidade necessários. Ao decidir pelo pacote que melhor atende às suas necessidades, alguns pontos a considerar são:

Número de webhooks necessários
Assinaturas/usuários autorizados atuais/projetados gerenciados no seu app
Número atual de apps cliente X
O nível de suporte que você prefere da X (suporte via fórum ou suporte gerenciado Enterprise 1:1)
Preço de cada pacote

Etapa 2: Verifique a configuração da sua X App no portal do desenvolvedor A X App atualmente usada para User Streams ou Site Streams será listada para o usuário proprietário dentro do portal do desenvolvedor. Essa X App também pode ser usada com a Account Activity API para manter os usuários autorizados desse app. Um novo app também pode ser criado, e os usuários podem ser reautorizados para esse novo app, se desejado. Se você estiver criando um novo app em nome de uma empresa, recomenda-se criá-lo com uma conta corporativa X @handle.

Habilite “Read, Write and Access direct messages” na guia permissions da página da sua X App. *Observe que alterar essas configurações não é retroativo; quaisquer usuários autorizados manterão as permissões do momento em que foram autorizados. Se um usuário ainda não concedeu a você acesso de leitura, escrita e mensagens diretas, será necessário que esse usuário reautorize seu app.
Se você não estiver familiarizado com o X Sign-in e como os contextos de usuário funcionam com a X API, revise Obtaining Access Tokens.
Gere access tokens para o proprietário da X App na parte inferior da guia “Keys and Tokens”. Na mesma guia, anote seu Consumer Key, Consumer Secret, Access Token e Access Token Secret. Você precisará deles para usar a API.
Gere um Bearer Token usando seu Consumer Key e Consumer Secret para métodos de API application-only.

Etapa 3: Configure seus webhooks

Crie um app web com um endpoint para usar como seu webhook para receber eventos (por exemplo, https://your_domain.com/webhook/twitter ou https://webhooks.your_domain.com).
Use seu Consumer Key, Consumer Secret, Access Token e Access Token Secret ao criar seu webhook. Observe que seu endpoint deve retornar uma resposta JSON com um response_token que é um hash HMAC SHA-256 codificado em base64, criado a partir do crc_token e do Consumer Secret do seu app.
Revise a documentação Securing Webhooks, prestando atenção especial aos requisitos de Challenge Response Check (CRC).
Certifique-se de que seu webhook ofereça suporte a requisições POST para eventos recebidos e a requisições GET para o CRC.
Certifique-se de que seu webhook tenha baixa latência (menos de 3 segundos para responder a requisições POST)

Etapa 4: Valide a configuração do seu webhook

As Webhook APIs protegerão seus webhooks de duas maneiras:

- Exigir verificações de challenge response para validar que o proprietário do webhook é o proprietário do app web. - Um cabeçalho de assinatura em cada requisição POST para seu app web validar a origem.

Para verificar que você é tanto o proprietário do app web quanto da URL do webhook, a X executará um Challenge Response Check (CRC), que não deve ser confundido com uma verificação de redundância cíclica.
Uma requisição GET com um parâmetro chamado crc_token será enviada para a URL do seu webhook. Seu endpoint deve retornar uma resposta JSON com um response_token que é um hash HMAC SHA-256 codificado em base64, criado a partir do crc_token e do Consumer Secret do seu app.
Espera-se que o crc_token mude a cada requisição CRC recebida. O crc_token deve ser usado como a mensagem no cálculo, em que seu Consumer Secret é a chave.
Caso a resposta seja inválida, os eventos deixarão de ser enviados para o webhook registrado.

Etapa 5: Crie assinaturas para cada usuário autorizado de User Streams ou Site Streams Convertendo para a Account Activity API a partir de User Streams:

Gere uma lista das suas assinaturas de usuário atuais em User Streams
Configure suas novas assinaturas da Account Activity API usando a solicitação: POST account_activity/all/:env_name/subscriptions
Confirme suas assinaturas da Account Activity API usando a solicitação: _GET account_activity/all/:env_name/subscriptions/list _

Migração para a Account Activity API a partir de Site Streams: (usando control streams):

Gere uma lista das suas assinaturas atuais em Site Streams usando a solicitação: GET /1.1/site/c/:stream_id/info.json
Configure suas novas assinaturas da Account Activity API usando a solicitação: POST account_activity/all/:env_name/subscriptions
Confirme suas assinaturas da Account Activity API usando a solicitação: _GET account_activity/all/:env_name/subscriptions/list _

Registro de webhook e criação de assinaturas (sem migração de Site Streams ou User Streams)

Registre sua URL de webhook na sua App usando POST webhooks e receba um webhook_id.
Use o webhook_id retornado para adicionar assinaturas de usuário com POST webhooks/:webhook_id/subscriptions/all.

O painel do Account Activity (aplicativo de exemplo da Account Activity API)

Criamos um app de exemplo para agilizar os testes com a Account Activity API:

Baixe o aplicativo de exemplo Account Activity Dashboard aqui (ele usa Node.js)
Siga as instruções no README para instalar e iniciar o app
Depois que o aplicativo for iniciado, você pode usar a interface para configurar facilmente seu webhook e criar uma nova assinatura

Atividades disponíveis

Tipo de mensagem	Detalhes
tweet_create_events	Payload de status de Post quando qualquer uma das seguintes ações é realizada pelo usuário da assinatura ou direcionada a ele: Posts, Retweets, respostas, @menções, QuoteTweets
favorite_events	Evento de like (curtida) com o usuário e o alvo.
follow_events	Evento de seguir com o usuário e o alvo.
block_events	Evento de bloqueio com o usuário e o alvo.
mute_events	Evento de silenciar com o usuário e o alvo.
direct_message_events	Status de Mensagem Direta com o usuário e o alvo.
direct_message_indicate_typing_events	Evento de digitação em Mensagem Direta com o usuário e o alvo.
direct_message_mark_read_events	Evento de leitura de Mensagem Direta com o usuário e o alvo.

Tipos de mensagens de stream obsoletos


Linhas em branco	Linhas em branco não serão mais entregues na Account Activity API, pois eram usadas como mensagens de keep-alive em User Streams e Site Streams.
Avisos de limite	Avisos de limite não serão mais enviados para um determinado webhook. Em vez disso, os usuários podem chamar a API para obter o uso atual dos handles disponíveis. Isso será incluído no portal do desenvolvedor em algum momento no futuro.
Mensagens de desconexão	Avisos de desconexão não serão mais necessários, pois webhooks não dependem de uma conexão ativa.
Avisos de paralisação	Avisos de paralisação não serão mais necessários, pois webhooks não dependem de uma conexão ativa capaz de lidar com grandes volumes de mensagens recebidas.
Lista de amigos	Listas de amigos não serão mais enviadas proativamente. Agora haverá um endpoint REST para obter essas informações.

Tipos de eventos obsoletos


Descrição	Nome do evento	Origem	Destino	Objeto de destino
Usuário exclui um Post	delete	Usuário atual	Usuário atual	Post
Usuário seguido exclui um Post	delete	Usuário seguido	Usuário seguido	Post
Usuário remove o favorito de um Post	unfavorite	Usuário atual	Autor do Post	Post
Post do usuário tem o favorito removido	unfavorite	Usuário que removeu o favorito	Usuário atual	Post
Usuário deixa de seguir alguém	unfollow	Usuário atual	Usuário seguido	Null
Usuário cria uma List	list_created	Usuário atual	Usuário atual	List
Usuário exclui uma List	list_destroyed	Usuário atual	Usuário atual	List
Usuário edita uma List	list_updated	Usuário atual	Usuário atual	List
Usuário adiciona alguém a uma List	list_member_added	Usuário atual	Usuário adicionado	List
Usuário é adicionado a uma List	list_member_added	Usuário que adicionou	Usuário atual	List
Usuário remove alguém de uma List	list_member_removed	Usuário atual	Usuário removido	List
Usuário é removido de uma List	list_member_removed	Usuário que removeu	Usuário atual	List
Usuário assina uma List	list_user_subscribed	Usuário atual	Proprietário da List	List
A List do usuário recebe uma assinatura	list_user_subscribed	Usuário assinante	Usuário atual	List
Usuário cancela a assinatura de uma List	list_user_unsubscribed	Usuário atual	Proprietário da List	List
A assinatura da List do usuário é cancelada	list_user_unsubscribed	Usuário que cancelou a assinatura	Usuário atual	List
Usuário atualiza seu perfil	user_update	Usuário atual	Usuário atual	Null
Usuário atualiza seu status protegido	user_update	Usuário atual	Usuário atual	Null

Guia de migração de Mensagens diretas

Em 17 de setembro de 2018, descontinuamos os endpoints legados de Mensagens diretas. Se você utilizava esses endpoints, certifique-se de migrar para os novos endpoints de Mensagens diretas ou para a Account Activity API. Consulte este anúncio para saber mais. Este guia foi elaborado para ajudá-lo a migrar das APIs REST legadas de Mensagens diretas para suas substituições aprimoradas, que saíram da versão beta. Abaixo, você encontrará um resumo das alterações, uma lista de novos recursos e as principais diferenças e considerações para ajudar na transição. Os novos endpoints de Mensagens diretas já estão disponíveis para todos os desenvolvedores. Para orientação na migração de User Streams ou Site Streams, consulte o guia de migração para a Account Activity API.

Resumo das alterações
Novos recursos
Envio de Mensagens diretas
Recebimento de Mensagens diretas
Exclusão de Mensagens diretas

Resumo das alterações

Se você ainda estiver usando os seguintes endpoints de DM, será necessário migrar para os endpoints mais recentes.

Endpoint obsoleto	Nova alternativa para migração
POST direct_messages/new	POST direct_messages/events/new
GET direct_messages/show	GET direct_messages/events/show
GET direct_messages	GET direct_messages/events/list
GET direct_messages/sent	GET direct_messages/events/list
POST direct_messages/destroy	DELETE direct_messages/events/destroy

Novos recursos

Os novos endpoints da API de Mensagens diretas oferecem diversas funcionalidades e proporcionam acesso aprimorado às Mensagens diretas anteriores. Os novos recursos incluem:

Suporte a anexos de mídia (imagem, GIF e vídeo).
Possibilidade de solicitar respostas estruturadas dos usuários com uma lista de opções predefinidas.
Até 30 dias de acesso às Mensagens diretas anteriores.

Para ver a lista completa dos novos recursos de Mensagens diretas e dos novos endpoints de API, consulte a documentação técnica.

Diferenças e considerações de migração

Os novos endpoints da API se comportam de forma bastante diferente em relação aos anteriores. Apenas atualizar as URLs dos endpoints resultará em erros no seu aplicativo. Considere o seguinte ao atualizar seu aplicativo para a migração.

Novo objeto de Mensagem direta

A primeira coisa que você provavelmente notará é a nova estrutura de objeto de Mensagens diretas. Essa nova estrutura de objeto Message Create foi introduzida para dar suporte a novas funcionalidades como Quick Replies e Attachments. O novo objeto também contém um objeto de usuário mais compacto. Seu aplicativo precisará ser atualizado para lidar com essa nova estrutura de objeto ao fazer o parsing e, possivelmente, nos modelos de dados ou no armazenamento. Para a descrição de cada propriedade, consulte a documentação completa sobre o Message Create Object. Exemplo de objeto Message Create

{
      "type": "message_create",
      "id": "1234858592",
      "created_timestamp": "1392078023603",
      "initiated_via": {
        "tweet_id": "123456",
        "welcome_message_id": "456789"
      },
      "message_create": {
        "target": {
          "recipient_id": "1234858592"
        },
        "sender_id": "3805104374",
        "source_app_id": "268278",
        "message_data": {
          "text": "Blue Bird",
          "entities": {
            "hashtags": [],
            "symbols": [],
            "urls": [],
            "user_mentions": [],
          },
          "quick_reply_response": {
            "type": "options",
            "metadata": "external_id_2"
          },
          "attachment": {
            "type": "media",
            "media": {
             ...
            }
          }
        }
      }

Resumo

Estrutura totalmente nova do objeto de Mensagem Direta.
Objeto de usuário condensado.
Novas informações disponíveis (respostas de resposta rápida, anexos, etc.).

Enviando Mensagens diretas

POST direct_messages/events/new é um substituto direto para o envio de Mensagens diretas. A principal diferença deste endpoint é que todas as informações agora são enviadas como JSON no corpo da requisição POST, em vez de parâmetros POST individuais. Exemplo de requisição do Twurl

twurl -A 'Content-type: application/json' -X POST /1.1/direct\_messages/events/new.json -d '{"event": {"type": "message\_create", "message\_create": {"target": {"recipient\_id": "4534871"}, "message_data": {"text": "Olá, mundo!"}}}}'

Observe, na solicitação acima, que o content-type está definido como application/json, e não application/x-www-form-urlencoded. Além disso, se você estiver construindo a assinatura OAuth 1.0a, note que o corpo JSON não é incluído na geração da assinatura. A maioria das bibliotecas OAuth já leva isso em consideração. Se você estiver usando o twurl, certifique-se de estar usando pelo menos a versão 0.9.3.

Resumo

A mensagem é definida no corpo da requisição POST em JSON
O cabeçalho Content-Type deve ser definido como application/json
O corpo em JSON não é incluído na geração da assinatura OAuth.

Recuperando Mensagens diretas

A recuperação de Mensagens diretas passadas agora é feita com um único endpoint da API: GET direct_messages/events/list. A principal diferença neste novo endpoint é que ele retorna tanto as mensagens enviadas quanto as recebidas em ordem cronológica inversa, o que pode facilitar a reconstrução de uma conversa. No entanto, se você estiver interessado apenas em mensagens enviadas ou apenas em recebidas, será necessário pós-processar a resposta consultando a propriedade sender_id. A paginação agora é baseada em um valor de cursor, em vez do id de uma Mensagem direta. Uma propriedade cursor é retornada com cada resposta. O endpoint GET direct_messages/events/list retornará até 30 dias de mensagens passadas, independentemente de quantas mensagens existam nesse período. Quando nenhum cursor é retornado, não há mais mensagens a serem retornadas. O método para acessar Mensagens diretas individualmente com GET direct_messages/events/show permanece o mesmo, embora o objeto de Mensagem direta retornado tenha uma estrutura diferente, conforme descrito anteriormente. Por fim, o acesso em tempo real às Mensagens diretas agora é feito via webhook com a Account Activity API. Para obter orientação sobre como migrar de User Streams ou Site Streams, consulte o guia de migração para a Account Activity API.

Resumo

Mensagens enviadas e recebidas agora são retornadas no mesmo endpoint.
Retorna até 30 dias de mensagens.
Paginação baseada em cursor.
Acesso em tempo real às Mensagens Diretas via webhook.

Excluindo Mensagens diretas

Mensagens diretas agora podem ser excluídas com DELETE direct_messages/events/destroy. A interface permanece, em grande parte, a mesma, exigindo o id da mensagem a ser excluída. A principal diferença é que o endpoint agora requer uma requisição DELETE em vez de uma requisição POST. A forma como Mensagens diretas excluídas são refletidas nos clientes oficiais do X permanece a mesma. As Mensagens diretas são removidas apenas da interface do usuário do context fornecido. Outros participantes da conversa ainda podem acessar a Mensagem direta.

Resumo

Excluir uma Mensagem direta requer o id.
O novo endpoint requer uma requisição DELETE.
A forma como Mensagens diretas excluídas aparecem nos clientes oficiais do X permanece inalterada.

**Tem perguntas sobre a migração para os novos endpoints de Mensagens diretas? **Publique sua pergunta no fórum da comunidade de desenvolvedores em devcommunity.com.

Perguntas frequentes

Geral

Quais são as vantagens de usar a Account Activity API? A Account Activity API usa webhooks, o que significa que, diferentemente das streaming APIs, não exigimos que você mantenha uma conexão aberta para enviarmos informações. Webhooks também diferem das REST APIs porque você não precisa nos consultar centenas de vezes a cada 15 minutos para obter os dados que interessam. Isso aumenta a eficiência entre o usuário e seu App, pois entrega os dados quando eles acontecem. A Account Activity API oferece diversos benefícios:

Velocidade: entregamos os dados na velocidade do X.
Simplicidade: entregamos todos os eventos de uma conta por meio de uma única conexão de webhook. As atividades entregues na API incluem Posts, @menções, respostas, Retweets, Quote Tweets, Retweets de Quote Tweets, likes, Mensagens diretas enviadas, Mensagens diretas recebidas, follows, blocks e mutes.
Escala: você recebe todas as atividades de uma conta que gerencia sem ser limitado por quaisquer limites de requisições ou tetos de eventos.

A Account Activity API está disponível como sandbox premium, premium paga e oferta Enterprise, para que você possa escalar conforme precisar de mais contas para recursos de compliance ou funcionalidade adicional. Para começar, baixe trechos de Exemplo de código no GitHub. Como identifico qual nível de produto é melhor para mim? Leia nossa página de Visão geral da Account Activity API para saber mais sobre as diferenças entre as opções Premium e a opção Enterprise. Qual é a diferença entre um ambiente Premium e um webhook Enterprise? Não há diferença. Cada ambiente Premium terá seu próprio webhook_id. Preciso de ambientes de desenvolvimento, homologação e produção para a Account Activity API, isso é possível? Sim! Com os níveis pagos da Account Activity API (Premium pago e Enterprise), é possível registrar várias URLs de webhook e gerenciar assinaturas separadamente para cada uma por meio dos métodos da API. Além disso, vários apps clientes podem ser adicionados a uma allowlist para manter a autorização dos seus users atualmente autorizados. Vocês têm algum guia passo a passo sobre como configurar a Account Activity API? Na verdade, temos!

Se você está começando, recomendamos que visite nosso guia Introdução a webhooks
Acompanhe nossos scripts com suporte da X Dev:
- Account Activity API dashboard, um aplicativo web em Node que exibe eventos de webhook.
- O chatbot SnowBot, um aplicativo web em Ruby desenvolvido com as APIs de Account Activity e Mensagens diretas. Esta base de código inclui um script para ajudar a configurar webhooks da Account Activity API.

Existe uma forma de recuperar dados se nosso sistema ficar fora do ar por um período de tempo? Com os níveis pagos da Account Activity API (Premium pago e Enterprise), nosso sistema tentará novamente enviar as atividades a você várias vezes ao longo de um período de quatro horas. Se o seu sistema não responder dentro desse período de quatro horas, a atividade será perdida e você terá que usar outros endpoints REST para recuperar os dados em até 7 dias. Sugerimos que você use seus diferentes webhooks, ou ambientes, como ferramenta de redundância, e a Account Activity Replay API para garantir que você não perca nenhuma atividade se um de seus sistemas ficar fora do ar. Qual autenticação devo usar com a Account Activity API? Os métodos de autenticação exigidos para a Account Activity API são descritos por método nas páginas de referência da API. Se você está começando com a autenticação do X, recomendamos que leia esta seção. O que é uma verificação de desafio-resposta (CRC)? A verificação de resposta ao desafio (CRC) da Account Activity API é um recurso de segurança implementado para garantir que as atividades da Account Activity API sejam enviadas ao desenvolvedor correto. Ela também pode ser usada por desenvolvedores para garantir que os dados recebidos estejam vindo da X. A X enviará automaticamente um CRC para a sua URL de webhook uma vez a cada 24 horas, contando a partir da última vez em que a URL de webhook foi validada. Seu sistema deve responder com uma resposta válida em até 3 segundos para permanecer validado. Visite nossa página Securing webhooks para mais detalhes. Há algo que invalidaria imediatamente minha URL de webhook? Se ocorrer qualquer um dos seguintes, marcaremos imediatamente seu webhook como inválido:

O servidor responde a um CRC com um token incorreto. Nesse caso, nosso sistema não fará retries para enviar a atividade.
A URL de webhook está configurada com um certificado incorreto. Nesse caso, nosso sistema não fará retries para enviar a atividade.
Seu servidor retorna um código de resposta que não seja 2XX, 4XX ou 5XX.
Você especifica o uso de gzip sem realmente enviá-lo.
Você não especifica o uso de gzip, mas o envia na resposta.

Receberei atividades duplicadas se estiver inscrito em usuários que estão interagindo entre si? Sim. Se seu aplicativo web tiver assinaturas ativas para o Usuário A e o Usuário B, e o Usuário A mencionar o Usuário B em um Post, haverá duas atividades POST enviadas ao webhook registrado. Cada atividade terá um indicador “for_user_id” para mostrar a qual assinatura a atividade pertence. Quando faço uma assinatura para meu webhook, posso substituir a parte /all/ do seguinte endpoint por outros objetos de dados de atividade de conta para limitar as atividades que a API entrega? POST https://api.x.com/1.1/account_activity/all/:env_name/subscriptions.json Não, isso não é possível. No momento, temos disponível apenas o produto /all/. Existe alguma forma de usar a Account Activity API sem solicitar permissões de Mensagens diretas dos usuários? Neste momento, as permissões de Mensagens diretas são necessárias porque não há como “filtrar” as atividades de Mensagens diretas para esta API. Existe uma versão gratuita da Account Activity API? Sim, oferecemos a versão sandbox como um nível gratuito. Nossa opção de sandbox é limitada a um único webhook com, no máximo, 15 assinaturas. Você pode ler mais sobre a opção sandbox em nossa documentação. É possível usar a Account Activity API para obter Retweets de Posts que mencionam usuários inscritos? Infelizmente, isso não faz parte das atividades entregues por esta API. Para isso, sugerimos usar a Streaming API. Quais são os possíveis tipos de atividade representados por um tweet_create_event? Um payload de tweet_create_event será enviado: Se o usuário da assinatura realizar qualquer uma das seguintes ações:

Cria um Post
Faz um Retweet
Responde a um Post

Se outro usuário:

@menciona* o usuário da assinatura
Cita um Tweet criado pelo usuário da assinatura

*Observação: A Account Activity API só entrega eventos quando o usuário da assinatura receberia uma notificação da X e poderia ver o evento publicamente. Isso significa que, se a conta mencionada (@userA) segue a conta protegida (@userB), então UserA receberá uma notificação de que UserB a mencionou. Se UserA não segue UserB (e não foi aprovado por UserB), UserA não receberá uma notificação e, portanto, um tweet_create_event não seria enviado via AAA se @userA tivesse uma assinatura. Se um usuário bloqueado mencionar meu usuário inscrito, como posso identificar isso? Você verá um campo booleano user_has_blocked no nível superior da resposta JSON, definido como “true” ou “false”. Esse campo só será exposto em menções a Posts. Enterprise Como posso adicionar meu App a uma allowlist ou verificar se meu App já está na allowlist? Para gerenciar os X apps que você adicionou a uma allowlist para acesso via as APIs Enterprise, entre em contato com seu gerente de conta informando o seu app ID. Você pode encontrar seu app ID acessando a página “Apps” no portal do desenvolvedor. Se eu tiver acesso a três webhooks, posso usar três webhooks para cada um dos apps que registrei para uso Enterprise? O limite de webhooks é definido no nível da conta, não no nível do app. Se você tiver acesso a três webhooks e dois apps registrados para uso Enterprise, poderá usar dois webhooks em um app e o terceiro no outro app, mas não três em cada app. Posso especificar quais tipos de eventos serão redeliverados usando a Account Activity Replay API? Os tipos de eventos a serem redeliverados não podem ser especificados. Todos os eventos entregues dentro da janela de data e hora indicada serão redeliverados. Haverá novas tentativas se meu aplicativo falhar ao ingerir um evento da Account Activity Replay API? Não, não haverá novas tentativas. Se um aplicativo falhar ao ingerir um evento enviado pela Account Activity Replay API, outro job de Replay pode ser enviado para o mesmo período, a fim de tentar a redelivery de quaisquer eventos de Replay perdidos. O que devo fazer quando eu receber um evento de conclusão com sucesso parcial? Sugerimos anotar os timestamps dos eventos que foram recebidos e solicitar outro job de Replay para os eventos que foram perdidos. Quantos jobs da Account Activity Replay API posso ter em execução ao mesmo tempo? Apenas um job da Account Activity Replay API por webhook pode estar em execução ao mesmo tempo. Como posso diferenciar eventos da Account Activity Replay API de eventos de produção em tempo real à medida que são entregues ao meu webhook? Como a Account Activity Replay API sempre entregará eventos do passado, os eventos podem ser diferenciados dos eventos de produção em tempo real com base no timestamp do evento. Com que rapidez posso começar a usar a Account Activity Replay API para redeliver uma atividade que meu aplicativo descartou ou perdeu? Uma atividade fica disponível para redelivery cerca de 10 minutos após ser criada.

Guia de solução de erros

Código 32

Esse erro geralmente indica que algo está incorreto na solicitação, nos headers, na autorização ou na URL que você está especificando. Isso não é um erro da Account Activity API; é um erro de autorização, e a X não está recebendo a configuração adequada de OAuth nem a URL correta.

Enterprise - Certifique-se de que as consumer keys e os access tokens que você está usando pertencem a um X App registrado para uso de produtos Enterprise. Se você não tiver suas consumer keys e access tokens, ou precisar adicionar seu X App à allowlist, entre em contato com seu gerente de contas.
Se estiver autenticando com contexto de usuário, certifique-se de ter autorizado sua solicitação corretamente com os oauth_nonce, oauth_signature e oauth_timestamp apropriados.
Certifique-se de que seus access tokens tenham o nível de permissão adequado.
- Na guia ‘Keys and tokens’ no app dashboard, verifique se seus access tokens têm o nível de permissão ‘Read, write, and direct messages’ permission level.
- Se o nível de permissão dos tokens estiver definido para algo inferior a isso, acesse a guia ‘Permissions’, ajuste a permissão de acesso para ‘Read, write, and direct messages’ e, em seguida, regenere seus access tokens e secret na guia ‘Keys and tokens’.
Certifique-se de que sua URL esteja corretamente formada.
- Lembre-se de que :env_name diferencia maiúsculas de minúsculas.

Código 200 - Proibido

Premium - Certifique-se de que você tem uma conta de desenvolvedor aprovada antes de tentar fazer uma solicitação à API. Você também deve usar o :env_name correto na solicitação, que pode ser configurado na página de ambientes de desenvolvimento.
Enterprise - Certifique-se de que seu gerente de conta concedeu a você acesso à Account Activity API.
Verifique se você configurou corretamente o seu URI. Esse erro pode ocorrer se você tiver informado um URI incorreto na solicitação.

Código 214 - A URL do webhook não atende aos requisitos.

Certifique-se de que está usando HTTPS.
Sua URL de webhook pode estar malformada.
Saiba mais sobre como configurar sua URL de webhook na seção Develop webhook consumer app na página Getting started with webhooks.

Código 214 - Alta latência na requisição GET de CRC. Seu webhook deve responder em menos de 3 segundos.

Isso significa que seu servidor está lento. Certifique-se de responder ao CRC em até 3 segundos.

Código 214 - Código de resposta diferente de 200 durante a solicitação CRC via GET (por exemplo, 404, 500 etc.).

Seu servidor está fora do ar. Verifique se ele está em execução corretamente.

Código 214 - Recursos demais já foram criados.

Enterprise - Você já usou todos os seus webhooks. Use o endpoint GET webhooks com cada uma das suas Apps registradas para identificar onde seus webhooks estão distribuídos.

Código 261 - O App não pode executar ações de escrita.

O App que você está usando com a API não tem o nível de permissão adequado definido para seu access token e access token secret. Acesse a guia “Keys and tokens” no painel de X apps e verifique os níveis de permissão atribuídos ao seu access token e access token secret. Se estiver configurado como qualquer opção diferente de “Read, write and Direct Messages”, você precisará ajustar as configurações na guia “Permission” e regenerar seu access token e access token secret para aplicar as novas configurações.
Como alternativa, você pode estar tentando registrar um webhook usando autenticação somente do App, o que não é compatível. Autentique com contexto de usuário, conforme indicado nas seções de referência da API para registrar um webhook para a Enterprise Account Activity API.

Índice de referência da Account Activity API


Finalidade	Enterprise
Registra uma URL de webhook / Gera um webhook_id	POST webhooks
Retorna todas as URLs de webhook e seus statuses	GET webhooks
Aciona manualmente uma verificação de resposta ao desafio	PUT webhooks/:webhook_id
Inscreve uma App nos eventos de uma conta	POST webhooks/:webhook_id/subscriptions/all
Retorna a contagem de assinaturas ativas no momento	GET subscriptions/count
Verifica se um webhook está inscrito em uma conta	GET webhooks/:webhook_id/subscriptions/all
Retorna uma lista das assinaturas ativas no momento	GET webhooks/:webhook_id/subscriptions/all/list
Exclui o webhook	DELETE webhooks/:webhook_id
Desativa uma assinatura usando OAuth em 3 etapas (DESCONTINUADO)	DELETE webhooks/:webhook_id/subscriptions/all
Desativa uma assinatura usando OAuth apenas da aplicação	DELETE webhooks/:webhook_id/subscriptions/:user_id/all.json
Reentrega atividades para um webhook	POST replay/webhooks/:webhook_id/subscriptions/all

Account Activity API Enterprise

POST account_activity/webhooks

Registra um novo webhook URL para o contexto de aplicação fornecido. A URL será validada por meio de uma solicitação CRC antes de ser salva. Se a validação falhar, será retornada uma mensagem de erro detalhada ao solicitante. O número de webhooks permitidos é determinado pelo pacote de cobrança.

URL do recurso

https://api.x.com/1.1/account_activity/webhooks.json

Informações do recurso


Formato da resposta	JSON
Requer autenticação	Sim (context do usuário – todos os tokens de consumidor e access tokens)
Sujeito a limite de taxa	Sim
Solicitações/15 minutos (autenticação de usuário)	15
Suporte a edições de Tweet	Todos os objetos de Tweet incluirão metadados de edição de Tweet descrevendo o histórico de edições do Tweet. Consulte a página de fundamentos “Tweet edits” para mais detalhes.

Parâmetros


url (obrigatório)	URL codificada do endpoint de callback.

Exemplo de requisição

$ curl —request POST —url ‘https://api.x.com/1.1/account_activity/webhooks.json?url=https%3A%2F%2Fyour_domain.com%2Fwebhooks%2Ftwitter%2F0' —header ‘authorization: OAuth oauth_consumer_key=“CONSUMER_KEY”, oauth_nonce=“GENERATED”, oauth_signature=“GENERATED”, oauth_signature_method=“HMAC-SHA1”, oauth_timestamp=“GENERATED”, oauth_token=“ACCESS_TOKEN”, oauth_version=“1.0“‘

Respostas HTTP

Código HTTP	Mensagem
200	A URL do webhook está registrada para a App fornecida
403	Há um erro na sua solicitação. Consulte a seção de mensagens de erro abaixo.

Exemplo de resposta — sucesso

_HTTP 200_

    {
      "id": "1234567890",
      "url": "https://your_domain.com/webhook/twitter/0",
      "valid": true,
      "created_at": "2016-06-02T23:54:02Z"
    }

Mensagens de erro

Código	Mensagem
214	A URL do webhook não atende aos requisitos.
214	Muitos recursos já foram criados.
214	A URL do webhook não atende aos requisitos. Token de CRC inválido ou formato de resposta JSON inválido.
214	Alta latência na solicitação GET de CRC. Seu webhook deve responder em menos de 3 segundos.
214	Código de resposta diferente de 200 durante a solicitação GET de CRC (por exemplo, 404, 500, etc.).

HTTP 403

    {
      "errors": [
        {
          "code": 214,
          "message": "Muitos recursos já criados."
        }
      ]
    }

GET account_activity/webhooks

Retorna todas as URLs e seus statuses para a App informada. Marcamos uma URL como inválida se ela falhar na verificação de validação diária. Para reativar a URL, chame o endpoint de atualização.

URL do recurso

https://api.x.com/1.1/account_activity/webhooks.json

Informações do recurso


Formato da resposta	JSON
Requer autenticação	Sim (somente App — Bearer Token)
Sujeito a limite de taxa	Sim
Solicitações por janela de 15 min (autenticação da App)	15

Exemplo de requisição

    $ curl --request GET
     --url https://api.x.com/1.1/account_activity/webhooks.json
     --header 'authorization: Bearer TOKEN'

Exemplo de resposta

HTTP 200 OK

    [
      {
        "id": "1234567890",
        "url": "https://your_domain.com/webhook/twitter/0",
        "valid": true,
        "created_at": "2016-06-02T23:54:02Z"
      }
      {
        "id": "2468013579",
        "url": "https://your_domain2.com/webhook/twitter/0",
        "valid": true,
        "created_at": "2016-06-04T22:31:29Z"
      }
    ]

Mensagens de erro

Código	Mensagem
99	Você não tem acesso a este recurso.

PUT account_activity/webhooks/:webhook_id

Dispara a verificação de resposta ao desafio (CRC) para a URL do webhook especificado. Se a verificação for bem-sucedida, retorna 204 e reativa o webhook definindo seu status como valid.

URL do recurso

https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json

Informações do recurso


Formato da resposta	JSON
Requer autenticação	Sim (context de usuário — todos os consumidores e access tokens)
Sujeito a limite de taxa	Sim
Solicitações/ janela de 15 min (autenticação do usuário)	15

Parâmetros


webhook_id (obrigatório)	ID do webhook. Definido no caminho do recurso.

Exemplo de requisição

    $ curl --request PUT
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID.json
     --header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="ACCESS_TOKEN", oauth_version="1.0"'

Resposta

HTTP 204 OK

{ }

Mensagens de erro

Code	Message
34	O webhook não existe ou está associado a um X App diferente.
214	A URL do webhook não atende aos requisitos.
214	A URL do webhook não atende aos requisitos. Token CRC inválido ou formato de resposta JSON inválido.
214	Alta latência na solicitação GET de CRC. Seu webhook deve responder em menos de 3 segundos.
214	Código de resposta diferente de 200 durante a solicitação GET de CRC (por exemplo, 404, 500, etc.).

POST account_activity/webhooks/:webhook_id/subscriptions/all

Inscreve a App fornecida em todos os eventos no contexto de usuário informado para todos os tipos de mensagem. Após a ativação, todos os eventos do usuário solicitante serão enviados ao webhook da App via requisição POST. As assinaturas estão atualmente limitadas com base na configuração da sua conta. Se precisar adicionar mais assinaturas, entre em contato com seu gerente de conta.

URL do recurso

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json

Informações do recurso


Formato da resposta	JSON
Requer autenticação	Sim (OAuth em 3 etapas — consumer key na whitelist e access token do usuário assinante)
Com limite de taxa	Sim
Solicitações/janela de 15 min (autenticação do usuário)	500

Parâmetros


webhook_id (obrigatório)	id do webhook. Definido no caminho do recurso.

Exemplo de requisição

    $ curl --request POST
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json
     --header 'authorization: OAuth oauth_consumer_key="WHITELISTED_CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBING_USER'S_ACCESS_TOKEN", oauth_version="1.0"'

Exemplo de resposta – sucesso

HTTP 204 NO CONTENT

{}

Mensagens de erro

Código	Mensagem
34	O webhook não existe ou está associado a uma X App diferente.
348	O App cliente não tem permissão para acessar as assinaturas de webhook deste usuário.

GET account_activity/subscriptions/count

Retorna o número de assinaturas atualmente ativas na sua conta. Observe que o endpoint /count requer OAuth apenas para a aplicação; portanto, você deve fazer solicitações usando um Bearer Token em vez do contexto de usuário.

URL do recurso

https://api.x.com/1.1/account_activity/subscriptions/count.json

Informações do recurso


Formato da resposta	Código de resposta HTTP
Requer autenticação	Sim (somente App — Bearer Token)
Sujeito a limite de taxa	Sim
Solicitações por janela de 15 min (autenticação da App)	15

Códigos de resposta HTTP


Code	Message
200	Sucesso. Será retornada a contagem de assinaturas para o webhook solicitado.
401	Sua App não tem permissão para visualizar as assinaturas do webhook especificado.

Exemplo de solicitação

    $ curl --request GET
     --url https://api.x.com/1.1/account_activity/subscriptions/count.json
     --header 'authorization: Bearer TOKEN'

Exemplo de resposta — Sucesso

HTTP 200

    {
      "account_name":"minha-conta",
      "subscriptions_count_all":"1",
      "subscriptions_count_direct_messages":"0",
      "provisioned_count":"50"
    }

Mensagens de erro

Código	Mensagem
32	Não foi possível autenticar você.

HTTP 401

    {
      "errors": [
        {
           "code": 32,
          "message": "Não foi possível autenticar você."
        }
      ]
    }

GET account_activity/webhooks/:webhook_id/subscriptions/all

Fornece uma maneira de verificar se uma configuração de webhook está inscrita nos eventos do usuário informado. Se o context do usuário informado tiver uma assinatura ativa com o aplicativo fornecido, retorna 204 OK. Se o código de resposta não for 204, o usuário não terá uma assinatura ativa. Consulte os códigos de resposta HTTP e as mensagens de erro abaixo para mais detalhes.

URL do recurso

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json

Informações do recurso


Formato da resposta	JSON
Requer autenticação	Sim (OAuth de 3 etapas — consumer key na lista de permissões e access token do usuário assinante)
Com limite de taxa	Sim
Solicitações por janela de 15 min (autenticação do usuário)	500

Parâmetros


webhook_id (obrigatório)	id do webhook. Definido no caminho do recurso.

Exemplo de solicitação

$ curl —request GET —url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json —header ‘authorization: OAuth oauth_consumer_key=“WHITELISTED_CONSUMER_KEY”, oauth_nonce=“GENERATED”, oauth_signature=“GENERATED”, oauth_signature_method=“HMAC-SHA1”, oauth_timestamp=“GENERATED”, oauth_token=“SUBSCRIBING_USER’S_ACCESS_TOKEN”, oauth_version=“1.0“‘

Exemplo de resposta - sucesso

HTTP 204 NO CONTENT

{ }

GET account_activity/webhooks/:webhook_id/subscriptions/all/list

Retorna uma lista das assinaturas atuais do tipo All Activity para o webhook especificado. Observe que o endpoint /list requer OAuth somente de aplicação; portanto, as solicitações devem ser feitas usando um Bearer Token em vez do contexto de usuário.

URL do recurso

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all/list.json

Informações do recurso


Formato da resposta	Código de resposta HTTP
Requer autenticação	Sim (somente App — Bearer Token)
Limite de taxa	Sim
Solicitações/janela de 15 min (autenticação da App)	50

Parâmetros


webhook_id (obrigatório)	id do webhook. Definido no caminho do recurso.

Códigos de resposta HTTP

Código	Mensagem
200	Sucesso. Uma lista de inscrições para o webhook solicitado será retornada.
401	Seu App não tem permissão para visualizar inscrições do webhook especificado.

Exemplo de requisição

$ curl —request GET —url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all/list.json —header ‘authorization: Bearer TOKEN’

Exemplo de resposta — sucesso

HTTP 200

    {
      "webhook_id": "1234567890",
      "webhook_url": "https://your_domain.com/webhook/twitter/0",
      "application_id": "11231812",
      "subscriptions": [{
        "user_id": "20212306"
      }]
    }

Mensagens de erro

Código	Mensagem
32	Não foi possível autenticar você.

HTTP 401

    {
      "errors": [
        {
           "code": 32,
          "message": "Não foi possível autenticar você."
        }
      ]
    }

DELETE account_activity/webhooks/:webhook_id

Remove o webhook da configuração da App informada. O id do webhook pode ser obtido fazendo uma chamada GET para /1.1/account_activity/webhooks.

URL do recurso

https://api.x.com/1.1/account_activity/webhooks/:webhook_id.json

Informações do recurso


Formato da resposta	JSON
Requer autenticação	Sim (contexto do usuário — todos os consumer tokens e access tokens)
Com limite de taxa	Sim
Solicitações/Janela de 15 min (autenticação do usuário)	15

Parâmetros


webhook_id (obrigatório)	id do webhook. Definido no caminho do recurso.

Exemplo de solicitação

    $ curl --request DELETE
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID.json
     --header 'authorization: OAuth oauth_consumer_key="CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="ACCESS_TOKEN", oauth_version="1.0"'

Resposta

HTTP 204 OK

{ }

DELETE account_activity/webhooks/:webhook_id/subscriptions/all (DESCONTINUADO)

Desativa a(s) assinatura(s) para o contexto de usuário e a App fornecidos. Após a desativação, todos os eventos do usuário que fez a solicitação deixarão de ser enviados para a URL do webhook.

URL do recurso

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/all.json

Informações do recurso


Formato da resposta	JSON
Requer autenticação	Sim (OAuth de 3 etapas — consumer key em whitelist e access token do usuário inscrito)
Com limite de taxa	Sim
Solicitações/15 minutos (autenticação do usuário)	500

Parâmetros


webhook_id (obrigatório)	ID do webhook. Definido no caminho do recurso.

Exemplo de requisição

    $ curl --request DELETE
     --url https://api.x.com/1.1/account_activity/webhooks/:WEBHOOK_ID/subscriptions/all.json
     --header 'authorization: OAuth oauth_consumer_key="WHITELISTED_CONSUMER_KEY", oauth_nonce="GENERATED", oauth_signature="GENERATED", oauth_signature_method="HMAC-SHA1", oauth_timestamp="GENERATED", oauth_token="SUBSCRIBED_USER'S_ACCESS_TOKEN", oauth_version="1.0"'

Exemplo de requisição

{ }

DELETE /account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json

Desativa a assinatura para o webhook e o user id especificados. Após a desativação, todos os eventos do usuário solicitante deixarão de ser enviados para a URL do webhook. Observe que este endpoint requer OAuth somente do aplicativo (app-only), portanto, as solicitações devem ser feitas usando um Bearer Token em vez de contexto de usuário.

URL do recurso

https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json

Informações do recurso


Formato da resposta	JSON
Requer autenticação	Sim (somente App - Bearer Token)
Sujeito a limite de taxa	Sim
Solicitações/janela de 15 min	500

Exemplo de requisição

    $ curl --request DELETE
     --url https://api.x.com/1.1/account_activity/webhooks/:webhook_id/subscriptions/:user_id/all.json
     --header 'authorization: Bearer TOKEN'

Resposta

HTTP 204 NO CONTENT

Mensagens de erro

Código	Mensagem
404	Desculpe, esta página não existe. — Isso geralmente ocorre quando o id de usuário especificado não está de fato inscrito.

Replay API

POST /1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json ¶ Envia uma solicitação para recuperar atividades de até os últimos cinco dias de todas as assinaturas que existiram durante as janelas de data e hora especificadas na solicitação. Se o seu webhook tiver assinaturas de usuário ativas, você também receberá esses eventos simultaneamente. Observação: realizamos um CRC antes de entregar eventos de replay.


Request Method	HTTP POST
URL	/1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json?from_date=yyyymmddhhmm&to_date=yyyymmddhhmm
Response Format	JSON
Requires Authentication	Sim (somente aplicação - Bearer Token)
Rate Limit	5 solicitações por 15 minutos. Atualmente não há um máximo para o número de jobs de replay que podem ser solicitados.
from_date	O timestamp UTC mais antigo (inicial) a partir do qual os eventos serão fornecidos; deve estar no formato ‘yyyymmddhhmm’. O timestamp tem granularidade de minuto e é inclusivo (ou seja, 12:00 inclui o minuto 00). Os horários válidos devem estar dentro dos últimos 5 dias, em UTC, e não mais recentes que 31 minutos antes do momento atual. Recomenda-se que from_date e to_date fiquem dentro de ~2 horas.
to_date	O timestamp UTC mais recente (final) até o qual o evento será fornecido; deve estar no formato ‘yyyymmddhhmm’. O timestamp tem granularidade de minuto e é exclusivo (ou seja, 12:30 não inclui o 30º minuto da hora). Os horários válidos devem estar dentro dos últimos 5 dias, em UTC, e não mais recentes que 10 minutos antes do momento atual.

Respostas

As seguintes respostas podem ser retornadas pela API. A maioria dos códigos de erro é retornada com uma string que inclui detalhes adicionais no corpo. Para respostas diferentes de 200, você deve resolver o erro e tentar novamente.

Status	Texto	Código de erro	Descrição	Mensagem
202	Accepted	N/A	A solicitação foi bem-sucedida e as atividades serão enviadas.	N/A
400	Bad Request	214	O webhook foi marcado como inválido.	O webhook está marcado como inválido e requer uma verificação CRC.
400	Bad Request	357	O parâmetro query está ausente.	: queryParam é obrigatório.
400	Bad Request	358	A rota ou o parâmetro query está malformado.	Não foi possível analisar o parâmetro.
400	Bad Request	360	O parâmetro de rota é negativo.	webhook_id: [] não é maior ou igual a 0.
400	Bad Request	368	from_date ou to_date não está no passado.	: [<field_value>] não está no passado.
400	Bad Request	356	from_date deve ser anterior a to_date.	from_date deve ser anterior a to_date.
400	Bad Request	356	from_date deve estar dentro dos últimos 5 dias.	from_date deve estar dentro dos últimos 5 dias.
401	Unauthorized	32	A autenticação HTTP falhou devido à autenticação em 3 etapas fornecida.	Método de autenticação inválido. Use somente autenticação de aplicativo.
401	Unauthorized	61	O cliente não tem permissão para solicitar este método.	O cliente não tem permissão para solicitar este método.
403	Forbidden	200	O cliente não possui uma conta Enterprise com Replay habilitado.	É necessária uma conta Enterprise da Account Activity API com replay. Confirme se você tem uma conta Enterprise e se o replay está habilitado.
404	Not Found	34	webhook_id inexistente; incompatibilidade entre webhook_id e application_id.	O webhook não existe ou está associado a um X App diferente.
409	Conflict	355	Há uma solicitação em andamento que precisa concluir o processamento antes de fazer outra.	Um trabalho de replay já está em andamento para este webhook.
429	Too Many Requests	88	Limite de taxa atingido (atingiu o limite de solicitações por período de tempo).	Solicitações demais. Reduza a taxa de solicitações da sua API.
500	Internal Server Error	0	Erro interno do servidor.	Erro interno do servidor.
503	Service Unavailable	67	Um ou mais serviços dependentes na X estão indisponíveis.	Erro do servidor da X. Tente novamente usando um padrão de backoff exponencial.

”Mensagem “Job completed successfully””

Quando seu job for concluído com sucesso, a Account Activity Replay API entregará o seguinte evento de conclusão. Assim que você receber esse evento, o job terá terminado de ser executado e outro poderá ser enviado.

{
  "replay\_job\_status": {
    "webhook_id": "1234577122340233217",
    "job_state": "Complete",
    "job\_state\_description": "Job concluído com sucesso"
    "job_id": "1095098195724558337"
  }
}

Mensagem “Falha ao concluir o job”

Caso seu job não seja concluído com sucesso, retornaremos a seguinte mensagem, incentivando você a tentar novamente o job de Replay. Assim que receber esse evento, o job terá concluído a execução e outro poderá ser enviado.

{
  "replay\_job\_status": {
    "webhook_id": "123451374207332352",
    "job_state": "Incomplete",
    "job\_state\_description": "Falha na entrega de todos os eventos do job, tente novamente o job de replay",
    "job_id": "1093226942650736640"
  }
}

Exemplo de solicitação com curl

    curl --request POST  --url 'https://api.x.com/1.1/account_activity/replay/webhooks/:webhook_id/subscriptions/all.json?from_date=yyyymmddhhmm&to_date=yyyymmddhhmm'
    --header 'authorization: Bearer TOKEN'

Exemplo de resposta

HTTP 202

{
  "job_id": "1234567890",
  "created_at": "2016-06-02T23:54:02Z"
}

Visão geral

Posts

users

Mensagens diretas

Likes

List

Spaces

Comunidades

Notas da Comunidade

Tendências

Mídia

Uso

Conexões do stream

Conformidade

Enterprise v2

Likes Streams

GNIP 2.0

​Série de vídeos

​Resumo de recursos

​Gerenciar webhooks e usuários inscritos

​Gerenciando um webhook:

​Gerenciando usuários inscritos:

​Artigos relacionados

​Um walkthrough em vídeo da Account Activity API

​Introdução ao uso de webhooks

​1. Crie um X App.

​2. Obter acesso à Account Activity API

​3. Desenvolver app consumidora de webhook

​4. Validar configuração

​Protegendo webhooks

​Verificações de Desafio-Resposta

​A solicitação de CRC ocorrerá:

​Requisitos da resposta:

​Bibliotecas HMAC específicas de cada linguagem:

​Exemplo de geração de token de resposta em Python:

​Exemplo de resposta JSON:

​Outros exemplos:

​Validação opcional do cabeçalho de assinatura

​Diretrizes de segurança adicionais

​Blocos agregados de rede do X

​Configurações de servidor recomendadas

​Gerenciamento de webhooks e assinaturas

​Criando e alterando webhooks

​Endpoints de gerenciamento de configuração de webhook:

​Por que não posso simplesmente atualizar a URL do webhook?

​Adicionar e remover assinaturas de usuário

​Endpoints de gerenciamento de assinaturas

​Tentativas

​O que são novas tentativas?

​Cronograma de novas tentativas

​Linha do tempo de novas tentativas

​Estrutura do objeto de dados de Atividade de Conta

​tweet_create_events (Posts, Retweets, Respostas, Quote Tweets)

​tweet_create_events (@menções)

​eventos_favoritos

​follow_events

​eventos_de_unfollow

​block_events

​unblock_events

​mute_events

​unmute_events

​user_event

​direct_message_events

​direct_message_indicate_typing_events

​direct_message_mark_read_events

​tweet_delete_events

​API de Reprodução de Atividade da Conta

​Usando a Account Activity Replay API

​Limitações

​Disponibilidade e tipos de dados

​Introdução à migração

​Guia de migração: da User Streams/Site Streams para a Account Activity API

​Resumo das alterações

​APIs descontinuadas

​APIs substitutas

​Diferenças e considerações de migração

​Novos recursos

​Gerenciando assinaturas de usuários

​Como migrar

​Siga as etapas abaixo para migrar facilmente da Site Streams API para a Account Activity API

Série de vídeos

Resumo de recursos

Gerenciar webhooks e usuários inscritos

Gerenciando um webhook:

Gerenciando usuários inscritos:

Artigos relacionados

Um walkthrough em vídeo da Account Activity API

Introdução ao uso de webhooks

1. Crie um X App.

2. Obter acesso à Account Activity API

3. Desenvolver app consumidora de webhook

4. Validar configuração

Protegendo webhooks

Verificações de Desafio-Resposta

A solicitação de CRC ocorrerá:

Requisitos da resposta:

Bibliotecas HMAC específicas de cada linguagem:

Exemplo de geração de token de resposta em Python:

Exemplo de resposta JSON:

Outros exemplos:

Validação opcional do cabeçalho de assinatura

Diretrizes de segurança adicionais

Blocos agregados de rede do X

Configurações de servidor recomendadas

Gerenciamento de webhooks e assinaturas

Criando e alterando webhooks

Endpoints de gerenciamento de configuração de webhook:

Por que não posso simplesmente atualizar a URL do webhook?

Adicionar e remover assinaturas de usuário

Endpoints de gerenciamento de assinaturas

Tentativas

O que são novas tentativas?

Cronograma de novas tentativas

Linha do tempo de novas tentativas

Estrutura do objeto de dados de Atividade de Conta

tweet_create_events (Posts, Retweets, Respostas, Quote Tweets)

tweet_create_events (@menções)

eventos_favoritos

follow_events

eventos_de_unfollow

block_events

unblock_events

mute_events

unmute_events

user_event

direct_message_events

direct_message_indicate_typing_events

direct_message_mark_read_events

tweet_delete_events

API de Reprodução de Atividade da Conta

Usando a Account Activity Replay API

Limitações

Disponibilidade e tipos de dados

Introdução à migração

Guia de migração: da User Streams/Site Streams para a Account Activity API

Resumo das alterações

APIs descontinuadas

APIs substitutas

Diferenças e considerações de migração

Novos recursos

Gerenciando assinaturas de usuários

Como migrar

Siga as etapas abaixo para migrar facilmente da Site Streams API para a Account Activity API

O painel do Account Activity (aplicativo de exemplo da Account Activity API)

Atividades disponíveis

Tipos de mensagens de stream obsoletos

Tipos de eventos obsoletos

Guia de migração de Mensagens diretas

Resumo das alterações

Novos recursos

Diferenças e considerações de migração

Novo objeto de Mensagem direta

Resumo

Enviando Mensagens diretas

Resumo

Recuperando Mensagens diretas

Resumo

Excluindo Mensagens diretas

Resumo

Perguntas frequentes