Release identity
SHA-256 of the pack file bytes: 77bbbd3b60864bbd58bfde7f39c51c9ab9d533bc86d0ae29ab07b8e6d9572f8d
Not in the distributable release manifest. The binary carries a digest-bound manifest of the distributable library; a pack whose bytes differ from its manifest entry — endpoint, tier, allowlist, or credential edited, with provider, version, and review block preserved — fails the digest check, loses distributability, and renders MODIFIED rather than as the shipped reviewed artifact. Review state and artifact status are different facts: the first is a documentation-review declaration, the second is the identity of the exact bytes.
Capabilities (5)
airtable.records.read v1.0.0R0
- Action
- read
- Endpoint
GET https://airtable-api.invalid/v0/BASE_ID/TABLE_ID_OR_NAME- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-airtable-token- Data class
- pii
List records in one table as a collection read. The retrieved documentation states results are paginated by offset (default page of 100), that empty-valued fields are omitted from returned records, and that the GET form is limited to URLs under 16,000 characters — longer filter formulas must use the registered POST form instead. Table records frequently describe people, so the read is registered at the pii class; declare internal only after the owner classifies the base.
airtable.records.search v1.0.0R0
- Action
- read
- Endpoint
POST https://airtable-api.invalid/v0/BASE_ID/TABLE_ID_OR_NAME/listRecords- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-airtable-token- Data class
- pii
The POST form of list records, registered read-only at the read floor: the retrieved documentation prescribes it when encoded filter formulas would exceed the GET URL length limit, passing the same parameters in the request body instead of the query string. Body shape mirrors the GET parameters — filterByFormula, fields, sort, view, pageSize, maxRecords and offset. The registration does not restrict the body; the endpoint performs no write.
airtable.records.create v1.0.0R2
- Action
- create
- Endpoint
POST https://airtable-api.invalid/v0/BASE_ID/TABLE_ID_OR_NAME- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-airtable-token- Data class
- pii
Create one or more records in one table: the retrieved documentation states the body carries either a single fields object or a records array, with an optional typecast flag for best-effort type conversion (disabled by default to protect data integrity). Created records can later be deleted, so create sits at the R2 floor for reversible writes; the registration does not restrict which fields a request may carry.
airtable.records.update v1.0.0R2
- Action
- update
- Endpoint
PATCH https://airtable-api.invalid/v0/BASE_ID/TABLE_ID_OR_NAME/RECORD_ID- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-airtable-token- Data class
- pii
Update one record: the retrieved documentation states PATCH updates only the fields specified and leaves the rest unchanged. The PUT form is deliberately not registered — the documentation states it performs a destructive update clearing all unspecified cell values, and the method restriction is one the registration actually enforces. Overwritten cell values are not recoverable through this API; update sits at the R2 floor as the vocabulary's reversible-write tier and policy can raise it for sensitive bases. RECORD_ID is a placeholder the deployment binds before enabling.
airtable.records.delete v1.0.0R3
- Action
- delete
- Endpoint
DELETE https://airtable-api.invalid/v0/BASE_ID/TABLE_ID_OR_NAME- Connector
- http
- Custody
- customer_vault
- Credential ref
secret-ref-airtable-token- Data class
- pii
Delete records from one table. Collection deletion passes one records[] query parameter per record id on the table path, with a documented batch limit of 10 records per call; the delete-multiple-records reference page returned only its document title when retrieved (attempted again on 2026-09-21), so the records[] form and the batch limit follow the Web API's long-documented REST conventions and MUST be re-verified against the operation page before enabling. Delete is one of the IRREVERSIBLE ACTIONS (delete, send, pay, deploy, approve, share and transfer) and cannot be taken without a person; deleted records are not restorable through this endpoint and this pack makes no general-reversibility claim.
Credential reference
The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.
- Reference
secret-ref-airtable-token- Custody
- customer_vault
- Injection
- header (Authorization)
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.
Resources
airtable-base(table, pii):https://airtable-api.invalid/v0/BASE_ID
Pack notes and exclusions
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 retrieved 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 retrieved 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-records reference page returned only its document title when retrieved this session, so the delete capability's method and path follow the Web API's REST conventions documented on the retrieved introduction and records pages rather than a verified endpoint page — re-verify before enabling; that gap is why this pack is a draft. 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.
Review record
Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)
- https://airtable.com/developers/web/api/introduction (retrieved 2026-09-21)
- https://airtable.com/developers/web/api/list-records (retrieved 2026-09-21)
- https://airtable.com/developers/web/api/create-records (retrieved 2026-09-21)
- https://airtable.com/developers/web/api/update-record (retrieved 2026-09-21)
- https://airtable.com/developers/web/api/delete-multiple-records (retrieved 2026-09-21)
- https://airtable.com/developers/web/api/authentication (retrieved 2026-09-21)
A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.