Por Sorsa Editorial

Atualizado em 11 de julho de 2026: apresenta os tetos confirmados de contas não verificadas (50 posts originais e 200 respostas por dia, pela página de limites do X desde meados de maio de 2026), remove o número diário não publicado do Premium e reenquadra o limite de ritmo como os sublimites semi-horários documentados do X.

Em resumo: O endpoint de escrita da API do X permite 100 posts por 15 minutos por usuário e 10.000 por 24 horas por app. Separadamente, a conta do X carrega tetos válidos em toda a plataforma que contam posts de API e manuais juntos: desde maio de 2026, contas não verificadas têm 50 posts originais e 200 respostas por dia, e é esse teto de conta que trava a maioria das automações primeiro.

Postar pela API do X em 2026 esbarra em três tetos separados, não um, e eles são impostos de forma independente. O endpoint da API tem os próprios rate limits por app e por usuário. A conta do X de onde você posta tem tetos diários válidos em toda a plataforma que se aplicam venha o post de um script ou do app. E no pagamento por uso, cada post criado é cobrado, com um teto rígido de 2 milhões de leituras de posts do lado de leitura da mesma conta. Qualquer um dos três pode retornar um erro, e é por isso que "meu código está longe do rate limit" é uma das reclamações mais comuns e confusas de quem automatiza o X.

Este guia cobre as três camadas com números atuais, verificados contra a própria documentação do X. Nós construímos e operamos a Sorsa API, uma API alternativa do Twitter (X) para ler dados públicos do X, então postar em si não é a nossa faixa: as escritas pertencem à API oficial, e estes são os limites com que você convive lá. Onde podemos ajudar é a outra metade da maioria dos fluxos de postagem, a parte de leitura, confirmar que um post foi ao ar, puxar o engajamento dele ou monitorar menções depois de publicar, que as seções abaixo sinalizam onde for relevante. Os números de postagem aqui são o que a API oficial do X te dá agora.

Última verificação: 6 de julho de 2026, contra a documentação oficial de rate limit e de limite de conta do X.


Índice


