Export Twitter Data to Google Sheets: 4 Methods (2026)

By Sorsa Editorial

Published June 13, 2026. Pricing reflects the official X API pay-per-use rates after the April 20, 2026 update, verified against current public breakdowns in June 2026.

The hard part is rarely the spreadsheet. It is the data source feeding it. Sorsa API, an alternative Twitter/X API, returns public tweets, profiles, and follower lists as plain JSON behind a single header, so a Sheets export is a few lines of code. Billing is flat: one call counts as one request no matter how many tweets or profiles come back, the author profile is included free inside every tweet, and plans start at $49 for 10,000 requests. There is no per-tweet meter to drain a scheduled job, and the limit is a flat 20 requests per second on every plan. Setup uses API key authentication, not OAuth.

Contents

• How do you export Twitter data to Google Sheets?
• Which export method should you use?
• Pull tweets into Sheets with Google Apps Script
• No-code and low-code routes
• What columns should your export have?
• Common gotchas before you ship
• Do you need the official Twitter/X API for this?
• A real export setup
• Frequently asked questions
• Getting started

How do you export Twitter data to Google Sheets?

Exporting Twitter data to Google Sheets means pulling tweets, profiles, or follower lists from an API and writing them into rows. Four routes cover every case: a no-code connector for simple actions on your own account, a Sheets add-on that calls an API from inside the sheet, a low-code workflow tool, or a custom script. The right one depends on volume, schema control, and how technical you are.

Each route is built on the same idea. Something calls an endpoint, receives JSON, and appends a row per record. Where they differ is control. A no-code applet hides the request and gives you fixed columns. A script exposes the full response, so you decide the schema, the schedule, and how duplicates are handled.

One distinction matters before you pick. Pulling data tied to your own account (your posts, your followers) is straightforward almost everywhere. Pulling arbitrary keywords, mentions, or other accounts at volume needs an API that returns search and timeline data directly, because the official platform connectors built into no-code tools were heavily restricted after the 2023 API changes.

Which export method should you use?

Use Apps Script for production exports with a custom schema, an add-on or n8n for scheduled imports without much code, and a no-code connector only for simple actions on your own account. Setup time runs from under ten minutes for no-code to a couple of hours for a full Apps Script, and only the scripted routes give you reliable deduplication and exact column control.

The trade is control against effort. If a fixed set of columns and approximate timing is fine, a connector or add-on saves you an afternoon. If a downstream report depends on the exact schema, or duplicates would corrupt your numbers, the scripted routes are worth the extra setup.

Pull tweets into Sheets with Google Apps Script

Google Apps Script is the most flexible route: a JavaScript function that runs inside Google's infrastructure, calls an API, and writes rows, attached to a time-based trigger so it runs on its own. It is the only option that gives full control over the schema, deduplication, error handling, and logging, and it needs no third-party connector.

The example below pulls tweets for a search query and appends new ones to a tab. It calls the Sorsa search endpoint, which accepts a query plus an order of popular or latest and returns up to 20 tweets per page with the author profile attached. Follow these steps:

1. Create a tab named Tweets in your Google Sheet.
2. Open the Extensions menu and choose Apps Script.
3. In Project Settings, add a script property named SORSA_API_KEY with your key.
4. Paste the function below and set your search query.
5. Run the function once and approve the authorization prompt.
6. Open Triggers, add a time-driven trigger, and pick a run interval.

function exportTweetsToSheet() {
  var apiKey = PropertiesService.getScriptProperties().getProperty('SORSA_API_KEY');
  var query = 'your search query here';

  var response = UrlFetchApp.fetch('https://api.sorsa.io/v3/search-tweets', {
    method: 'post',
    contentType: 'application/json',
    headers: { 'ApiKey': apiKey },
    payload: JSON.stringify({ query: query, order: 'latest' }),
    muteHttpExceptions: true
  });

  var status = response.getResponseCode();
  if (status === 401) { Logger.log('Unauthorized: check the ApiKey value'); return; }
  if (status === 429) { Logger.log('Rate limited: wait one second, then retry'); return; }
  if (status !== 200) { Logger.log('Unexpected status: ' + status); return; }

  var tweets = (JSON.parse(response.getContentText()).tweets) || [];
  var sheet = SpreadsheetApp.getActiveSpreadsheet().getSheetByName('Tweets');

  // Keep the ID column as text so 19-digit IDs do not lose precision
  sheet.getRange('A:A').setNumberFormat('@');

  if (sheet.getLastRow() === 0) {
    sheet.appendRow(['tweet_id', 'created_at', 'username', 'full_text',
                     'likes_count', 'retweet_count', 'reply_count']);
  }

  var lastRow = sheet.getLastRow();
  var seen = lastRow > 1
    ? sheet.getRange(2, 1, lastRow - 1, 1).getValues().flat().map(String)
    : [];

  var added = 0;
  tweets.forEach(function (t) {
    var id = String(t.id || '');
    if (!id || seen.indexOf(id) !== -1) return;
    var user = t.user || {};
    sheet.appendRow([id, t.created_at || '', user.username || '', t.full_text || '',
                     t.likes_count || 0, t.retweet_count || 0, t.reply_count || 0]);
    added++;
  });

  Logger.log('Done. Added ' + added + ' new tweets.');
}

