This update is about the time around publishing: the post you are not ready to send yet, the moment you need to know a scheduled post went out (or did not), and the afternoon you spend working out why an integration returned a 400. Three features land in the dashboard to help with each.
Drafts
The Playground now has Save draft. A draft keeps everything you have set up: the selected accounts, shared text, per-account text, media and platform options, and the schedule.
Saved drafts appear on the new Drafts page, with a title taken from the post text, the platforms it targets and when it was last edited. Open one to continue in the Playground exactly where you left off.
A few details we cared about:
- Drafts do not have to be valid. You can save a half-written post with no accounts selected. Full validation runs when you publish, the same as any other post.
- Publishing a draft removes it from the Drafts list, so the list only holds work in progress.
- No accidental losses. If you try to leave the Playground with unsaved changes, you are offered the choice to save them as a draft first.
- Drafts are shared with your project. Everyone on the team can see and pick up a draft.
Two related shortcuts round this out. From the Posts page, Open in playground loads any existing post's original request so you can reuse it as the starting point for a new one. And the Playground can import a POST /v1/posts request body as JSON, which is handy when a developer wants to hand a request over to someone who prefers the visual editor. Accounts in the JSON that are not connected to your project are skipped, and you are told how many.
Drafts cost nothing. Credits are only used when a post is actually created.
Notifications
Under Settings → Notifications you can now create rules that tell you when something happens to a post. Each rule has:
- A channel: email (up to 20 recipients) or a webhook URL.
- Events: any of
post.scheduled,post.published,post.partialandpost.failed. - A scope: all accounts, or only posts that include specific accounts.
- Only scheduled posts: an option to skip posts that were published immediately, so you only hear about the ones that went out while you were not watching.
Emails summarise the post and list the result for every platform, with a link to each live post or the error that stopped it.
Webhooks receive a JSON body with the same information, and every delivery is signed. The x-signature header is an HMAC-SHA256 of the timestamp and body using a secret generated when you create the rule, and x-webhook-timestamp and x-webhook-id let you reject stale requests and de-duplicate retries. We wrote a step-by-step guide to verifying signatures.
Failed deliveries are retried with exponential backoff, and Send test sends a sample notification through the rule before you save it, so you can confirm your endpoint or inbox is set up correctly.
Webhook URLs must use https:// and resolve to a public address. This is checked when you save the rule and again before each delivery.
A good starting setup for most teams:
| Rule | Channel | Events |
|---|---|---|
| "Tell me when something breaks" | Email to the social team | post.partial, post.failed |
| "Sync results to our system" | Webhook | post.published, post.partial, post.failed |
The full payload format is in the notifications docs.
Request logs
The new Logs page lists every API request made with your project's keys: method, path, operation, the platform involved (when there is one), status code, duration, which API key was used, and when it happened. Failed requests include the error message.
You can filter by:
- Type: Posts, Accounts, Integrations, Media, Usage or Other
- Status: 2xx, 4xx or 5xx
- Platform
- Time: the last hour, 24 hours, 7 days or 30 days
and search by path, operation or method.
The most common use is the obvious one: an integration starts getting errors, and instead of adding logging to your own code, you filter the Logs page to 4xx and read the error messages. Rate-limited requests (429) are logged too, which makes it easy to see when a burst of traffic is hitting your limit.
Every API response includes an X-Request-Id header. Log it on your side, and you can match a specific call in your system to its entry in Relaycast.
Logs store request metadata only, not request or response bodies, and are kept for 30 days. Post content and results are on the Posts page instead, which shows each post's per-platform results and its original request.
Getting the new features
All three are available now in every project. Open the dashboard to try them, and read more in the docs:
Ready to build?
Get an access key and publish your first post in minutes.