Como decodificar um Snowflake ID do Twitter

#Decodifique um Snowflake ID em uma data

O horário de criação de um tweet está escrito no ID dele, então você pode lê-lo sem buscar o post: descarte os 22 bits mais baixos do ID, some a época do X e você tem o horário Unix em UTC, exato até o milésimo de segundo, mais fino que o minuto que o X mostra embaixo de um post. Funciona também com posts apagados, desde que você tenha o ID, e o Conversor de ID de tweet em data gratuito faz isso para um ID ou para uma lista inteira.

1. Copie o ID. Em um link de post como x.com/<username>/status/2110301305616889042, o ID é o número depois de status/. O mesmo número abre o post sozinho em x.com/i/web/status/ seguido do ID.

2. Descarte os 22 bits mais baixos. 2110301305616889042 >> 22 dá 503135038761: o tempo entre a época do X e o post, em milésimos de segundo. Dividir por 2^22 e arredondar para baixo dá o mesmo número.

3. Some a época. 503135038761 + 1288834974657 = 1791970013418, um horário Unix em milésimos de segundo: 1791970013,418 em segundos.

4. Leia como data. 1791970013,418 é quarta-feira, 14 de outubro de 2026, 09:26:53,418 UTC. Converta para o seu fuso para exibir: o X mostra a cada leitor o horário no fuso local dele.

Cole qualquer ID de post, ID de usuário ou link de post no decodificador para ver a data e as quatro partes.

A mesma aritmética em código. Os inteiros do Python guardam os 64 bits; em JavaScript use BigInt, porque um número comum arredonda um ID de 19 dígitos.

from datetime import datetime, timezone

EPOCH = 1288834974657  # ms: November 4, 2010, 01:42:54.657 UTC


def snowflake_to_datetime(snowflake_id):
    ms = (int(snowflake_id) >> 22) + EPOCH
    return datetime.fromtimestamp(ms / 1000, tz=timezone.utc)


print(snowflake_to_datetime("2110301305616889042"))
# 2026-10-14 09:26:53.418000+00:00

const EPOCH = 1288834974657n;

function snowflakeToDate(id) {
  // BigInt keeps all 19 digits; Number("2110301305616889042")
  // would turn the ID into 2110301305616889000
  const ms = (BigInt(id) >> 22n) + EPOCH;
  return new Date(Number(ms));
}

console.log(snowflakeToDate("2110301305616889042").toISOString());
// 2026-10-14T09:26:53.418Z

Em um banco de dados que guarda IDs como inteiros de 64 bits, o mesmo deslocamento roda dentro da consulta:

-- PostgreSQL, id stored as BIGINT
SELECT id,
       to_timestamp(((id >> 22) + 1288834974657) / 1000.0) AS created_utc
FROM posts;

-- BigQuery, id stored as INT64
SELECT id,
       TIMESTAMP_MILLIS((id >> 22) + 1288834974657) AS created_utc
FROM dataset.posts;

O conversor também aceita uma coluna inteira de IDs de uma vez, baixa os resultados em CSV e transforma uma data de volta em um ID, tudo no seu navegador.

#Datas de IDs antigos e de listas longas, com a Sorsa API

A aritmética falha em dois tipos de ID: posts de antes de 4 de novembro de 2010 e contas abertas antes de fevereiro de 2016. Esses IDs foram numerados um a um e não guardam horário, então a fórmula devolve um instante a poucos segundos da época, que parece plausível e está errado. Para esses IDs, e sempre que você quiser o created_at do próprio X ao lado do horário decodificado, consulte os IDs em lotes.

Para datar IDs de tweets em massa, inclusive os antigos, use a Sorsa API, uma API e scraper do Twitter (X) para dados públicos: o POST /tweet-info-bulk devolve o created_at de até 100 IDs de posts por requisição, a partir de US$ 0,014 por 1.000 posts, contra US$ 5,00 por 1.000 na API oficial do X. As contas passam pelo GET /info-batch pelo mesmo valor, 100 por requisição, onde o X cobra US$ 10,00 por 1.000.

1. Pegue uma chave. Cadastre-se e copie sua chave de API no painel. A conta vem com 100 requisições grátis, sem cartão.

2. Envie até 100 IDs de posts. Passe IDs ou links completos em tweet_links para o POST /tweet-info-bulk (abre em uma nova aba); cada post volta inteiro, com o perfil do autor.

   curl -X POST "https://api.sorsa.io/v3/tweet-info-bulk" \
     -H "ApiKey: YOUR_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"tweet_links": ["1243617904", "2110301305616889042"]}'
   

   {
     "tweets": [
       {
         "id": "1243617904",
         "created_at": "2009-02-24T19:51:06Z",
         "full_text": "Field notes from the harbor survey are up on the site",
         "likes_count": 4,
         "user": {
           "id": "20536157",
           "username": "lanternbay_research",
           "created_at": "2009-02-10T16:22:31Z"
         }
       },
       {
         "id": "2110301305616889042",
         "created_at": "2026-10-14T09:26:53Z",
         "full_text": "New dataset: ten years of harbor traffic, in one CSV",
         "likes_count": 212,
         "user": {
           "id": "1427632226255384585",
           "username": "copperfield_signals",
           "created_at": "2021-08-17T14:03:41Z"
         }
       }
     ]
   }
   

   Ver resposta completa

