Versioning

The Marky API uses date-based versioning, inspired by Stripe. This means the API evolves without breaking your existing integrations.

How it works

Every request returns a Marky-Version header with the API version used:

Marky-Version: 2026-04-08

You can pin your integration to a specific version by sending the header:

curl https://api.mymarky.ai/api/workspaces \
  -H "Authorization: Bearer mk_live_your_key" \
  -H "Marky-Version: 2026-04-08"

If you don’t send the header, you get the latest version.

When we make changes

Non-breaking changes (new fields, new endpoints) are added without a version bump. Your existing code won’t break.
Breaking changes (removed fields, changed behavior) create a new version date. Your pinned version continues working until you’re ready to upgrade.

Deprecations

When we rename an endpoint or field, the old name keeps working. It is marked deprecated in the OpenAPI document behind the API Reference, its description says Deprecated: use <new name>, and the changelog announces it. Renames like this are additive, so they ship without a version bump, and a pinned Marky-Version gets the same response shapes from the old and new names. Move to the new name when convenient. Before any deprecated name stops working, it will be announced in the changelog with notice.

Renamed: businesses are now workspaces

October 31, 2026. What the dashboard calls a workspace, the API used to call a business. The top-level endpoints now use the workspace name:

Old (deprecated, still works)	New
`GET /api/businesses` (`list_businesses`)	`GET /api/workspaces` (`list_workspaces`)
`POST /api/businesses` (`create_business`)	`POST /api/workspaces` (`create_workspace`)
`GET /api/businesses/{business_id}` (`get_business`)	`GET /api/workspaces/{workspace_id}` (`get_workspace`)
`PATCH /api/businesses/{business_id}` (`update_business`)	`PATCH /api/workspaces/{workspace_id}` (`update_workspace`)
`DELETE /api/businesses/{business_id}` (`delete_business`)	`DELETE /api/workspaces/{workspace_id}` (`delete_workspace`)
`business_id` in the body of `POST /api/media/from-url`, `/api/media/from-reference`, `/api/media/uploads`	`workspace_id`

Request and response bodies are the same under both names. What did not change:

Paths under a workspace keep their shape, for example /api/businesses/{business_id}/posts. There business_id is the workspace ID.
Response bodies still carry the workspace ID as business_id.
Media uploads accept either workspace_id or business_id. Send one; if you send both they must match, or you get a 422.

The MCP server renamed its tools the same way; see MCP Server.

Current version

Version	Date	Notes
`2026-04-08`	April 8, 2026	Initial release

Best practices

Pin your version in production integrations to avoid surprises
Test against the latest version periodically to adopt improvements
Check the changelog for new features and deprecation notices

Getting Started

Integrations

How it works

When we make changes

Deprecations

Renamed: businesses are now workspaces

Current version

Best practices

​How it works

​When we make changes

​Deprecations

​Renamed: businesses are now workspaces

​Current version

​Best practices

How it works

When we make changes

Deprecations

Renamed: businesses are now workspaces

Current version

Best practices