Content Composer Content Calendar Unified Social Inbox AI Smart Replies Creative Studio Social Media Analytics Automation Feed Reader Link-in-Bio Content Strategy Report Builder White Label See All Products →
For Marketing Teams For Agencies For Enterprises Integrations Compare Explore All Features →
Pricing
Blog Help Center Developers Case Studies Changelog
About
Language: en es fr de ar zh pt tr hi nl
Log In Sign Up

Changelog & versioning

What changed, and the promises we make about what will not.

The promise

What we may add without warning

Your integration must tolerate these. They are not breaking changes, and they can ship any day:

  • New endpoints, and new optional request fields.
  • New fields in a response object. Do not use strict schema validation that rejects unknown keys.
  • New values in an enum-like field — new post statuses, new platforms, new error codes. Handle the default case rather than exhaustively matching.
  • New webhook event types. Ignore events you did not ask for.

What we will not do inside v1

  • Remove or rename a field you already receive.
  • Change a field's type, or the meaning of an existing value.
  • Remove an endpoint, or add a required request field to one.
  • Change an error's code for the same condition. (The message wording may improve — which is why you branch on code, never on message.)

If something has to go

A breaking change means a new version, served alongside v1 — not a change to v1. If an endpoint is ever deprecated, its responses carry a Sunset header (RFC 8594) giving the date it stops working: 

Sunset: Sat, 01 Aug 2026 00:00:00 GMT
Link: <https://vm.viraldashboard.io/developers/changelog>; rel="sunset"

You get at least six months between a Sunset header appearing and the endpoint being switched off, and the deprecation is announced here on the day the header first ships. If you log one thing from our responses, log the presence of a Sunset header.

Releases

The reference is generated from the running API. The reference renders https://vm.viraldashboard.io/api/public/v1/openapi.json live, so it always describes the API you are actually calling — it cannot drift the way a hand-written page can.

v1 — launch

The first public release. /api/public/v1 covers the whole product surface:

  • Brands — list, read, create.
  • Social accounts — discover what a platform needs, connect with credentials, issue a one-time OAuth authorization URL, refresh, disconnect.
  • Posts — list, read, create (publish now, schedule, or draft), update, delete, submit for approval, poll status.
  • Media — multipart upload (validated by magic bytes), async import from a URL, poll the job.
  • Analytics — post and account metrics, clamped to your plan's retention window.
  • Link-in-Bio, content plans, RSS feeds — full CRUD, and scheduling a plan item into a real post.
  • Webhooks — endpoints, signed deliveries, secret rotation, delivery history and retry.
  • AI — captions, hashtags and images, metered in credits.
  • Reports — CRUD, async export to PDF/CSV/JSON/PPTX/XLSX, download, recurring schedules.

Everything is authenticated with a scoped Bearer key, authorized per brand, and every write requires an Idempotency-Key. Errors share one envelope. Rate limits are per key.