3. Date as contas do mesmo jeito. Repita user_ids uma vez por conta, até 100, no GET /info-batch (abre em uma nova aba); cada perfil traz o próprio created_at.

   curl -G "https://api.sorsa.io/v3/info-batch" \
     -H "ApiKey: YOUR_API_KEY" \
     --data-urlencode "user_ids=20536157" \
     --data-urlencode "user_ids=1427632226255384585"
   

4. Gaste requisições só onde a decodificação não ajuda. O script lê post_ids.csv, decodifica todo Snowflake de graça e envia só os IDs mais antigos para a API, depois grava uma data por ID.

   import csv
   from datetime import datetime, timezone
   
   import requests
   
   BASE = "https://api.sorsa.io/v3"
   HEADERS = {"ApiKey": "YOUR_API_KEY"}
   EPOCH = 1288834974657           # Twitter's epoch, Unix ms
   
   
   def decode(post_id):
       """The UTC time inside a Snowflake ID; None for an older ID."""
       if len(post_id) < 15:       # counted ID from before Nov 4, 2010
           return None
       ms = (int(post_id) >> 22) + EPOCH
       return datetime.fromtimestamp(ms / 1000, tz=timezone.utc)
   
   
   def look_up(post_ids):
       """created_at from Sorsa API, 100 post IDs per request."""
       found = {}
       for i in range(0, len(post_ids), 100):
           r = requests.post(f"{BASE}/tweet-info-bulk", headers=HEADERS,
                             json={"tweet_links": post_ids[i:i + 100]},
                             timeout=30)
           r.raise_for_status()
           for tweet in r.json().get("tweets", []):
               found[tweet["id"]] = tweet["created_at"]
       return found
   
   
   with open("post_ids.csv", newline="", encoding="utf-8") as f:
       ids = [row["post_id"].strip() for row in csv.DictReader(f)]
   
   decoded = {i: decode(i) for i in ids}
   looked_up = look_up([i for i, d in decoded.items() if d is None])
   
   with open("post_dates.csv", "w", newline="", encoding="utf-8") as f:
       out = csv.writer(f)
       out.writerow(["post_id", "created_at_utc", "source"])
       for i in ids:
           if decoded[i]:
               out.writerow([i, decoded[i].isoformat(), "decoded"])
           else:
               out.writerow([i, looked_up.get(i, ""), "looked up"])
   

Um post apagado ou protegido não volta, então a linha dele fica vazia: associe os resultados pelo id, nunca pela posição. Um 403 significa que a chave está ausente ou sem requisições, um 429 que você passou de 20 requisições em um segundo, e requisições com falha nunca são cobradas.

Consultar IDs antigos de posts custa US$ 5,00 por 1.000 na API oficial do X, que cobra cada post devolvido, e a partir de US$ 0,014 por 1.000 na Sorsa API, que cobra a requisição e coloca 100 posts em cada uma.

Frente à API oficial do X, a Sorsa API sai na frente em cada ponto de que esse trabalho precisa:

• Preço por 1.000 posts

  Sorsa API

  a partir de US$ 0,014

  API oficial do X

  US$ 5,00

• Preço por 1.000 contas

  Sorsa API

  a partir de US$ 0,014

  API oficial do X

  US$ 10,00

• IDs por requisição

  Sorsa API

  100 posts ou 100 contas

  API oficial do X

  100, cobrados um a um

• Posts de antes de novembro de 2010

  Sorsa API

  sim, com created_at

  API oficial do X

  sim, pelo mesmo preço por post

• Configuração

  Sorsa API

  uma chave de API em um header

  API oficial do X

  conta de desenvolvedor, app, bearer token

• Velocidade

  Sorsa API

  20 requisições por segundo em todos os planos

  API oficial do X

  rate limits por janela de 15 minutos

• Volume

  Sorsa API

  sem teto de leitura de posts; planos maiores conforme você cresce

  API oficial do X

  3 milhões de leituras de posts por mês, depois Enterprise a partir de cerca de US$ 42 mil por mês

• Seu login do X

  Sorsa API

  nunca pedido

  API oficial do X

  a conta de desenvolvedor fica na sua conta do X

