Airtable Batch Processing Subprocess

• Subprocess Functionality: Designed to be called by other workflows.
• Batch Operations: Supports insert, update, and upsert operations for multiple records.
• Dynamic Routing: Routes requests to the correct Airtable API endpoint based on the mode parameter.
• Rate Limit Handling: Includes logic to detect and wait for 429 Too Many Requests status codes to prevent API throttling.
• Data Transformation: Prepares data for Airtable API calls, including structuring fields and handling id for updates.
• Error Handling: Implements retries for HTTP requests.

This workflow is intended to be executed as a subprocess.

1. Trigger: It is designed to be triggered by an Execute Workflow node (e.g., Airtable Batch node in the provided JSON).
2. Inputs: The Airtable Subprocess trigger node expects the following inputs:
   • baseId: Your Airtable Base ID (e.g., appXXXXXXXXXXXXX).
   • tableIdOrName: The ID or name of your Airtable Table (e.g., tblXXXXXXXXXXXXX).
   • mode: The operation mode. Accepts upsert, insert, or update.
   • fieldsToMergeOn (optional, for upsert mode): An array of field names to use for matching records (e.g., ["field1", "field2"]).
   • records: An array of record objects, where each object contains the fields to be sent to Airtable. For update mode, records must include an id field.

Workflow Logic:

• The Airtable Subprocess node receives the input data.
• The Split Out node separates the records array.
• The batch 10 node groups records into batches of 10.
• The Switch node directs the batched records based on the mode input:
  • update: Processes through Edit Fields4 (to extract id and fields) -> Aggregate3 -> update HTTP Request.
  • upsert: Processes through Edit Fields1 (to extract fields) -> Aggregate1 -> upsert HTTP Request.
  • insert: Processes through Edit Fields2 (to extract fields) -> Aggregate2 -> insert HTTP Request.
• Each of the Airtable HTTP request nodes (upsert, insert, update) checks for a 429 status code using the rate limit? nodes.
• If a 429 is detected, a Wait node is triggered (0.2s for upsert, 5s for insert, 5s for update) followed by a retry request node to re-attempt the operation.
• The return merged output node aggregates the results from the different branches.