The publishing layer for everything you build.

1. Send one approved, scheduled request

Use a Schedule Trigger to collect reviewed content on a recurring schedule. Set the workflow timezone deliberately. For a specific future publication time, send the request ahead of time and let Solnk own the final schedule.

Configure an HTTP Request node with POST https://api.solnk.com/api/v1/publishes, a stored Bearer credential, and this JSON body:

{
  "content": "Your reviewed announcement",
  "publish_mode": "scheduled",
  "scheduled_at": "REPLACE_WITH_A_FUTURE_ISO_8601_UTC_TIME",
  "targets": [{ "account_id": "REPLACE_WITH_A_CONNECTED_ACCOUNT_ID" }]
}

Replace both placeholders. Get account IDs from GET /api/v1/accounts. Persist one Idempotency-Key header value for this content revision and destination set before sending. Save the returned data.id with your source item.

Use the required scopes: accounts:read to list accounts, posts:write to create or retry, posts:read to inspect delivery, and webhooks:write to register a receiver. Team approval for member credentials still applies; check approval_status.

2. Treat notifications as a reason to read the latest state

Create an n8n Webhook receiver. Register its production URL with POST /api/v1/webhooks, using url and events containing post.published and post.failed.

Store the one-time secret securely. Verify HMAC-SHA256 through X-Solnk-Signature against the raw request body before trusting the notification. Validate raw-body handling and the event-to-publish-ID mapping with your receiver before activation.

Fetch GET /api/v1/publishes/{id} and inspect targets. A success notification can concern only some destinations. processing is unresolved; partial combines successful and failed targets. Periodically reconcile unfinished records in case a notification is missed.

3. Retry the operation that actually failed

• For creation returning 503 PUBLISH_DISPATCH_UNCERTAIN, resend the same body with the same idempotency key. Use details.publish_id to track that request. The idempotency cache lasts 24 hours; do not create a new post with a fresh key just because queue dispatch was uncertain.
• For explicit failed targets on a failed or partial publish, use POST /api/v1/publishes/{id}/retry. Successful targets and targets with unknown outcomes are not resent. Resolve the underlying error first.
• Webhook delivery has its own retries: up to six attempts with backoff. Accept duplicates safely and read the latest publish state before taking further action.

Before enabling unattended runs, validate credentials, future timestamps, response mapping, signatures, duplicate events, partial failures, and uncertain dispatch using isolated test accounts. A green HTTP node alone does not prove a post went live.