Help

Feature Request: Adding Workspace IDs/routes to base metadata

Topic Labels: API
1111 0
cancel
Showing results for 
Search instead for 
Did you mean: 
Matthew_Thomas
7 - App Architect
7 - App Architect

Use case

The recently released, in beta, Metadata API is a great start to a long requested feature by developers here. Providing programmatic access to a user’s base IDs/names is immensely helpful and should help simplify many development workflows.

One addition that I’m sure would be helpful for many developers is adding information and routes to tailor API requests based on a specific Airtable Workspace. While many users and organizations probably limit the number of workspaces they have based on features/pricing (e.g. have 1 Pro workspace where bases that need custom apps and scripting live, and have ‘N’ free workspaces to more logically group bases that don’t need pro features).

For my own account, a simplified version of the workspace I have access to is:

  1. Work (Pro account; bases relevant to all departments)
  2. Work (Free account; bases relevant to my specific team)
  3. Personal
  4. Testing

Many of the Airtable apps I develop are targeted towards workspace #1: the cross-cutting, company-wide bases and deal with referencing data from one base or another. To accomplish these tasks, I reference the base IDs in a separate “Directory” base that I can access programmatically.

The introduction of the metadata API should obviate the need for manually creating/updating this “Directory” base, as bases are added, changed, or deleted. However, being able to separate operations by workspace would be most helpful, even if just by work vs. personal workspaces at the simplest. Without being able to filter results, I see the utility of the metadata API to be limited.

Proposed addition

  1. Adding “workspaceId” data to base data returned by /v0/meta/bases

    • Perhaps the easiest change from a backend architecture perspective. As the docs note, “adding keys to response objects [is not considered] a breaking change”.
    • API calls would still return all bases, but the caller could then filter the array based on workspaceId.
      {
          "id": "appXXXX",
          "name": "My first base",
          "permissionLevel": "create",
          "workspaceId": "wspXXXX",
      }
    
    
  2. Adding new /v0/meta/workspaces and /v0/meta/workspaces/WorkspaceId/bases routes

    • Would allow users to filter results and only request the data relevant to their needs.
    • Would allow additional targeting of Apps, Scripts, and other Airtable integrations to bases in specific workspaces
      // /v0/meta/workspaces
      {
         "workspaces": [
              {
                  "id": "wspXXXXX",
                  "name": "My first workspace"
              },
             ...
         ]
      }
    
      // /v0/meta/workspaces/WorkspaceId/bases
      {
         "bases": [
              {
                  "id": "appXXXXX",
                  "name": "My first base"
              },
              ...
         ]
      }
    
0 Replies 0