Os preços da API oficial do X estão na página de preços (abre em uma nova aba) dela; a comparação completa está no nosso guia de preços da API do X. Para timelines inteiras e buscas desde 2006, veja dados históricos do Twitter.

#O que os 64 bits de um Snowflake ID guardam

Um Snowflake ID é um inteiro de 64 bits dividido em quatro campos: um timestamp de 41 bits, um número de datacenter de 5 bits, um número de worker de 5 bits e uma sequência de 12 bits, com o bit mais alto sempre 0 para o número continuar positivo. O layout vem do gerador do próprio Twitter, lançado em 2010 e mantido no código-fonte snowflake-2010 (abre em uma nova aba), que monta cada ID como ((time - epoch) << 22) | (datacenter << 17) | (worker << 12) | sequence.

Cada campo pode ser lido com um deslocamento e uma máscara:

• 63

  Largura

  1

  Campo

  Sinal, sempre 0

  Como ler

  Valor de exemplo

  0

• 62 a 22

  Largura

  41

  Campo

  Tempo desde a época, em 1/1000 s

  Como ler

  id >> 22

  Valor de exemplo

  503135038761

• 21 a 17

  Largura

  5

  Campo

  Datacenter (0 a 31)

  Como ler

  (id >> 17) & 31

  Valor de exemplo

  11

• 16 a 12

  Largura

  5

  Campo

  Worker (0 a 31)

  Como ler

  (id >> 12) & 31

  Valor de exemplo

  7

• 11 a 0

  Largura

  12

  Campo

  Sequência (0 a 4.095)

  Como ler

  id & 4095

  Valor de exemplo

  1234

A época. 1288834974657 é a constante twepoch desse arquivo de código-fonte: quinta-feira, 4 de novembro de 2010, 01:42:54,657 UTC. O Snowflake conta a partir daí em vez de 1970, o que deixa mais dos 41 bits para o futuro. O campo comporta 2^41 milésimos de segundo, cerca de 69,7 anos, e se esgota em 10 de julho de 2080 às 17:30:30,208 UTC.

Os outros 22 bits. O README (abre em uma nova aba) de 2010 do Twitter descreve 10 bits de ID de máquina, até 1.024 máquinas, que o código divide em datacenter e worker. A sequência de 12 bits numera os IDs que uma máquina entrega dentro do mesmo milésimo de segundo, até 4.096 deles. O X nunca documentou o que significam os números atuais de datacenter e worker, então trate-os como rótulos, não como dados.

Ordem. Como o tempo fica nos bits mais altos, um ID maior quase sempre significa um post mais novo. O README prometia ordem com precisão de cerca de um segundo entre máquinas, e o guia de IDs do X (abre em uma nova aba) chama os IDs de aproximadamente ordenados no tempo por esse motivo: dois posts feitos no mesmo segundo em máquinas diferentes podem sair fora de ordem.

Outras plataformas copiaram o design com uma época própria, então um ID de outro serviço, decodificado com a época do X, cai anos longe da data real.

#Quais IDs do X são Snowflakes, e desde quando

Os IDs de posts viraram Snowflakes em 4 de novembro de 2010; os IDs de usuários, listas e buscas salvas vieram em 1º de fevereiro de 2016. O próprio X anunciou a segunda mudança em um post no fórum de desenvolvedores de 23 de novembro de 2015 (abre em uma nova aba): a partir de 1º de fevereiro de 2016, todos os novos usuários, listas e buscas salvas recebem Snowflake IDs de 64 bits, posts e DMs já os têm, e os IDs existentes continuam válidos.

Duas datas mais antigas causam a maior parte da confusão. Em janeiro de 2013, o blog de desenvolvedores do Twitter anunciou os IDs de usuário de 64 bits (abre em uma nova aba), ativados em 21 de outubro de 2013. Essa mudança só deixou o contador passar de 32 bits; as contas continuaram recebendo IDs sequenciais até 2016. Páginas que põem a mudança dos usuários "por volta de 2020" também estão erradas: uma conta aberta em meados de 2016 já tem um Snowflake de 18 dígitos.

• Post (tweet)

  Snowflake ID desde

  4 de novembro de 2010

  Decodifica em uma data

  sim, para IDs de 15 dígitos ou mais

• Mensagem direta

  Snowflake ID desde

  até novembro de 2015

  Decodifica em uma data

  sim, para IDs de 15 dígitos ou mais

• Conta de usuário

  Snowflake ID desde

  1º de fevereiro de 2016

  Decodifica em uma data

  sim para IDs de 18 e 19 dígitos, não para contas mais antigas

• Lista, busca salva

  Snowflake ID desde

  1º de fevereiro de 2016

  Decodifica em uma data

  sim para os IDs mais novos e mais longos

