Generate Barcode Label PDFs from Airtable Records

Generate a label PDF from a selected Airtable record, then attach the finished file to that record. Use one automation script to submit the request and a second to check its saved job ID.

This approach keeps an unfinished PDF job separate from the trigger that creates it. It uses Airtable’s scripting action and Gookit’s HTTP API, not a native connector. The scripts have offline mapping and job-handling tests, but have not been run in a live Airtable base. Verify the automation and attachment import in a test base before activation.

Prepare the table and template

Create a test table named Labels with these fields:

Use a text SKU field to preserve identifiers with leading zeros. The scripts expect the exact field types above; Label status is text rather than a single-select object.

Create the 50 × 30 mm name/SKU template in your Gookit developer account. A key from that account and its template ID are the two Gookit settings you need.

Configure the submission action

• airtable-submit.js
• airtable-check.js

Create an automation with a deliberate test trigger for one selected record. Add Run a script and paste airtable-submit.js. Configure input variables recordId from the trigger and templateId from your saved template. Add a secret named GOOKIT_API_KEY using the script editor’s secrets feature.

Airtable’s Run a script documentation explains input variables, secrets, output values and plan restrictions. Confirm the action is available on your workspace; do not assume a trial includes it.

The script validates the record, rejects one that already has a Job ID, sends one print request and writes the returned ID to the record. It also exposes jobId as action output so the response remains available if the record update fails.

Check the saved job separately

Create a second manually tested automation using airtable-check.js, with recordId and the same secret. Run it after the first automation succeeds.

For pending or processing output, the script updates Label status and keeps the job ID. For completed output, it passes the temporary PDF URL to the attachment field. Verify that Airtable finishes importing the attachment and that the downloaded file opens correctly.

The example does not run an unbounded loop inside an automation action. If you later schedule checks, choose a schedule that fits your Airtable limits and check only unfinished records. Keep job submission out of that polling automation.

Check what the record requested

One record with Copies set to two produces two labels. With the ROLL template, expect two PDF pages containing the same SKU. For a combined file across multiple records, first build a single items array and submit it once; the provided script intentionally handles one record per job.

Changing Copies after submission does not change the existing job. A reprint is a separate action. Preserve the previous job ID in your own history before clearing it for a deliberate new request.

Handle uncertain outcomes

Keep automatic retries off on submission until you can distinguish rejection from a timeout after acceptance. The Job ID guard protects an ordinary repeat after the field was saved; it cannot prevent concurrent runs or repair a failed write automatically.

For 429, wait for Retry-After before checking again. For failed, inspect the API error before replacing the job. The scripts retain the ID rather than hiding the failure by starting a new batch.

After the sample file is correct, test the intended stock and printer at Actual Size. Airtable delivery and physical printing are separate steps.