Push your approved Notion content calendar into Sprout Social

Every day at 6am, push my approved content calendar from Notion into Sprout Social so nobody has to retype captions.

Start by reading the calendar. Use Notion's Query a Data Source operation, which is the current replacement for the deprecated Query a Database, against my content calendar. Return only the rows where the status is Approved, the publish date falls within the next seven days, and the Sprout draft id property is still empty. For each row that comes back, read the caption, the target networks, the publish date and time, and any image URL.

Skip any row with an empty caption or no target network, and leave its status untouched so it still shows up in the calendar as needing work. Do not write anything back to a skipped row.

Where an image URL is present, call Sprout Social's Upload Media operation to fetch the image from its public URL, and attach it to the post within the same run. Uploaded media expires 24 hours after upload unless it is attached to a post, so never split the upload and the post creation across separate runs.

Resolve the target networks to profiles before creating anything. Call List Customer Profiles and map each target network named on the row to the matching connected profile. Sprout identifies post targets by customer profile id rather than by network name, so this mapping step is required. If a row names a network with no matching connected profile, skip that row and leave its status untouched as well.

Then call Create Publishing Post with the caption, the resolved profile ids, any uploaded media, and the row's publish date and time as the scheduled send time. Sprout's publishing API creates drafts only: is_draft must be true, and the delivery type only accepts SCHEDULED. The result is a scheduled draft sitting in the Sprout publishing calendar waiting for a human to approve and send it. Never describe this as publishing automatically.

Finally use Notion's Update a Page operation to write the returned draft id back onto the row's Sprout draft id property and flip its status to Scheduled. This write back, combined with the empty draft id filter in the first step, is the whole idempotency design: a row that has already been pushed will not match tomorrow's query, so the same caption never lands in Sprout twice. If creating a draft fails for a given row, leave that row completely untouched so it is picked up again on the next run.

Every step here is deterministic, so build this as a code workflow: a filtered database read, a field mapping, two creates, and a write back. There is no drafting, ranking, or judgement anywhere in the chain.