• Space

  Snowflake ID desde

  nunca

  Decodifica em uma data

  não: os IDs de Spaces são letras e dígitos, como 1YqGodQbNXDxv

Bom saber

Um ID sequencial decodifica sem erro, e essa é a armadilha. O ID de usuário de exemplo do próprio X, 2244994945, vira 4 de novembro de 2010, 01:42:55 UTC, menos de um segundo depois da época, e o primeiro post de todos, o ID 20, decodifica na própria época. Qualquer resultado nas primeiras horas de 4 de novembro de 2010 significa que o ID não guarda data.

Para o horário de cadastro de uma conta ao segundo, leia o created_at de uma consulta de perfil mesmo quando o ID é um Snowflake: o X não documenta em que momento do cadastro ele carimba o ID. Sem código, o Verificador de idade de conta do Twitter gratuito mostra a data de entrada de qualquer conta.

#Qual a idade de um ID? Conte os dígitos

Um Snowflake ID ganha um dígito toda vez que o relógio dentro dele cruza uma potência de dez, então só o comprimento já diz mais ou menos quando ele foi criado. Os IDs de posts têm 19 dígitos desde 25 de maio de 2018 e ficam em 19 até o campo se esgotar em 2080, porque o bit mais alto é sempre 0.

• até 11

  IDs de posts

  antes de 4 de novembro de 2010: sequenciais, sem data dentro

  IDs de contas

  antes de fevereiro de 2016: sequenciais, sem data dentro

• 15

  IDs de posts

  4 a 6 de novembro de 2010

  IDs de contas

  nenhum

• 16

  IDs de posts

  6 de novembro a 1º de dezembro de 2010

  IDs de contas

  nenhum

• 17

  IDs de posts

  1º de dezembro de 2010 a 7 de agosto de 2011

  IDs de contas

  nenhum

• 18

  IDs de posts

  7 de agosto de 2011 a 25 de maio de 2018

  IDs de contas

  1º de fevereiro de 2016 a 25 de maio de 2018

• 19

  IDs de posts

  desde 25 de maio de 2018

  IDs de contas

  desde 25 de maio de 2018

O comprimento também é o motivo de IDs quebrarem em JavaScript e em planilhas. Todo ID de post criado desde 28 de novembro de 2010 é maior que 2^53, o maior inteiro que um número do JavaScript guarda com exatidão, e é por isso que o guia de IDs do X manda manter os IDs como strings. Nosso guia do ID de usuário do Twitter a partir do username mostra o que o Excel e o JavaScript fazem com um ID e como guardá-lo com segurança.

#Transforme uma data em um ID para since_id e max_id

A fórmula roda ao contrário: subtraia a época de um horário Unix em milésimos de segundo e desloque o resultado 22 bits para a esquerda, e você tem o menor ID que o X poderia ter criado naquele instante. Ele não pertence a nenhum post; marca um ponto no tempo que a busca do X entende.

A sintaxe de busca do X aceita dois marcadores assim: since_id: devolve posts mais novos que um ID, e max_id: devolve posts até um ID, inclusive. Para a hora entre 09:00 e 10:00 UTC de 14 de outubro de 2026, o limite inferior é (1791968400000 - 1288834974657) << 22, que dá 2110294538449846272, e o limite superior é o ID das 10:00 menos 1, 2110309637944246271. O POST /search-tweets (abre em uma nova aba) da Sorsa API aceita a mesma sintaxe:

Q="from:lanternbay_research since_id:2110294538449846272"
Q="$Q max_id:2110309637944246271"
curl -X POST "https://api.sorsa.io/v3/search-tweets" \
  -H "ApiKey: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"query\": \"$Q\", \"order\": \"latest\"}"

Cada página devolve cerca de 20 posts com um next_cursor; envie-o de volta no corpo até ele voltar vazio. Guarde o ID mais novo que você já tem e passe-o como since_id: na execução seguinte, e um job agendado nunca busca o mesmo post duas vezes. Para segundos inteiros, since_time: e until_time: aceitam segundos Unix no lugar de IDs; os demais operadores de data estão na nossa lista de operadores de busca do Twitter.

#Date seus primeiros IDs

Um Snowflake ID do Twitter data a si mesmo: desloque-o 22 bits para a direita, some 1288834974657 e você tem o horário de criação, ao milésimo de segundo, de qualquer post desde 4 de novembro de 2010 e de qualquer conta desde fevereiro de 2016. Para tudo que é mais antigo, ou para pôr o created_at do próprio X ao lado de milhares de IDs, o /tweet-info-bulk da Sorsa API lê 100 posts por requisição a partir de US$ 0,014 por 1.000, com uma chave de API e sem conta de desenvolvedor. Suas 100 requisições grátis datam os primeiros 10 mil posts, então rode o script acima na sua própria lista.

#Perguntas frequentes