Airtable package v1.0.0

An Airtable account-issued bearer token (a personal access token with scopes chosen at creation) for the customer's account, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'Bearer', one separating space, then the token — 'Bearer <token>'. The token-issuance process is external: a person creates the token in the Airtable account's developer hub, selects scopes (for this pack, record read and record write on the specific bases the capabilities touch — the minimum that makes the capabilities work, nothing more) and hands the value to the vault; AAES creates nothing.

The authentication reference page was retrieved on 2026-09-21: it documents the two supported token types (personal access tokens and OAuth access tokens), that passing tokens via the legacy api_key URL parameter is not supported, and that scopes and base/workspace resources are configured at token creation — but it does not state token expiry behaviour, how a token is revoked in the developer hub, or whether editing scopes or disabling issuance invalidates already-issued tokens.

The deployment must therefore confirm before enabling: expiry behaviour (if any), the revocation path, and invalidation-on-edit behaviour — until confirmed, treat disabling issuance as not invalidating already-issued tokens and rotate by revoking the old value explicitly; a revoked or rejected value fails closed.

Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

The endpoint host 'airtable-api.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the real Airtable API host before enabling, in every endpoint, in the resource locator and in every egress allowlist entry — the reviewed documentation names the base path https://api.airtable.com/v0. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step. BASE_ID, TABLE_ID_OR_NAME and RECORD_ID in the endpoint paths are placeholders the deployment binds before enabling; the reviewed documentation recommends table IDs over names so a table rename does not silently redirect a registration.

Documented exclusions: this pack does not register the meta API — base, table and field schema management (creating or deleting bases or tables, altering field definitions) — webhook management, and enterprise and user administration. This pack does not register public-link or view-sharing operations. Attachment acknowledgment: excluding a separate attachment-upload operation does not exclude attachment effects — the registered airtable.records.create and airtable.records.update carry unrestricted record bodies, and Airtable attachment fields accept attachment objects by URL supplied in an ordinary record write, so a record write can attach externally-hosted files to a base; that effect is in scope of the two registered write capabilities and policy must review it there.

The PUT update form is also deliberately not registered: the retrieved update documentation states a PUT performs a destructive update that clears all unspecified cell values, while PATCH updates only the fields specified — only PATCH is registered, and because the restriction is the registered method (not caller intent about a body) it is a real restriction AAES enforces.

The delete-multiple-records reference page was retrieved on 2026-09-21 and establishes the method, path and records[] query-parameter form; the retrieved page content did not show the per-call batch limit, so the completed review makes no batch-limit claim (see the capability description); the same review found token expiry/revocation behaviour unestablished in the retrieved authentication reference — the cut-off path is deleting the token in the Airtable account, and this pack makes no stronger claim.

Both gaps are documented findings of the completed review, not blockers. The Airtable authentication reference page was retrieved on 2026-09-21 and covers token types, the unsupported legacy api_key parameter, and scope/resource configuration, but not expiry or revocation behaviour; the credential note records what must still be confirmed before enabling.