Airtable IDs for tables, fields, records, etc

Every table, view, field, record, automation, interface, user, and more in Airtable has an Airtable ID. This is typically a three letter prefix that identifies the type of object, followed by 14 alphanumeric characters that identify the specific object.

When using Airtable, you rarely ever need to access these internal IDs. However, sometimes it is useful to know these ids, such as when working with scripting and prefilling forms.

General tips:

  • Whenever you duplicate a base, all of the internal Airtable IDs also change!
  • These IDs are also available in third party tools and scripts that expose schema information.

Record ID

Prefix: rec

Ways to find it:

  • Create a formula field with the formula RECORD_ID()
  • Look in the url of the browser when a record is open in the expanded view
  • Available in an automation when the record is a triggering record or a found record
  • Get it through scripting

Tips:

  • Do not confuse this with the primary field value of a record, or with any fields that you may be named “id”.
  • Useful when prefilling a linked record field where the primary field value might change or might not be unique
  • Useful when working with a third party integration source that will need to get a particular record
  • Essential to understand if you work with scripts
  • Guaranteed to be unique across a table, and probably is unique across a base.
  • Except for the convoluted method for getting a table ID, this is the only ID available through formula fields.

Table ID

Prefix: tbl

Ways to find it:

  • Look in the url when the table is open
  • Get it through scripting
  • Look at the API documentation for the table
  • Create a formula field based on a button field that opens an extension, such as Page Designer, that is configured for that table.

Tips:

  • Useful when writing code where the table name might change
  • Useful when generating urls for records

View ID

Prefix: viw

Ways to find it:

  • Look in the url when the view is open
  • Get it through scripting
  • Look at the API documentation for the table

Tips:

  • Useful when writing code where the view name might change
  • Optional when generating urls for records
  • A form view has both a view ID and a share ID. The url for publishing the form is the share ID, not the view ID.

Field ID

Prefix: fld

Ways to find it:

  • Get it from the “Manage Fields” tool for the table. You may need to unhide it".
  • Get it from the url for a specific field. (Right-click the field name, and select “Copy field URL”)
  • Get it from the url for a specific cell. (Right-click the cell, and select “Copy cell URL”)
  • Get it through scripting
  • Look at the API documentation for the table
  • Use my “Field List” extension

Tips:

  • Useful when prefilling forms where the field name might change
  • Useful when writing code where the field name might change
  • Useful when debugging scripts

Other IDs

Other internal IDs are not used as frequently and I do not have time to write them up now.

Additional abbreviations:

  • base ID prefix: app
  • user ID prefix: usr
  • workspace ID prefix: wsp
  • automation ID prefix: wfl
  • automation trigger ID prefix: wtr
  • automation action ID prefix: wac
  • interface ID prefix: pag

Note that elements within an Interface can be found in the url when the element is selected. However, these interface element IDs do not follow the same format as other IDs. They do not have a consistent three letter prefix and they are much shorter than 14 alphanumeric characters.

10 Likes

This is an amazing list, @Kuovonne! Thank you so much for writing this up! :cowboy_hat_face:

This is one of my big pet peeves with Airtable — not that ALL of the IDs change, but very specifically that all of the Record IDs change.

Since Record IDs are always unique to a particular table/base, there is actually no reason for Airtable to change the Record IDs from base to base. Each base is a standalone entity with its own set of Record IDs.

But since Airtable changes the Record IDs with each base, this makes restoring data from a snapshot infinitely more difficult, because you can’t match Record IDs across bases.

So I feel like a good practice for people to get in the habit of doing is creating their own unique IDs for each record in every table, so in the case of needing to restore data from a snapshot, you can easily figure out which records are which.

This actually could be as easy as just creating an “Autonumber” field in each table.

2 Likes