Como os limites de posts da API do X funcionam {#how-x-api-posting-limits-work}

O X impõe a postagem em três camadas independentes em 2026: o rate limit da API no endpoint de escrita, o teto diário de nível de conta na própria conta do X e a cobrança de pagamento por uso que mede cada post criado. Uma requisição pode falhar contra qualquer uma delas, e cada uma retorna um sinal diferente.

A primeira camada é o rate limit da API. O endpoint de escrita (POST /2/tweets) permite 100 posts por 15 minutos por usuário e 10.000 por 24 horas por app. São janelas móveis que começam na sua primeira requisição, não num horário fixo de relógio, e furar uma retorna HTTP 429.

A segunda camada é o teto de conta. Toda conta do X está presa a limites de postagem válidos em toda a plataforma, que valem juntos na web, no celular e na API. A própria documentação de limites do X é explícita ao dizer que esses tetos diários contam ações "de todos os dispositivos, incluindo web, celular, telefone, API", então um post automatizado e um post digitado à mão saem do mesmo orçamento diário. Essa é a camada que a maioria dos guias ignora, e costuma ser a que de fato trava um bot.

A terceira camada é a cobrança. Desde que o X migrou para pagamento por uso em fevereiro de 2026, cada post criado custa dinheiro (US$ 0,015 por um post simples, US$ 0,20 por um post com URL desde o reajuste de 20 de abril de 2026), e a conta carrega um teto rígido separado de 2 milhões de leituras de posts por mês do lado de leitura. Você pode ficar confortavelmente dentro do seu rate limit de postagem e ainda ser bloqueado nas leituras, ou ver um fluxo de publicação cheio de links ficar caro rápido. O quadro completo de custo por ação, incluindo o adicional de URL e a janela de deduplicação, está na análise de preços da API do X em 2026.

A conclusão prática: o rate limit da API raramente é a restrição decisiva para postar. O teto de conta quase sempre é.


Quantos tweets dá para postar por dia pela API do X? {#how-many-tweets-can-you-post-per-day-via-the-x-api}

Só pela API, um único usuário autenticado pode postar até 100 tweets por 15 minutos, e um app pode postar até 10.000 por 24 horas somando todos os seus usuários. Mas a conta do X de onde esses posts saem tem teto separado no nível da plataforma, e esse teto de conta é menor que o teto da API e costuma ser o que trava a automação.

Veja como as duas camadas se empilham para uma única conta:

CamadaLimiteJanelaAplica-se a
API por usuário (POST /2/tweets)100 posts15 minCada token de usuário autenticado
API por app (POST /2/tweets)10.000 posts24 hO app inteiro, todos os usuários juntos
Teto de conta, não verificada50 posts + 200 respostas24 hA conta do X, API e manual juntos
Sublimites de ritmo da contaNão publicadosSemi-horárioA conta do X, qualquer origem

Desde meados de maio de 2026, a própria página de limites do X trava contas não verificadas em 50 posts originais e 200 respostas por dia, um corte forte em relação aos antigos 2.400, e quebra esse orçamento diário em sublimites semi-horários cujos valores de intervalo o X não publica. É amplamente relatado que reposts e quote-posts contam para os 50, embora o X não tenha confirmado de forma direta, e a página de ajuda ainda cita o velho número de 2.400 em alguns pontos, e é por isso que números conflitantes circulam entre os guias. Contas verificadas (Premium) são isentas desses tetos publicados; o X não informa número para elas, então, numa conta Premium, os limites de escrita da API acima viram o teto prático.

A armadilha é projetar em torno do limite da API. Um desenvolvedor lê "100 posts por 15 minutos" (quase 9.600 por dia por usuário) e constrói para isso, e depois o bot trava bem antes porque o teto de nível de conta e o ritmo semi-horário dele travam primeiro. Para uma conta não verificada rodando automação, 50 posts por dia é o teto real, não a janela da API.

Esse comportamento em camadas também aparece do lado de leitura, em que as janelas de 15 minutos e os pools por app contra por usuário causam a maioria dos 429 de pipeline de coleta. Esses limites de leitura estão cobertos endpoint por endpoint na referência complementar de rate limits da API do X.


Rate limits para respostas, exclusões e mensagens diretas {#rate-limits-for-replies-deletes-and-direct-messages}

Postar um tweet de topo, postar uma resposta, apagar um tweet e enviar uma mensagem direta rodam, cada um, sob limites de escrita separados na API do X. Uma resposta usa o mesmo endpoint POST /2/tweets e o mesmo limite de um post original, mas a exclusão e o envio de DM são mais rígidos e são regidos pelas próprias janelas.

AçãoEndpointPor usuárioPor appJanela
Postar tweet ou respostaPOST /2/tweets10010.00015 min (usuário), 24 h (app)
Apagar tweetDELETE /2/tweets/:id50não suportado15 min
Enviar mensagem diretaPOST /2/dm_conversations/.../messages15 por 15 min + 1.440 por 24 h1.44015 min e 24 h
Ler mensagens diretasGET /2/dm_events15não suportado15 min

A exclusão é a que surpreende quem roda trabalhos de limpeza. A 50 exclusões por 15 minutos por usuário, limpar 1.000 tweets antigos leva cerca de cinco horas de relógio, ritmadas por vinte janelas, e não há endpoint de exclusão em lote para acelerar. Ferramentas que apagam grandes timelines dão certo projetando as esperas, não repetindo mais rápido.

As respostas carregam o próprio teto de nível de conta por cima do limite da API. Para contas não verificadas, a página de limites do X fixa esse teto de respostas em 200 por dia, separado do orçamento de 50 posts originais, então um bot que responde menções pode esgotar a franquia de respostas com o orçamento de posts originais intacto.

As mensagens diretas são deliberadamente lentas. A 15 envios por 15 minutos por usuário mais um teto de 1.440 por 24 horas, e um teto de nível de plataforma amplamente citado em torno de 500 DMs por dia por conta, o envio automatizado bate numa parede rápido por design. Nenhuma dessas ações de escrita tem equivalente somente leitura: ler o histórico de DM, por exemplo, também é limitado a 15 requisições por 15 minutos, então fluxos com uso intenso de DM ficam restritos nas duas pontas.


E as curtidas, follows e reposts? {#what-about-likes-follows-and-reposts}

Seguir contas, curtir posts e dar quote-post mudaram de nível de acesso em 2026. A partir de 20 de abril de 2026, o X tirou essas ações de escrita de engajamento do pagamento por uso self-service e as tornou somente Enterprise, então uma automação que curte, segue ou dá quote-post de forma programática agora precisa de um contrato Enterprise, e não de um app de desenvolvedor padrão. Postagem e mensagens diretas ficaram no pagamento por uso.

Antes dessa mudança, os limites de API publicados para essas ações eram apertados: curtidas e follows rodavam a cerca de 50 por 15 minutos por usuário, com tetos adicionais de 24 horas, e reposts numa cadência parecida. Esses números agora são irrelevantes para usuários self-service, porque os endpoints ficam totalmente atrás do acesso Enterprise.

No nível da conta, os follows continuam com teto separado dos posts. Contas não verificadas são amplamente relatadas em torno de 400 follows por dia e contas Premium em cerca de 1.000, com o X de olho em padrões de seguir e deixar de seguir em ciclo que disparam restrições mesmo quando o número diário não é furado. As curtidas não têm limite de conta documentado publicamente, mas curtir de forma automatizada e agressiva dispara throttling comportamental de forma confiável.

Se o seu fluxo depende de escritas de engajamento programáticas, o nível Enterprise da API oficial é o caminho em conformidade, e não há substituto somente leitura para uma ação de escrita. O que uma API de leitura cobre é o lado da medição: em vez de curtir ou seguir, você lê quem engajou. Puxar as contas que deram repost ou responderam a um tweet de campanha é uma operação de leitura, tratada por endpoints como a consulta de quem deu retweet e de quem respondeu, o que mantém essa coleta de dados totalmente fora de qualquer conta de usuário.


O plano gratuito da API do X permite postar em 2026? {#does-the-x-api-free-tier-let-you-post-in-2026}

Não há um plano gratuito geral da API do X para novos desenvolvedores em 2026. O X descontinuou o plano gratuito independente quando o pagamento por uso foi lançado em fevereiro de 2026, então uma conta nova precisa comprar créditos antes de postar um único tweet. Se a API do X é gratuita em 2026 tem uma resposta para novos cadastros: não é.

Para quem ainda segura um app do plano gratuito legado, a franquia de postagem sempre foi mínima por design. O plano gratuito legado era somente escrita e medido em janelas de 24 horas, e a franquia documentada de POST /2/tweets era de 17 requisições por 24 horas compartilhadas por todo o app (algumas fontes citam um número mensal maior que valia para o caminho antigo da v1.1, que é a raiz da confusão entre 17 e 50 que você vê nos guias). De uma forma ou de outra, era um toco pensado para testar uma integração de postagem, nunca para rodar uma em volume, e concedia zero acesso de leitura de posts.

Então o plano gratuito nunca suportou postar em escala, e para novos desenvolvedores ele não existe mais. Se o que você de fato precisa testar é ler dados do X, e não postá-los, o acesso de terceiros é o caminho grátis prático. Toda conta nova da Sorsa começa com 100 requisições grátis, uma única vez, sem cartão, e elas nunca expiram. Elas cobrem todos os 40 endpoints de leitura à mesma taxa fixa dos planos pagos, o que pelos endpoints em lote basta para até 10.000 tweets ou 20.000 perfis antes de pagar qualquer coisa. Essa é uma carga real para validar uma integração de leitura, bem além dos pequenos créditos de teste que a maioria dos provedores oferece.


O ritmo semi-horário que trava a maioria das automações {#the-semi-hourly-pacing-that-stops-most-automations}

O limite que pega mais automações de postagem não é só o número diário de destaque. O X quebra o orçamento diário de postagem de cada conta em sublimites semi-horários menores, impostos no nível da conta por cima do teto diário e independentes do rate limit da API, e não publica os valores de intervalo. Quem faz live-tweet, thread ou bot de resposta esbarra nesse ritmo o tempo todo, às vezes antes de o teto diário aparecer.

O motivo de ser tão fácil esbarrar é que o orçamento é pequeno e compartilhado: 50 posts originais e 200 respostas por dia para uma conta não verificada, com reposts e quote-posts amplamente relatados como parte do mesmo pool, tudo ritmado em subintervalos. Um bot respondendo a uma rajada de menções, ou uma thread postada tweet a tweet num loop apertado, pode esgotar a franquia de um intervalo em menos de um minuto e então travar até ela resetar.

Há um segundo bloqueio, mais silencioso, por cima: a detecção de duplicatas. O X rejeita posts com texto idêntico ou quase idêntico publicados dentro de um intervalo de mais ou menos 24 a 48 horas, retornando o código de erro 187. Automações que reciclam a mesma mensagem, comuns em postagem evergreen ou setups de várias contas, esbarram nisso mesmo estando longe de qualquer rate limit. A correção é trivial, mudar até um caractere ou uma pontuação limpa a checagem de duplicata, mas ela tem de estar embutida no fluxo.

A regra prática para ritmar escritas: espalhe os posts pelo dia em vez de estourar contra o teto diário. Enfileire respostas e segmentos de thread em lotes de 10 a 15 com intervalos deliberados entre eles, e varie qualquer texto reciclado. Projetar só para o número diário é exatamente como automações travam no meio da execução.


O que acontece quando você bate em um limite de posts {#what-happens-when-you-hit-a-posting-limit}

Quando você excede um rate limit da API, o X retorna HTTP 429 com o código de erro 88:

json
{
  "errors": [{
    "code": 88,
    "message": "Rate limit exceeded"
  }]
}

A resposta ainda carrega os cabeçalhos de rate limit, que é a parte que importa. O x-rate-limit-reset é um timestamp Unix de quando a janela reabre, então um worker de escrita nunca precisa dormir às cegas por um intervalo fixo. Furos de teto de nível de conta e rejeições de duplicata aparecem de forma diferente: um teto de conta tende a retornar um 403 ou um aviso de restrição de postagem em vez de um 429, e uma duplicata retorna o erro 187, então um postador bem construído distingue os três em vez de tratar toda falha como rate limit.

Uma retentativa ciente do reset para o caminho de escrita fica assim:

python
import time
import requests

def post_tweet_with_retry(text, headers, max_retries=3):
    url = "https://api.x.com/2/tweets"
    for attempt in range(max_retries):
        response = requests.post(url, headers=headers, json={"text": text})

        if response.status_code != 429:
            return response

        reset = int(response.headers.get("x-rate-limit-reset", 0))
        wait_seconds = max(reset - int(time.time()), 1)
        print(f"Rate limited. Waiting {wait_seconds}s until the window resets.")
        time.sleep(wait_seconds + 1)  # +1s buffer

    raise Exception("Rate limit retries exhausted")

Duas coisas para vigiar. Primeiro, não repita na hora em um 429, porque um loop apertado de retentativa queima o orçamento restante nos outros endpoints na autenticação somente do app. Segundo, cheque o x-rate-limit-remaining antes de cada escrita e desacelere quando ele cair para um dígito, em vez de esperar a parada rígida. Num loop de postagem ou exclusão em massa, um 429 não tratado pode virar uma cascata de falhas antes de o código perceber.


Como postar em escala sem esbarrar nos limites {#how-to-post-at-scale-without-tripping-limits}

Conseguir volume real de postagem pela API do X é menos sobre o teto diário e mais sobre ritmar dentro da janela de 30 minutos e do teto de conta. Estes são os movimentos que de fato mudam o resultado.

  1. Ritme pelos sublimites semi-horários, não só pelo teto diário. O X divide o orçamento diário em intervalos semi-horários com valores não publicados, então agrupe respostas e segmentos de thread em grupos de 10 a 15 com intervalos em vez de estourar. Esse ritmo é o que trava primeiro em quase toda automação.

  2. Use uma conta verificada (Premium) para publicação de alto volume. Os tetos de 50 posts e 200 respostas por dia valem só para contas não verificadas; a página de limites do X isenta contas verificadas e não publica número para elas, então o limite de escrita da API vira o limite real.

  3. Varie qualquer texto reciclado para limpar a detecção de duplicatas. O erro 187 rejeita posts quase idênticos dentro de um intervalo de 24 a 48 horas. Gire a redação, ou anexe um elemento único, em postagem evergreen ou de várias contas.

  4. Vigie o adicional de URL no seu modelo de custo. Um post com qualquer link é cobrado a US$ 0,20 contra US$ 0,015 de um post simples, mais de 13 vezes o custo, então um fluxo de publicação cheio de links pode custar dinheiro de verdade rápido. As contas por trás desse salto estão no nosso olhar sobre por que a API do X fica tão cara.

  5. Separe as filas de escrita das filas de leitura. Postar e ler saem de limites diferentes e, no pagamento por uso, de tetos diferentes (o teto mensal de 2 milhões de leituras de posts é separado de qualquer orçamento de escrita). Manter as filas independentes significa que um acúmulo de leitura não pode bloquear um post agendado, e vice-versa.

Esse último ponto é onde a maioria dos setups de postagem de produção acaba dividida entre dois provedores, e leva direto ao padrão prático abaixo.


Postar contra ler: qual API para qual trabalho {#posting-versus-reading}

A maioria dos fluxos reais do X faz as duas coisas, e as duas metades pertencem a infraestruturas diferentes em 2026. Escrever no X (postar, responder, enviar DMs) é uma ação de primeira parte que tem de rodar na API oficial, sob os limites acima e em tokens autenticados por usuário. Ler o X em volume (verificar que um post foi publicado, puxar o engajamento dele, monitorar menções, coletar timelines) é onde o preço oficial por recurso e as janelas por endpoint ficam caros e desajeitados, e onde uma API de leitura de taxa fixa é um encaixe mais limpo.

  • Postagem, resposta e DMs automatizados: a API oficial do X, no pagamento por uso ou Enterprise. Não há substituto somente leitura em conformidade para uma escrita.
  • Curtidas, follows e quote-posts programáticos: o nível Enterprise da API oficial do X, já que saíram do self-service em 20 de abril de 2026.
  • Confirmar que posts foram ao ar, puxar engajamento, monitorar menções, leituras em massa: uma alternativa focada em leitura como a Sorsa, a um fixo de 20 requisições por segundo sem janelas por endpoint e leituras a partir de US$ 0,02 por 1.000 tweets na base de lote.

A divisão honesta vale ser dita com todas as letras: se você precisa escrever no X, esse é o território da API oficial, e nada aqui muda isso. Para a metade de leitura intensa do mesmo fluxo, uma API de leitura fixa e previsível remove as janelas de 15 minutos e a cobrança por recurso. Mover só as leituras é um primeiro passo comum, e o caminho de migração da API oficial cobre fazer isso sem tocar no lado de escrita.

Na prática: uma agência que vivia com restrição de postagem

Uma agência social (cerca de uma dúzia de pessoas) rodando posts agendados para clientes vivia batendo em restrições de postagem que não conseguia explicar. O agendador deles estava arquitetado em torno do número de "100 por 15 minutos" da API, mas as contas de clientes viviam sendo travadas no meio da campanha. A causa era a camada de conta: contas de cliente não verificadas batiam no teto diário da plataforma e no ritmo semi-horário dele bem antes de o limite da API importar, e os reposts contavam silenciosamente para o mesmo orçamento.

A correção de escrita foi operacional, não uma migração: eles moveram contas de alto volume para o Premium, ritmaram a postagem dentro dos sublimites semi-horários e variaram a cópia reciclada para parar de esbarrar no erro 187. O caminho de escrita ficou na API oficial, onde deve ficar. O que migrou foi a camada de relatório de leitura intensa, confirmar que posts foram ao ar e puxar o engajamento por post para os dashboards dos clientes, que vinha queimando silenciosamente rumo ao teto mensal de 2 milhões de leituras. No preço fixo por requisição, esse trabalho de leitura sai até 50x mais barato por leitura que o modelo oficial por recurso, e a conta de relatório caiu para a casa das centenas por mês, enquanto as restrições de postagem sumiram quando o ritmo foi ajustado.


Perguntas frequentes {#faq}

Quantos tweets dá para postar por dia com a API do X em 2026?

O endpoint de escrita da API do X permite 100 posts por 15 minutos por usuário e 10.000 por 24 horas por app. O limite decisivo costuma ser o teto de conta: desde maio de 2026, contas não verificadas ficam presas a 50 posts originais e 200 respostas por dia, ritmadas em sublimites semi-horários, enquanto contas verificadas (Premium) são isentas desses tetos publicados.

Qual é o rate limit da API do X para apagar tweets?

A exclusão de tweet via DELETE /2/tweets/:id tem teto de 50 requisições por 15 minutos por usuário, e não há endpoint de exclusão em lote. Nesse ritmo, limpar 1.000 tweets leva cerca de cinco horas de relógio, espalhadas por vinte janelas. Trabalhos grandes de limpeza dão certo construindo esperas entre os lotes em vez de repetir mais rápido, já que as pausas são a API funcionando como projetada.

Sim, mas posts com uma URL são cobrados a US$ 0,20 cada no pagamento por uso desde o reajuste de 20 de abril de 2026, contra US$ 0,015 de um post só de texto, mais de 13 vezes o custo. Um fluxo que autopublica links de newsletter, posts de blog ou URLs de afiliado em volume fica caro rápido, então o adicional de URL pertence a qualquer modelo de custo antes de entregar uma automação de postagem cheia de links.

O plano gratuito da API do X permite postar em 2026?

Nenhum plano gratuito geral existe para novos desenvolvedores. O X o descontinuou quando o pagamento por uso foi lançado em fevereiro de 2026, então contas novas precisam comprar créditos antes de postar. O plano gratuito legado era somente escrita e permitia só cerca de 17 posts por 24 horas por todo o app, com zero acesso de leitura. Para testar leituras em vez disso, a Sorsa API inclui 100 requisições grátis no cadastro, sem cartão, cobrindo todos os 40 endpoints.

Por que um erro 429 aparece mesmo abaixo do rate limit de postagem?

Um 429 significa que uma janela da API foi excedida, mas falhas de postagem muitas vezes vêm de outra camada. Os tetos diários de nível de conta (50 posts originais e 200 respostas por dia para contas não verificadas) contam posts de API e manuais juntos e costumam travar antes do limite da API, tipicamente retornando um 403 ou aviso de restrição. Texto duplicado quase idêntico retorna o erro 187. Distinga os três em vez de tratar toda falha como rate limit.

Como desenvolvedores conseguem alta vazão de leitura sem bater nesses limites?

A postagem fica na API oficial, mas o trabalho de leitura intensa migra para uma alternativa de taxa fixa para evitar as janelas por endpoint. A Sorsa API, por exemplo, serve todos os 40 endpoints de leitura a 20 requisições por segundo em todos os planos, a partir de US$ 0,02 por 1.000 tweets na base de lote, com planos a partir de US$ 49 por mês. Em escala de leitura, isso sai até 50x mais barato por leitura que o preço oficial por recurso.

Primeiros passos

Se o seu fluxo de postagem também tem de ler dados do X, confirmar que posts foram ao ar, puxar engajamento para relatório ou monitorar menções depois de publicar, esse lado de leitura é onde as janelas por endpoint e a cobrança por recurso oficiais mais doem, e onde uma API de leitura de taxa fixa é o encaixe mais limpo. A forma mais rápida de sentir a diferença é rodar algumas chamadas você mesmo: o playground interativo da API executa endpoints ao vivo no navegador sem chave e sem cadastro, para você checar o formato da resposta primeiro. Quando estiver pronto para construir, o início rápido da Sorsa API deixa você autenticado com uma única chave de API em poucos minutos, toda conta nova inclui 100 requisições grátis (uma única vez, sem cartão, nunca expiram, todos os 40 endpoints, o bastante para até 10.000 tweets ou 20.000 perfis), e os planos de preço fixo saem a partir de US$ 0,02 por 1.000 tweets na base de lote, a partir de US$ 49 por mês, a 20 requisições por segundo sem janelas por endpoint para administrar. Escrever no X fica na API oficial; a metade de leitura não precisa.


Revisado por Keksich, fundador da Sorsa, profissional de marketing e pesquisador da API do X.

Como este guia foi preparado: os limites de escrita e exclusão da API, o corpo do 429 e os caminhos de endpoint foram lidos direto das tabelas oficiais de rate limit do X, e os tetos de postagem de nível de conta da documentação de limites do X, ambos reconferidos em 11 de julho de 2026, porque esses números mudam sem muito aviso e a própria página de ajuda do X ainda cita o velho número de 2.400 em alguns pontos, e é por isso que números conflitantes de teto diário circulam; os tetos de 50 posts e 200 respostas aqui vêm da página de limites atual. As táticas de ritmo de postagem e de detecção de duplicatas, o código de recuperação de 429 e o enquadramento em três camadas vêm do nosso próprio trabalho operando uma API do Twitter (X) focada em leitura e das migrações de pipeline de leitura que a nossa equipe faz, incluindo o caso anônimo de agência acima (detalhes mesclados e retirados de qualquer coisa identificável). Os números de preço são resumidos da nossa cobertura separada de preços da API do X. Para quem somos e como falar conosco, veja Sobre a Sorsa. Nenhuma estatística, fonte ou resultado de cliente aqui é inventado.