Turn approved Airtable calendar rows into scheduled social posts

Every 15 minutes, sync my Airtable content calendar into bundle.social so that approved posts get scheduled automatically and nobody has to copy paste between the two tools. Build this as a code workflow on a cron trigger. Every step is deterministic, so there is no drafting or judgement involved.

Start with Airtable List Records against my content calendar table, filtering for rows where Status is Approved and the bundle.social post id field is still empty. That pair of conditions is what makes the run safe: a row is only eligible if a human approved it and it has not already been scheduled. List Records paginates, so follow the offset until every matching row has been collected before processing any of them.

For each matching row, pull the image across first. Take the URL of the image attachment on the row and call bundle.social Create upload from URL to add it to the team media library. bundle.social posts reference an uploadId rather than a raw file or an external URL, so this upload has to happen before the post is created, and the returned uploadId is what gets attached to the post.

Then call bundle.social Create post to schedule it. Set the scheduled time from the row's Publish At field, converting to UTC. Target the platforms named in the row's multi select field, mapping each one to the bundle.social platform value such as INSTAGRAM, FACEBOOK, LINKEDIN, TWITTER, TIKTOK, YOUTUBE or THREADS. Attach the uploadId from the previous step and use the row's copy as the post text. Set referenceKey on the post to the Airtable record id. referenceKey is a caller supplied idempotency key that can be looked up afterwards with Get post by reference key, so if a run is retried, or one run overlaps the next, the same row can never become two posts.

Finally, write the result back to Airtable with Update Record on the same record id: store the returned bundle.social post id in the post id field, and flip Status from Approved to Scheduled. That write back is what stops the next run 15 minutes later from picking the same row up again, so it has to happen for every row that was scheduled successfully. Airtable Update Record is a PATCH, so only those two fields change and everything else the team put in the row is left untouched.

A few constraints to respect. Airtable create and update operations cap at 10 records per batch, so chunk the write backs rather than sending them all at once. bundle.social counts scheduled posts against the plan quota at scheduling time in UTC and drafts are exempt, so each row must be scheduled exactly once. If a row has no Publish At time, no platforms selected, or no image attachment, skip it and leave its Status as Approved rather than scheduling something incomplete. If Create post fails for a row, do not write back to Airtable for that row, so it stays eligible and the next run retries it.