Create posts in bulk

Creates many social posts in one request. The rows travel in the request payload — there is no file upload and no CSV, just an array of the same objects POST /social/posts takes one at a time. Up to 500 rows per request.

Use case: loading a quarter of content in one call. Your planning tool has the client's whole content calendar. Build one row per slot, tag each with your own clientReference, and send them together. The batch either succeeds as a unit or tells you precisely which rows to fix. Store the returned job.id and poll GET /social/bulk-posts/{bulkJobId} until status is terminal, then reconcile each result by its clientReference.

The whole batch is validated up front

Validation runs across every row before anything is created, and the batch is atomic at that stage:

• If any row is invalid, nothing is created. success is false, SY95050 comes back in error, and each bad row appears in job.results[] with its 0-based index, its clientReference, and the reason in errors[]. Fix those rows and resend the whole batch.
• If every row is valid, a job is queued, success is true, and you get a job.id. Individual rows can still fail later, when the platform rejects them at publish time; that shows up on the job, not here.

Reconcile by clientReference where you can and by index otherwise — the rows themselves are not echoed back, so those two fields are the only link to your own data.

Notes.

• The request body must be wrapped in an input object, with the rows in input.posts.
• Check success, not the HTTP status. A batch-wide rejection is an HTTP 200 with success: false and SY95050 in error.
• Maximum 500 rows per request. A larger array is rejected outright with SY95048 and nothing is created; split it and send several batches.
• The brand on each row is socialProfileId. brandId is only ever a URL path token, and this route has no path token at all.
• Rows may target different brands. Each row's platforms are checked against that row's own brand, so a platform connected on one brand and not another fails only the rows that need it.
• Each row follows the same schedule rules as a single post: scheduledAt or scheduleDate + scheduleTime, never both, and scheduleDate / scheduleTime are read in that row's brand timezone. Mixing the two forms across different rows in one batch is fine.
• Rate limits apply to the request, not to the rows: a 500-row batch costs one request against your budget. See Rate limits.

Write operation: not executed against the live account. The request and response shown are built from the API schema; this publishes to real social accounts when run.