> ## Documentation Index
> Fetch the complete documentation index at: https://docs.redbark.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Airtable
> Sync transactions to an Airtable base
Airtable lets you treat your transactions like a database — build views, link records, and run interfaces and automations on top of live banking data. Transactions are written as records in a table within a base you choose.
## Setup
Click **Add Destination**, select **Airtable**, and authorise Redbark. The connection uses OAuth 2.0 with PKCE. You grant access to specific bases, and Redbark requests only the scopes it needs: read and write records, and read and write base schema.
Choose one of the bases you granted access to, then select an existing table, or click **create a Transactions table** to have Redbark create a "Redbark Transactions" table for you, with the full transaction field schema already set up.
Tick the CDR disclosure checkbox confirming you understand data sent to Airtable leaves Redbark's control and is governed by Airtable's own terms. Then save the destination.
## How it works
On each sync, Redbark Sync:
1. **Ensures the fields exist**: when Redbark creates the table for you, it is created with the full transaction field schema already in place. If you pick an existing table instead, only the fields that don't already exist are added.
2. **Reads existing Transaction IDs**: the `Transaction ID` field is read across the table to identify transactions that have already been synced.
3. **Appends new records**: only new posted transactions are written, in batches of up to 10 records per request. Pending transactions are excluded by default. You can enable pending transactions per sync as an [experimental setting](/syncs#include-pending-transactions-experimental).
4. **Applies retroactive corrections**: if a previously-synced transaction changes upstream (e.g. a description or category is enriched), the existing record is updated in place rather than duplicated.
Values are written with Airtable's `typecast` enabled, so they coerce into your column types and select options are created automatically — writes succeed even if you change a field's type.
## Transaction fields
| Field | Airtable type | Description |
| -------------- | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| Description | Single line text | Transaction description (primary field on tables Redbark creates) |
| Transaction ID | Single line text | Unique identifier used for deduplication |
| Date | Date | Transaction date |
| Amount | Number | Transaction amount |
| Currency | Single line text | ISO 4217 currency code |
| Direction | Single select | `credit` or `debit` |
| Category | Single line text | Transaction category (if available) |
| Merchant | Single line text | Merchant name (if available) |
| Account | Single line text | Bank account name |
| Status | Single select | `posted` (or `pending` when the experimental [include-pending-transactions](/syncs#include-pending-transactions-experimental) toggle is enabled) |
| Class | Single line text | `payment`, `transfer`, `fee`, `interest`, or `other` |
| Post Date | Date | Date the transaction was posted |
If you've set up custom categories, two extra fields are added:
| Field | Airtable type | Description |
| --------------- | ---------------- | ---------------------------------------------------------------------- |
| Subcategory | Single line text | Your resolved subcategory (if available) |
| Custom Category | Single line text | Your resolved custom category name (falls back to Category if not set) |
You can add your own fields to the table. They're left untouched by syncs. Records from multiple bank accounts land in the same table — use the **Account** field to filter or group them.
If you rename the base or table in Airtable, Redbark detects the new name on the next sync and updates the destination label automatically.
## Authentication
Airtable uses OAuth 2.0 with PKCE. Access tokens are short-lived (about an hour) and are refreshed on demand when within 5 minutes of expiry. Airtable rotates the refresh token on every refresh, so Redbark stores the new one each time. If a refresh fails (for example, you revoked Redbark's access from your Airtable account, or the 60-day refresh token expired through inactivity), the sync is classified as `destination_auth_expired` and you'll be prompted to re-authenticate from the [destinations](/destinations) page.
## Troubleshooting
**Base or table not accessible**
If Redbark loses access to the base or table (it was deleted, or access was revoked in Airtable), the sync fails and you can reconnect or re-select a table from the [destinations](/destinations) page.
**Rate limits**
Airtable limits each base to 5 requests per second. Redbark batches writes and automatically backs off and retries on a `429`, so large syncs complete without intervention.
## Tips
* **Create the table from Redbark** for the quickest start (the full field schema is set up for you immediately).
* **Bring your own table** if you already have one; Redbark only adds the fields it needs and leaves the rest alone.
* **Views and automations are safe**: syncs only create and update records, so your views, interfaces, and automations keep working.