The Integration Registry: Knowing What Depends on Your Base Before You Change It

Someone wants to change the Discount field on the Deals table from a percentage to a single select. Inside the base, the question of what that breaks has an answer for most of it: Airtable’s field manager lists the automations, configurations, fields, interfaces, syncs, and views that depend on it.

Outside the base, the connections are just as real, but nothing shows them: the billing system that reads Discount every night, the quoting tool that writes to it, and the partner whose payload carries it don’t appear in the field manager or anywhere else in Airtable.

An integration registry is the record that answers the outside half. InAir's guide to running Airtable inside complex system landscapes argues that a governed base stays changeable, and that impact analysis "is only possible because the dependencies were registered somewhere." This post covers what that record needs to hold, how to build it in Airtable, how to keep it current, and how to use it before a change.

Where Existing Registries Stop

InAir's guide to controlling enterprise Airtable sprawl already sets up a Sync Registry Base, whose API Integrations table "tracks external systems reading/writing to the bases (Integration Name, Client ID/Service Account, Integration Tool, Authorized Scopes, and Developer Email)."

The same base records which fields each sync carries, in its Sync Connections and Mapped Fields tables. For external integrations, though, the API Integrations table stops at authorized scopes, so it doesn’t record which fields each integration reads or writes.

The difference matters at the moment of a change. The same guide's change protocol asks you to verify that changing a field type "does not break external REST API configurations." A registry that knows an integration holds data.records:read on a base can't tell you whether that integration reads Discount. A registry that links integrations to fields can.

So the registry in this post extends that base. It keeps the API Integrations record, links each integration to the fields it reads or writes, and adds when it runs, who owns it and what it has been promised.

What the Registry Records

For each integration, the registry holds six things.

• Identity and access. The integration's name, the tool it runs in, and the token or service account it uses. This is the part the API Integrations table already holds.
• Fields, by direction. Every table and field the integration reads, and every one it writes, recorded separately. A field two integrations write is where ownership has to be decided, and a field one writes and others read is where a change spreads.
• Trigger and schedule. Whether it runs on a webhook, on a button, on a record change, or on an interval, and how often.
• Business owner. The person or role who decides whether the integration should change, alongside the developer who maintains it. A schema change needs the first; a fix needs the second.
• Contract. For an integration that receives a scoped payload, the contract version and the keys it expects. For one that still reads directly, a note that it has no contract.
• Last confirmed. The date someone last checked that the entry still matches what the integration does.

Fields are recorded by ID as well as by name. Airtable's Get base schema endpoint returns every table and field with its ID, so an entry can store the ID and refresh the name, and a rename doesn't orphan the registry.

Building It in Airtable

The registry lives in the same Sync Registry Base. It uses two tables that base already has and adds a junction table between them.

Field Access is a junction table. An integration touches many fields and a field is touched by many integrations, and a junction record per pair, with its own Read and/or Write value, keeps both sides queryable without duplicating either.

From an API Integrations record, a lookup through Field Access lists every field it touches. From a Mapped Fields record, a lookup of the Integration link lists every integration that depends on it.

Two filtered views do most of the day-to-day work. One shows Mapped Fields where a rollup of Field Access, counting only the records where Access includes Write, is greater than one, which is a list of the places where ownership needs to be decided. The other shows API Integrations whose Last confirmed date is older than the review interval, which is the list of entries that may no longer be true.

Keeping It Current

A registry is only as useful as its last update, and it decays in the same way the base does: quietly, through ordinary work. Three habits keep it accurate.

1. Register before go-live. A new integration, token or webhook gets its registry entry before it's switched on, not after. The governance guide frames the same step as "a registration ledger whenever a new API integration, OAuth connection, or webhook is deployed." Whoever is building the integration knows exactly what it touches, so that's when the fields get recorded.
2. Update it as part of the change. Changing what an integration reads or writes includes changing its entry. A change isn't finished while the registry still describes the old version.
3. Confirm on a schedule. Each owner confirms their entries at a fixed interval, and the Last confirmed date moves forward. An entry nobody will confirm is a strong sign of an integration nobody owns.

Two of those moments are also when an assessment goes stale. InAir's Integration Load framework names a new system being onboarded, or an integration involved in ownership or failure detection being modified, among the events that should trigger a fresh assessment. A registry that's updated at those points gives each new assessment a current starting list.

Using It Before a Change

Back to the Discount field. With the registry in place, the impact analysis is a lookup, not a search.

1. Find the field. Open the Discount record in the Mapped Fields table.
2. Read its Field Access links. In this example, three integrations touch it: the billing system reads it nightly, the quoting tool writes it on every quote, and a partner receives it in a scoped payload at contract version 2.
3. Contact the owners. The business owner of each integration decides whether the change is acceptable. The billing system's developer checks whether a single select breaks its parsing. The quoting tool needs to write option names instead of numbers. The partner's contract changes a type, so it needs a new version, agreed before the field changes.
4. Check the inside of the base. The field manager's Dependencies view covers the automations, configurations, fields, interfaces, syncs and views that depend on the field, and any script that references it needs its own search. The trace in Blast Radius follows those internal consumers further down the chain.
5. Make the change, then update the registry.

Without the registry, step 2 is a question sent to every team that might be involved, and the answer is only as complete as the replies.

This is the discipline Ian Robinson describes on Martin Fowler's site as consumer-driven contracts: a provider can change safely when it knows what each consumer actually depends on. The registry is where an Airtable base keeps that knowledge.

What the Registry Doesn't Do

A registry records what integrations are supposed to touch. It doesn't watch what they actually do. An integration that reads directly through the API can start using a new field without anyone updating its entry, which is one more reason to move direct readers onto scoped payloads, where a field only goes out when someone adds it to the script. And an entry is only as reliable as its last confirmation, which is why that date sits on every record.

If you want to know what depends on your bases before the next schema change, rather than after it, Schedule a Discovery Call with InAir and we'll build the first version of the registry with you.