Two practical notes. Keep the key in a script property, never hardcoded in the function body, so it stays out of shared script history. And build the query visually first if the syntax is unfamiliar: the visual query builder turns advanced search operators like from:, since:, and until: into a tested string you can paste in.

To collect more than one page, read the next_cursor field from the response and call again with it in the body until it returns null. The mechanics are the same across paginated endpoints; the cursor pagination reference shows the loop. To export a follower list instead of tweets, call the followers endpoint with a username; each page returns up to 200 profiles, which keeps a large follower list export inside a handful of requests.

No-code and low-code routes

No-code and low-code tools trade control for speed. IFTTT and Make connect X to Google Sheets in minutes and suit simple actions tied to your own account; n8n sits one level up with real logic; Sheets add-ons call an API directly from inside the sheet. None of them handle deduplication or custom schemas as cleanly as a script.

The honest limit on the pure no-code path: after the 2023 platform changes, the built-in X connectors in these tools are oriented toward your own account and posting, not toward reading arbitrary search results into a datastore. For logging your own posts or reacting to your own activity, they work well. For monitoring keywords, mentions, or competitors at volume, you will want a data source that returns search and timeline results, fed through an add-on or a script.

n8n is the strongest middle ground. You build a workflow visually but keep branches, transforms, pagination loops, and a schedule trigger. A typical shape is a schedule trigger, an HTTP Request node that calls the search endpoint, a node that splits the response array into items, and a Google Sheets node that appends each row. Because n8n can hold state, you can add a deduplication step the same way the script does.

Sheets add-ons such as an API connector let you configure a URL, headers, and parameters inside the sheet, then refresh on a schedule. They are a good fit when you want scheduled imports without writing code. Send the API key in the request header rather than the URL so it does not end up in logs or browser history.

What columns should your export have?

A clean export gives you one row per tweet with stable, named columns. At minimum, capture the tweet ID, timestamp, author handle, text, and the three core engagement counts. The ID is the unique key for deduplication and should be stored as text; everything else maps directly from the response.

Treat the headers as a contract: once a report or formula depends on them, renaming a column breaks things quietly, so define the schema once and keep it. Because the author profile is returned inside every tweet, the handle and follower counts come from the same response with no extra request, which is part of why a flat per-request bill stays low here.

Common gotchas before you ship

Three issues catch most first exports: tweet IDs losing precision, scheduled runs failing silently, and pagination quietly stopping at one page. Each has a simple fix, and getting them right up front saves a rebuild later when a report is already wired to the sheet.

Tweet IDs are too large for Sheets to store as numbers. They are 18 to 19 digit values, and Google Sheets stores numbers as 64-bit floating point, which keeps only about 15 significant digits. The last digits round to zero and the ID stops matching the real tweet. Format the ID column as plain text, or write the value as a string before it reaches the sheet.

Pagination is not automatic. Search and timeline endpoints return about 20 records per page; follower endpoints return up to 200. To go past one page, loop on the next_cursor value until it comes back null. Batch endpoints help where the data fits them: when you already hold up to 100 tweet IDs or 100 usernames, a single bulk call returns all of them, which is the main lever in reducing request volume.

Scheduled runs can fail without telling you. A time-based trigger that errors out will not notify you unless you build alerting in. Add a MailApp.sendEmail call in a catch block, or check the Apps Script execution logs on a schedule. On rate limits, a 429 simply means wait one second and retry; with a flat 20 requests per second across every plan, a sensible interval rarely hits it.

Do you need the official Twitter/X API for this?

No, not for reading data into a sheet. The official X API is required only for write actions such as posting or sending direct messages. For reading public tweets, profiles, and follower lists, a read-only alternative bills per request rather than per resource, which is the difference between a few cents and a few dollars on the same export.

