Developer & Agents•
6 min read
•
2026-10-20 · Updated 2026-10-20

Monitor social publishing failures without duplicate posts

Save the first post ID, inspect every destination and stop polling with an explicit outcome. A timeout must not quietly create a second upload.

By Reeling product team. Examples describe the documented implementation; no live publishing test is implied.

Save the receipt before doing anything else

A publishing request can create a post before the client receives its response. Store the post ID, selected channel, project, timestamp and a non-secret reference to the original media. Record the intended visibility too: a completed private upload is not a public campaign post.

Do not put API keys or private response bodies in shared logs. If a POST times out before a post ID returns, the outcome is ambiguous. Check the account’s existing posts and request context before submitting the same file again.

Read the destination results separately

The Reeling status endpoint returns a top-level status and a publish_results array. Inspect each destination’s published flag, upload_status, public URL and error. A request can be accepted while the video is processing, and one destination can fail after another succeeds.

A mixed result should become a mixed report. Preserve the successful destination and investigate the failed one. Do not retry the whole batch because one upload needs a corrected permission or caption.

const pendingFixture = {
  success: true, status: "processing",
  publish_results: [{
    platform: "tiktok", success: true,
    published: false, upload_status: "PROCESSING"
  }]
};
// Synthetic fixture: upload acceptance is not public publication.

Use a finite observation window

The open-source example allows up to 12 status reads, five seconds apart. It stops early for a reported publication or failure and emits timedOut when the observation window ends. A scheduled post can remain pending beyond that window without being broken.

Choose a window that fits the job and provider limits. Keep the last known state when network reads fail. Rate-limit errors should produce a wait or an explicit retry decision, not a tight loop.

node examples/poll-status.mjs
node --env-file=.env examples/poll-status.mjs --live-read

Check the type of failure before retrying

Authentication, project ownership, plan eligibility, channel permissions and media validation are different problems. A new subscription does not fix every 403, and a new upload does not fix a missing channel scope. Correct the cause using the platform’s actual response and account configuration.

If the request reached a provider, check for the existing upload first. For TikTok inbox delivery, finish the post in the mobile app rather than treating the missing public URL as a failed API request.

Close the loop with a visible destination check

A returned publication flag is the API’s report. For a real campaign, open the destination under the expected audience conditions and check the caption, media, account and visibility. Keep the public URL or the reason it cannot be verified.

Track a practical outcome such as the proportion of reviewed posts with confirmed destination URLs. Keep “accepted,” “processing,” “published” and “unknown” distinct. The sample code does not establish delivery success rates or customer performance.

Sources and related documentation

Prepare your next publishing workflow

Review the supported destinations, account requirements and current plans.

View Plans
Account requirements apply
Tags:#Publishing API#Developer workflow#Delivery status