Airtable integration for AI agents.
Airtable integration for AI agents with secure authentication and server-side credential injection. Open Connector runs the OAuth, seals the token in an encrypted vault, and serves Airtable tools to your agent over MCP or a typed API — credentials injected server-side, every call audited, nothing leaving your infrastructure. Open source (AGPL-3.0) and self-hostable.
Real Airtable actions, managed and audited.
Your user connects Airtable once; your agent can then read and manage Airtable bases, records, collaboration, automations, and enterprise resources — scoped to the OAuth permissions you grant and the tool allowlist you configure. Every action is least-privilege and written to a tamper-evident audit trail.
- 1
Your user grants Airtable access once (OAuth) — the token lands in the vault.
- 2
Your agent calls a tool over MCP or the typed API; Open Connector injects the credential server-side.
- 3
Every routed call appends a hash-chained audit record — nothing leaves your infra.
Supported Airtable tools.
103 tools are generated from the published Airtable catalog. Descriptions are plain text; each action remains subject to its configured authentication and tool allowlist.
Showing 103 tools. All published catalog entries are included in this page's server-rendered HTML.
- Add base collaborator
- Add a new base collaborator. Despite the name, this route currently only supports adding one collaborator at a time.
- collaborators
- Add interface collaborator
- Use this to add a collaborator to an interface.
- collaborators
- Add workspace collaborator
- Add a new workspace collaborator. Despite the name, this route currently only supports adding one collaborator at a time.
- collaborators
- Audit log events
- Retrieve audit log events for an enterprise. By default, this will walk all the data we're currently storing and continue walking data into the future.
- auditLogs
- Change events
- Retrieve change events for enterprise bases. These change events are available for 14 days from the date of the event. This endpoint requires change events to be enabled for your enterprise account and toggled on in your enterprise admin panel. Please contact your account team or support to start this process. Events are generated only after you turn change events on in your admin panel.
- changeEvents
- Create a webhook
- Creates a new webhook in the specified base. Payloads may be generated and the notification URL (if given) will get a ping shortly after this completes. The number of webhooks per base is limited to 10. A single OAuth integration can create up to 2 webhooks per base. Each webhook created with OAuth or personal access token will expire and be disabled after 7 days. The webhook life can be extended while it is still active by calling [refresh webhook](/api/refresh-a-webhook) or [list webhook payloads](/api/list-webhook-payloads). After a webhook has expired and been disabled, the webhook's metadata and past payloads can be accessed for an additional 7 days. **Creator level permissions are required in order to register a webhook.**
- webhooks
- Create audit log request
- **NOTE:** Use of this API is discouraged for new use cases. Prefer to use the [audit log events API](/api/audit-logs-overview) instead. Create an audit log request. This starts the processing necessary to retrive the logs. The response includes an `id`, which is then used to [check the status of and download](/api/get-audit-log-request) your logs.
- auditing
- Create base
- Creates a new base with the provided tables and returns the schema for the newly created base. Refer to field types for supported field types, the write format for field options, and other specifics for certain field types. Supported field types have a write format shown. At least one table and field must be specified. The first field in the fields array will be used as the table's primary field and must be a supported primary field type. Fields must have case-insensitive unique names within the table. A default grid view will be created with all fields visible for each provided table.
- base
- Create base from package
- Creates a new base by installing a package template for an enterprise account, and returns the schema for the newly created base. Provide the packageId as part of the request path and the packageReleaseId in the request body to create a base from a package template. You can retrieve them with the [List packages](/api/list-enterprise-packages) endpoint. The package will be installed into a new base, creating all tables, fields, and views defined in the package.
- enterprise
- Create comment
- Creates a comment on a record. [User mentioned](/api/model/user-mentioned) is supported.
- comment
- Create descendant enterprise
- Creates a descendant enterprise account of the enterprise account. Descendant enterprise accounts can only be created for root enterprise accounts with the Enterprise Hub feature enabled. Note that descendant enterprise accounts are also called organizational units (org units). For more information on org units in organizations with Enterprise Hub, please see [our support article](https://support.airtable.com/docs/enterprise-hub-in-airtable#understanding-and-using-organizational-units).
- enterprise
- Create eDiscovery export
- Create an eDiscovery export request. The response includes an `id`, which is then used to [check the status of and download](/api/get-ediscovery-export) your export.
- changeEvents
- Create field
- Creates a new column and returns the schema for the newly created column. Refer to field types for supported [field types](/api/model/field-type), the write format for field options, and other specifics for certain field types. Supported field types have a write format shown.
- column
- Create records
- Creates multiple records. Note that table names and table ids can be used interchangeably. We recommend using table IDs so you don't need to modify your API request when your table name changes. Your request body should include an array of record objects. Each of these objects should have one key whose value is an inner object containing your record's cell values, keyed by either field name or field id. Returns a unique array of the newly created record ids if the call succeeds. You can also include a single record object at the top level.
- record
- Create group
- Create a new group from a [SCIM Group](https://datatracker.ietf.org/doc/html/rfc7643#section-4.2) object. This endpoint creates a group with no members. Use the [patch group](/api/patch-scim-group) or [put group](/api/put-scim-group) endpoints to populate the new group with members.
- scim
- Create user
- Create a new user from a [SCIM User](https://datatracker.ietf.org/doc/html/rfc7643#section-4.1) object. The response is the SCIM user object representing the newly created user. On creation, the user will always be marked active, and the emails array will include a single entry that matches the username. See the [SCIM User schema](https://datatracker.ietf.org/doc/html/rfc7643#section-4.1) for details. **`userName` semantics.** In most configurations, `userName` is the user's email and becomes the `email` field in Airtable. When the targeted SSO identity provider has `emailAttribute` configured, `userName` is the IdP-supplied SSO identifier (which may be non-email, up to 255 characters) and the user's email is taken from `emails[primary].value`. In that mode you must send `emails` with a primary entry on create. **Off-domain provisioning.** To provision a user whose primary email is on a domain that is not verified by the enterprise (for example, a franchise or partner email), send the [Airtable SSO extension](/api/scim-overview#scimAirtableSsoExtension) (`urn:airtable:params:scim:schemas:extension:sso:2.0:User`) with the `emailDomain` field naming a verified enterprise domain whose IdP has `emailAttribute` configured. Without the extension, off-domain SCIM POST requests are rejected with `400 — emailDomain extension required for off-domain provisioning`. Off-domain users created this way are not auto-verified — they receive a verification email and cannot sign in via SSO until they click the link. *WARNING*: As the user is provisioned without a password, the use of this endpoint is only intended on environments with SSO Active. *WARNING*: If your enterprise is not capturing the user's email domain, it is possible this will fail with a conflict against an already created user that is not a member of your enterprise (and this not visible when [listing users](/api/list-scim-users)). If this occurs, it is recommended you add the user to your enterprise (e.g. add them to a workspace and then claim them).
- scim
- Create table
- Creates a new table and returns the schema for the newly created table. Refer to [field types](/api/model/field-type) for supported field types, the write format for field options, and other specifics for certain field types. Supported field types have a write format shown. At least one field must be specified. The first field in the fields array will be used as the table's primary field and must be a supported primary field type. Fields must have case-insensitive unique names within the table. A default grid view will be created with all fields visible.
- table
- Create workspace
- Creates a new workspace with the provided name within the specified enterprise account and returns the workspace id. The requesting user must be an active effective admin of the enterprise account; the created workspace's owner will be the user who makes the request.
- workspace
- Delete a webhook
- Deletes a webhook. **Creator level permissions are required in order to delete a webhook.**
- webhooks
- Delete base
- Deletes the specified base. Deleted bases can be restored by workspace owners from the Trash UI, up to the workspace's billing plan retention period.
- workspace
- Delete base collaborator
- Delete a base collaborator.
- collaborators
- Delete base invite
- Delete a base invite. The invite must be [outstanding](/api/org-management-glossary#outstanding-invite).
- invites
- Delete block installation
- A deleted block installation is recoverable.
- block
- Delete comment
- Deletes a comment from a record. Non-admin API users can only delete comments they have created. Enterprise Admins can delete any comment from a record.
- comment
- Delete interface collaborator
- Delete an interface collaborator. Requires base collaborator access to remove others, but can be used to remove yourself even with interface-only collaborator access.
- collaborators
- Delete interface invite
- Delete an interface invite. The invite must be [outstanding](/api/org-management-glossary#outstanding-invite).
- invites
- Delete multiple records
- Deletes records given an array of record ids
- record
- Delete record
- Deletes a single record
- record
- Delete group
- Delete a single [SCIM Group](https://datatracker.ietf.org/doc/html/rfc7643#section-4.2).
- scim
- Delete user
- Delete a single SCIM user. The endpoint cannot be used to delete the admin that owns the authentication token used to make the request. The endpoint cannot be used to delete the sole owner of a workspace that has multiple collaborators. See [SCIM specification](https://datatracker.ietf.org/doc/html/rfc7644#section-3.6) for more.
- scim
- Delete share
- **WARNING:** Hard deleted share is NOT recoverable!!!
- shares
- Delete user by id
- Delete ELA enterprise account [internal](/api/org-management-glossary#internal-users) users and "claiming" enterprise account [managed](/api/org-management-glossary#managed-user) users.
- user
- Delete users by email
- Delete multiple users by email.
- user
- Delete view
- Delete a view.
- view
- Delete workspace
- Deletes the specified workspace. Deleted workspaces can be restored by workspace owners from the Trash UI, up to the workspace's billing plan retention period. **WARNING:** If the API user is not currently a workspace owner (one example where this can happen is if the API user is an enterprise admin), the workspace will not show up in the user's Trash. **WARNING:** Any bases in the deleted workspace will no longer be accessible, be sure to double check whether there are any actively used bases before proceeding with workspace deletion. If you want to retain access to these bases, you should transfer the bases to another workspace before deleting the workspace.
- workspace
- Delete workspace collaborator
- Delete a workspace collaborator.
- collaborators
- Delete workspace invite
- Delete a workspace invite.
- invites
- Enable/disable webhook notifications
- Enables or disables notification pings for a webhook. See [notification delivery](/api/webhooks-overview#webhook-notification-delivery). **Creator level permissions are required in order to enable or disable webhook notification pings.**
- webhooks
- Get audit log request
- **NOTE:** Use of this API is discouraged for new use cases. Prefer to use the [audit log events API](/api/audit-logs-overview) instead. Retrieve a specific audit log request.
- auditing
- Get base collaborators
- Returns basic information on the base. Does not include deleted collaborators and only include [outstanding](/api/org-management-glossary#outstanding-invite) invites.
- base
- Get base schema
- Returns the schema of the tables in the specified base.
- base
- Get eDiscovery export
- Get the status and result of an eDiscovery export.
- changeEvents
- Get enterprise
- Returns basic information relevant to the enterprise account.
- enterprise
- Get interface
- Returns general information about the interface. Does not include deleted collaborators and only includes [outstanding](/api/org-management-glossary#outstanding-invite) invites. `pageBundleId` is the ID of the interface and can be found in the [`interfaces`](/api/get-base-collaborators#response-interfaces) object returned by the [get base collaborators](/api/get-base-collaborators) endpoint.
- collaborators
- Get record
- Retrieve a single record. Any "empty" fields (e.g. **""**, **[]**, or **false**) in the record will not be returned. **Note** If we can't locate the record on a given table, the request will fallback to a base wide search and will still return the record if the Record ID is valid and the record is located within the same base.
- record
- Get group
- Get a single group as a [SCIM Group](https://datatracker.ietf.org/doc/html/rfc7643#section-4.2) object.
- scim
- Get user
- Get a single user as a [SCIM User](https://datatracker.ietf.org/doc/html/rfc7643#section-4.1) object.
- scim
- Get user by id
- Returns basic information relevant to both [internal](/api/org-management-glossary#internal-user) and [external](/api/org-management-glossary#external-user) user.
- user
- Get user group
- Returns basic information relevant to the user group.
- userManagement
- Get user info
- Retrieve the user's ID. For OAuth access tokens, the scopes associated with the token used are also returned. For tokens with the `user.email:read` scope, the user's email is also returned.
- whoAmI
- Get users by id or email
- Returns basic information relevant to both [internal](/api/org-management-glossary#internal-user) and [external](/api/org-management-glossary#external-user) user.
- user
- Get view metadata
- Get basic information of base view.
- view
- Get workspace collaborators
- Returns basic information on the workspace. Does not include deleted collaborators and only include [outstanding](/api/org-management-glossary#outstanding-invite) invites.
- collaborators
- Grant admin access
- Grant admin access to users. To use this endpoint, provide either the user's `id` or `email` in the request body. If both are supplied, the `email` will be ignored. In the example request provided, the first two users are successfully processed while all of the remaining users are not processed and are returned in the `errors` array with the reason why they were not able to be processed.
- user
- Delete records
- Delete records from a HyperDB table with primary keys matching specified primary keys
- hyperDBenterprise
- Read records
- Read records from a HyperDB table
- hyperDBenterprise
- Update or insert records
- Update or insert records from a HyperDB table with primary keys matching specified primary keys
- hyperDBenterprise
- List audit log requests
- **NOTE:** Use of this API is discouraged for new use cases. Prefer to use the [audit log events API](/api/audit-logs-overview) instead. Retrieve all audit log requests.
- auditing
- List bases
- Returns the list of bases the token can access, 1000 bases at a time. If there is another page to request, pass the offset as a URL query parameter. (e.g. `?offset=itr23sEjsdfEr3282/appSW9R5uCNmRmfl6`)
- base
- List block installations
- Lists basic information of base block installations.
- block
- List comments
- Returns a list of comments for the record from newest to oldest. Note: Comments in reply to another comment (where `parentCommentId` is set) may not have their parent comment in the same page of results and vice versa.
- comment
- List eDiscovery exports
- Get the status and result of all eDiscovery exports.
- changeEvents
- List packages
- List all packages for an enterprise account
- enterprise
- List personal access tokens
- List personal access tokens for users administered by this enterprise account. Only supported for root (organization-level) enterprise accounts; a request for a descendant (org unit) enterprise account returns an error. For enterprise-scoped tokens, resourceAccess.enterpriseAccountId is returned only when the scoped enterprise is the requested root enterprise account or one of its descendants.
- enterprise
- List records
- List records in a table. Note that table names and table ids can be used interchangeably. We recommend using table IDs so you don't need to modify your API request when your table name changes. The server returns one page of records at a time. Each page will contain **pageSize** records, which is 100 by default. If there are more records, the response will contain an **offset**. To fetch the next page of records, include **offset** in the next request's parameters. Pagination will stop when you've reached the end of your table. If the **maxRecords** parameter is passed, pagination will stop once you've reached this maximum. Returned records do not include any fields with "empty" values, e.g. **""**, **[]**, or **false**. You can filter, sort, and format the results with query parameters. Note that these parameters need to be URL encoded. You can use our [API URL encoder tool](https://codepen.io/airtable/pen/MeXqOg) to help with this. If you are using a helper library like [Airtable.js](https://github.com/Airtable/airtable.js), these parameters will be automatically encoded. **Note** Airtable's API only accepts request with a URL shorter than 16,000 characters. Encoded formulas may cause your requests to exceed this limit. To fix this issue you can instead make a POST request to `/v0/{baseId}/{tableIdOrName}/listRecords` while passing the parameters within the body of the request instead of the query parameters.
- record
- List groups
- List groups as [SCIM Groups](https://datatracker.ietf.org/doc/html/rfc7643#section-4.2) objects. [SCIM specification for list responses.](https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2)
- scim
- List users
- List users as [SCIM User](https://datatracker.ietf.org/doc/html/rfc7643#section-4.1) objects. See the SCIM specification for [list responses](https://datatracker.ietf.org/doc/html/rfc7644#section-3.4.2) for more.
- scim
- List shares
- Lists basic information of base shares.
- shares
- List views
- Lists basic information of base views.
- view
- List webhook payloads
- Enumerate the update messages for a client to consume. Clients should call this after they receive a ping. The webhook payload format can be found [here](/api/model/webhooks-payload) and uses [V2 cell value format](/api/field-model). Calling this endpoint will also extend the life of the webhook if it is active with an expiration time. The new expiration time will be 7 days after the list payloads call.
- webhooks
- List webhooks
- Lists all webhooks that are registered for a base, along with their statuses. **Read level permissions are required in order to list webhooks.**
- webhooks
- Logout user
- Logout the user. Only available for ELA and FLA [internal](/api/org-management-glossary#internal-user) enterprise account users and [managed](/api/org-management-glossary#managed-user) "claiming" enterprise users.
- user
- Manage block installation
- Manages block installation state.
- block
- Manage share
- Manages share state.
- shares
- Manage user
- Manage enterprise account [managed](/api/org-management-glossary#managed-user) users.
- user
- Manage user batched
- Batch manage enterprise account users. One of `id` or `email` must supplied in the body. If both are supplied, `id` will be used as the identifier in changing user email to the `email` specified in the request. *WARNING:* We recommend performing actions on up to 10 users at a time to avoid timeouts. Though we currently do not enforce a limit on the number of users you can manage at once, we are monitoring the performance of this endpoint and may enforce a limit in the future.
- user
- Manage user membership
- Batch manage organizations enterprise account users. This endpoint allows you to change a user's membership status from being unmanaged to being an organization member, and vice versa. To use this endpoint, provide either the user's `id` or `email` in the request body. If both are supplied, the `email` will be ignored. This endpoint can only be used if your enterprise is not domain capturing. In the example request provided, the first two users are successfully processed while all of the remaining users are not processed and are returned in the `errors` array with the reason why they were not able to be processed. Note that the domain of the user you are trying to claim must be verified in your organization's Admin Panel. If the domain is not verified, the user will not be claimed and will be returned in the `errors` array. For more information on managing users and the different types of users in organizations, please see [our support article](https://support.airtable.com/docs/using-organizations).
- user
- Move base
- Move a base between two workspaces owned by the enterprise.
- workspace
- Move user groups
- Batch move user groups between two enterprise accounts belonging to the same organization. This endpoint can only be used if your enterprise account has the Enterprise Hub feature enabled. If the target enterprise account has the invites settings restricted to org unit members, group members who are non-org unit members will be removed when the user groups are moved. For more information about invites settings, please see [our support article](https://support.airtable.com/docs/settings-airtable-admin-panel#sharing-and-data-in-the-admin-panel).
- userManagement
- Move workspaces
- Batch move workspaces between two enterprise accounts belonging to the same organization. This endpoint can only be used if your enterprise account has the Enterprise Hub feature enabled. If the target enterprise account has the invite settings restricted to org unit members, all non-org unit member collaborators will be removed when the workspaces are moved. For more information about invites settings, please see [our support article](https://support.airtable.com/docs/settings-airtable-admin-panel#sharing-and-data-in-the-admin-panel).
- workspace
- Patch group
- SCIM patch an array of operations to a Group and applies them sequentially. See [SCIM specification](https://datatracker.ietf.org/doc/html/rfc7644#section-3.5.2) for more.
- scim
- Patch user
- Perform a list of SCIM patch operations in sequence on an existing user. See [SCIM specification](https://datatracker.ietf.org/doc/html/rfc7644#section-3.5.2) for more.
- scim
- Sync CSV data
- Syncs raw CSV data into a Sync API table. You must first set up a sync from a base (instructions in this [support article](https://support.airtable.com/docs/airtable-sync-integration-api-endpoint)). The **apiEndpointSyncId** in the path parameters can be found in the setup flow when creating a new Sync API table, or from the synced table settings. The CSV data can contain up to 10k rows, 500 columns, and the HTTP request's size is limited to 2 MB. Up to 10k rows will be synced per sync run. If you send two requests that each contain a CSV with 10k rows before a sync run occurs, then only 10k rows will be synced. There is a rate limit of 20 requests, per 5 minutes, per base for this endpoint.
- record
- Put group
- Replace a Groups's attributes with all new values.
- scim
- Put user
- Replace a user's attributes with all new values. The body parameters are the same as those for [creating a user](/api/create-scim-user), except that you can set `active` to true or false.
- scim
- Refresh a webhook
- Extend the life of a webhook. The new expiration time will be 7 days after the refresh time. Note that this endpoint only applies to active webhooks with an expiration time. **Creator level permissions are required in order to refresh a webhook.**
- webhooks
- Remove user from enterprise
- Unshare a user from all enterprise workspaces, bases, interfaces, and user groups. If applicable, the user will also have their admin access revoked. Returns lists of unsharing and sharing actions performed as part of the user removal.
- enterprise
- Revoke admin access
- Revokes admin access from users. To use this endpoint, provide either the user's `id` or `email` in the request body. If both are supplied, the `email` will be ignored. In the example request provided, the first two users are successfully processed while all of the remaining users are not processed and are returned in the `errors` array with the reason why they were not able to be processed. Note that you can only revoke directly assigned admin access.
- user
- Revoke personal access tokens
- Revoke personal access tokens for users administered by this enterprise account. Only supported for root (organization-level) enterprise accounts; a request for a descendant (org unit) enterprise account returns an error. The response includes both revokedTokens and errors so callers can handle partial success.
- enterprise
- Update collaborator base permission
- Updates the permission level of a collaborator on a base.
- collaborators
- Update comment
- Updates a comment on a record. API users can only update comments they have created. [User mentioned](/api/model/user-mentioned) is supported.
- comment
- Update date dependency metadata
- Update date dependency metadata for a linked predecessor on a successor record. The rowId path parameter is the successor record ID.
- record
- Update field
- Updates the name, description, and/or options of a field. At least one must be specified.
- column
- Update interface collaborator
- Use this to update permissions for an interface-only collaborator.
- collaborators
- Update multiple records
- Updates records, or upserts them when `performUpsert` is set (see below). The URL path accepts both table names and table IDs. We recommend using table IDs so you don't need to modify your API request when your table name changes. A `PATCH` request will only update the fields included in the request. Fields not included in the request will be unchanged. A `PUT` request will perform a destructive update and clear all unincluded cell values. ### Upserts Set the `performUpsert` property in your request to enable upsert behavior. When upserting is enabled, the `id` property of records becomes optional. Records that do not include `id` will use the fields chosen by [`fieldsToMergeOn`](/api/update-multiple-records#request-performupsert-fieldstomergeon) as an external ID to match with existing records. * If zero matches are found, a new record will be created. * If one match is found, that record will be updated. * If multiple matches are found, the request will fail. Records that include `id` will ignore `fieldsToMergeOn` and behave as normal updates. If no record with the given `id` exists, the request will fail and will not create a new record. The API response for upsert requests will additionally include `updatedRecords` and `createdRecords` arrays, indicating which records in the `records` array already existed and were updated, or did not exist and were created, respectively. Airtable reserves the right to throttle upsert requests differently from the [standard rate limit throttling policy](https://airtable.com/developers/web/api/rate-limits). ### Typecasting Set the `typecast` parameter to `true` to enable typecasting. When typecasting is enabled, Airtable will try to convert string values in a record's `fields` object to the appropriate cell value. This conversion is only performed on a best-effort basis. Typecasting is disabled by default to ensure your data's integrity, but it may be helpful when integrating with third-party services.
- record
- Update multiple records (put)
- Update multiple records. This will perform a **destructive** update and clear all unspecified cell values. Table names and table ids can be used interchangeably. We recommend using table IDs so you don't need to modify your API request when your table name changes. Your request body should include an array of record objects. Each of these objects should have an **id** property representing the record ID and a **fields** property which contains all of your record's cell values by field name or field id for all of your record's cell values by field name. To issue an upsert request, where records would be created if no matching records to update are found, your request body should include a **performUpsert** parameter with **fieldsToMergeOn**. **fieldsToMergeOn** is an array with at least one and at most three field names or ids, where combined together, represent a unique record. Fields to merge on cannot be computed and must be of the following field types: number, text, long text, single select, multiple select, and date. In this case, the id property within record objects is optional. In addition to **records**, **updatedRecords** and **createdRecords** will be included as part of the response, containing record ids to specify which records were created or updated. Airtable reserves the right to throttle upsert requests differently from the standard rate limit throttling policy. Automatic data conversion for update actions can be enabled via **typecast** parameter. The Airtable API will perform best-effort automatic data conversion from string values if the **typecast** parameter is passed in. Automatic conversion is disabled by default to ensure data integrity, but it may be helpful for integrating with 3rd party data sources.
- doNotRender
- Update record
- Updates a single record. Table names and table ids can be used interchangeably. We recommend using table IDs so you don't need to modify your API request when your table name changes. A **PATCH** request will only update the fields you specify, leaving the rest as they were. A **PUT** request will perform a destructive update and clear all unspecified cell values. Your request body should include a **fields** property whose value is an object containing your record's cell values, keyed by either field name or field id. Automatic data conversion for update actions can be enabled via **typecast** parameter. The Airtable API will perform best-effort automatic data conversion from string values if the **typecast** parameter is passed in. Automatic conversion is disabled by default to ensure data integrity, but it may be helpful for integrating with 3rd party data sources.
- record
- Update record (put)
- Updates a single record. Any unspecified fields are **not updated**. Table names and table ids can be used interchangeably. We recommend using table IDs so you don't need to modify your API request when your table name changes. Your request body should include a **fields** property whose value is an object containing your record's cell values, keyed by either field name or field id. Automatic data conversion for update actions can be enabled via **typecast** parameter. The Airtable API will perform best-effort automatic data conversion from string values if the **typecast** parameter is passed in. Automatic conversion is disabled by default to ensure data integrity, but it may be helpful for integrating with 3rd party data sources.
- doNotRender
- Update table
- Updates the name, description, and/or date dependency settings of a table.
- table
- Update workspace AI allowlist
- Add or remove workspaces from the enterprise AI allowlist. Accepts up to 10 workspaces per request. Only applicable when the enterprise AI workspace restriction policy is set to SPECIFIED_WORKSPACES. Set includeDescendantWorkspaces to true to include workspaces from descendant org units.
- enterprise
- Update workspace collaborator
- Updates the permission level of a collaborator on a workspace.
- collaborators
- Update workspace restrictions
- Update [sharing restrictions settings](https://support.airtable.com/docs/workspace-sharing-restrictions) for the workspace.
- workspace
- Upload attachment
- Upload an attachment up to 5 MB to an attachment cell via the file bytes directly. To upload attachments above this size that are accessible by a public URL, they can be added using https://airtable.com/developers/web/api/field-model#multipleattachment
- record
Airtable integration, answered
- How do AI agents use Airtable through Open Connector?
- Your user connects Airtable once with one of its cataloged authentication methods. Open Connector stores the credential in an encrypted vault and exposes Airtable tools to your agent over MCP or a typed API, with credentials injected server-side on each call.
- Is this a Airtable MCP server?
- Yes. Open Connector can serve Airtable as a named MCP server with a scoped allowlist and a per-user connection URL, so any MCP client can call Airtable actions with credentials injected server-side.
- Where do Airtable credentials live?
- In your own infrastructure. Open Connector keeps credentials in its own vault and injects them at call time, so they never leave your environment.
Give your agents Airtable — keep the keys.
Open source, self-hostable, with Airtable credentials that never leave your infrastructure. Run it from source today.