Catch failed social posts and alert your marketing team

When bundle.social sends a webhook telling me one of my posts has moved to ERROR status, triage the failure straight away instead of letting it fail silently. Publishing in bundle.social is asynchronous, so a post can be accepted, then quietly fail minutes later with nobody noticing until the content is missing from the feed.

Start by calling Get post in bundle.social with the post ID from the webhook, and read the errorsVerbose block on the post record. It is keyed by platform, and each entry carries a code, a userFacingMessage, an errorMessage and an isTransient flag. Treat errorsVerbose as the source of truth and handle each failing platform separately: one post can publish fine on LinkedIn and fail on Instagram, and the two need different responses.

If isTransient is true for a failing platform, call Retry post. Leave a few minutes between attempts, and give up after two retries so we never sit in a retry loop. Keep that cap explicit and do not exceed it. Failed posts still count against the organization's monthly quota, and the API enforces hard rate limits of 100 requests per second, 500 per 10 seconds and 2,000 per minute, so an uncapped retry against a failure that will never succeed burns both quota and rate limit. If the post is still in ERROR after the second retry, stop retrying and send the Slack alert described below, noting that automatic retries were exhausted.

If isTransient is false, for example an expired token or a revoked permission, do not retry at all. Retrying cannot fix an authorization problem. Go straight to alerting.

To alert, send a Slack message to my marketing channel. Name the exact social account and platform that broke. The errorsVerbose key gives the platform directly, and the error code prefix confirms the origin: META for Instagram, Facebook and Threads, TT for TikTok, LI for LinkedIn, YT for YouTube, TW for X, PIN for Pinterest, RD for Reddit, BSKY for Bluesky, MST for Mastodon, HTTP for generic API errors and NET for DNS or connection failures. If the post payload does not already identify the account clearly, call Get social account by team and type to resolve its handle or channel name so the alert names a real account rather than an ID.

Quote the userFacingMessage in plain English rather than the raw errorMessage string, and say clearly that the account needs reconnecting in bundle.social. Include the post's scheduled time and a preview of its content, roughly the first couple of hundred characters, so whoever picks it up immediately knows what did not go out and how time sensitive it is.

Optionally call Create portal link in bundle.social and include the resulting hosted URL in the Slack message as a one click reconnect link, so the person fixing it can reauthorize the account without navigating the dashboard themselves.

Do not alert for transient failures that recovered on retry. Those are noise. Only send a Slack message when a failure is non transient, or when the two retry attempts have been used up and the post is still in ERROR.