Export your X bookmarks to Airtable

The order matters. Import once to get a table, fix the field types, and from then on use the extension with post_id as the merge field. Do it the other way around and you spend an evening deduplicating.

1. 1

   Comma-separate the tags column first

   Our ai_tags column is space-separated. Airtable creates Multiple select options by splitting on commas, so left alone you get one option reading caching infra performance. Substituting commas for spaces in that one column — in a spreadsheet, or via the in-browser converter — is thirty seconds of work that saves rebuilding the field later.
2. 2

   Import the CSV to create the table

   Add a base, choose to import a CSV, pick the file. Airtable produces a table with nine fields and a guess at each type. Do not build views yet.
3. 3

   Fix post_id before anything else

   If Airtable typed it as Number, change it to Single line text and then re-import. Converting the field back to text keeps whatever the number field was holding, and a 19-digit integer is not something a numeric field held faithfully in the first place. This is the one step where repairing in place does not work.
4. 4

   Set the remaining types

   Per the table below. Six of the nine want something other than the default.
5. 5

   Turn the primary field into something readable

   Airtable’s primary field is whatever landed in the first column and cannot be deleted, though unlike some tools it can be renamed and retyped. Point it at ai_summary, or add a formula field concatenating the handle and the first few words of the post, so linked records elsewhere in the base show something meaningful.
6. 6

   Import again tomorrow with a merge key

   Open the CSV import extension, map the columns, and set the merge field to post_id. Airtable updates matching records and inserts the rest. Overlapping exports stop mattering, which is the difference between this and the Notion route, where a second CSV simply appends.

The reason to put saved posts in Airtable rather than a plain spreadsheet is that the field types are enforced rather than merely suggested, and the views are cheap. Group a grid by ai_category and you have the sorted library, in a tool where you can add your own fields next to it: a status field for read or unread, a checkbox for “actually useful”, a link to whatever project the post is relevant to. That last one is the thing a CSV cannot do and a bookmark manager should not try to.

Two limits to know before you commit to it. Airtable’s lower plans cap records per base, and 500 rows per export day reaches a low cap faster than people expect — check yours against the size of your bookmark library rather than against a single import. And long text fields count toward per-record size limits, so a base of several thousand posts with your own attachments alongside is heavier than the row count suggests.

Airtable automations can fire on a new record and send it almost anywhere, and it would be straightforward to wire this table into Slack, an email, or a public interface. Two things to keep in view if you do.

The first is that we do not push into Airtable, and will not. X’s developer policy restricts handing X content to third parties and makes an exception for up to 500 post objects per person per day by non-automated means — a file you download. A scheduled write into your base would be an automated delivery of post content to a third-party service, which is not covered by that exception, so the download button is the deliberate stopping point.

The second is that the same rules follow the data. Once post text is in your base, an automation that republishes it to a public interface or a shared channel is a redistribution decision you are making, not one we made for you. Keeping the base private and the ai_ prefix intact on the generated fields is the low-effort way to stay on the right side of it. Posts deleted on X, incidentally, never enter the base at all — a the deletion check that runs every night takes them out of the export first.