The cost gap comes from how each side meters. The official X API charges per resource fetched: each post read is $0.005 and each user profile read is $0.010, with a hard ceiling of 2 million post reads per month, figures confirmed in our X API pricing breakdown. A flat per-request model counts one call as one request and includes the author profile for free.

For posting or DMs, the official API is the only option, and that is its territory. For reading public data into a sheet at a flat, predictable price, a read-only API is far cheaper and quicker to wire up, which is why it suits scheduled exports and social listening setups that run all month. The same source covers a brand mention tracker, and if you prefer a script outside Apps Script, the pattern translates directly to pulling data with Python.

A real export setup

A roughly ten-person analytics team came to this after a budget surprise. They were logging brand mentions and competitor posts into Sheets through the official API and getting billed per post and per author read on every scheduled pull, which climbed fast once they tracked several keywords daily. Moving the same reads to a flat per-request API cut that data cost by roughly 30 to 50 times, the expected result for any read-heavy workload switching off per-resource billing, since the author profile rides along free and a batch call counts once.

The build itself stayed small: one Apps Script per keyword, an hourly trigger, the tweet ID as the dedup key, and a separate tab of seen IDs so the lookup stayed quick as the sheet grew. The lesson they took was about fit, not tooling. Sheets is a fine reporting surface and a poor warehouse; past a few hundred thousand rows it slows down, and that is the point to move the raw data into a database and keep Sheets for the view on top.

Frequently asked questions

Can you export Twitter data to Google Sheets without coding?

Yes, within limits. No-code platforms such as IFTTT and Make connect X to Google Sheets and work best for simple actions tied to your own account. For reading arbitrary keywords, mentions, or other accounts at volume, a Sheets add-on or a short Apps Script that calls a read-only API like Sorsa is more dependable, because it controls pagination, scheduling, and which columns get written.

Why do tweet IDs look wrong in Google Sheets?

Tweet IDs are 18 to 19 digit numbers, and Google Sheets stores numbers as 64-bit floating point, which only keeps about 15 significant digits. The final digits round to zero, so the ID stops matching the real tweet. Store IDs as text instead: format the ID column as plain text, or write the value as a string before it reaches the sheet.

How do you avoid duplicate rows on scheduled exports?

Use the tweet ID as the unique key. Before each scheduled run, read the IDs already in the sheet, then skip any tweet whose ID is present. For large sheets, keep a separate tab holding only the IDs seen so far so the lookup stays fast. Because every tweet ID is unique, this prevents duplicates even when runs overlap.

How often should a Twitter to Sheets export run?

Match the interval to how often the data drives a decision. Hourly suits time-sensitive mention alerts; daily is enough for trend reports or keyword summaries; weekly fits slow-moving audits. Running more often than needed adds noise and, on metered APIs, spends money for little gain. A scheduled trigger lets you set any interval and change it later.

Do you need the official Twitter API to export data to Sheets?

No. The official X API is required only for write actions such as posting or sending DMs. For reading public tweets, profiles, and follower lists into a sheet, a read-only alternative such as the Sorsa API works through a single ApiKey header and bills per request, so a scheduled export does not get metered per tweet. Plans start at $49 for 10,000 requests.

How many tweets can Google Sheets hold?

A single Google Sheets file holds up to 10 million cells across all tabs, which caps rows by how many columns you use. A seven column tweet export reaches that limit at roughly 1.4 million rows. As of April 2026, Google began a beta that doubles the ceiling to 20 million cells. Past a few hundred thousand rows, performance drops and a database is the better home.

Getting started

The fastest way to see the data shape is to try a query before writing any code. Open the API playground, run a search, and read the JSON you will be mapping to columns. When the schema looks right, drop the Apps Script above into your sheet and add a trigger.

When you are ready to wire it up, the quickstart guide covers the header auth and your first call, and the request-based plans start at $49 for 10,000 requests with a flat 20 requests per second and no approval queue.

Reviewed by Keksich, founder of Sorsa, marketer and X API researcher.

This guide draws on our team's hands-on work running the Sorsa API and the live API and its documentation, plus Google's official Apps Script behavior for scheduled triggers and header requests. The Google Sheets capacity figures were checked against Google's Workspace updates from April 2026, and the X API per-resource pricing was cross-checked across current public breakdowns and our own pricing teardown. Four export routes were compared. More on who we are is on the about page. Verified June 13, 2026.