Skip to content

Join the Seedly owners community →

Help Center

API Changelog

Notable changes to the Seedly CRM REST API.

Last updated

All notable changes to the Seedly CRM REST API.


2026-08 - Campaigns API, task cancellation, and repaired scopes#

Added#

  • Create, send, and schedule email campaigns via API. You can now push a finished HTML email into the CRM and send it (or schedule it) without opening the builder. The campaign sends through the same provider setup, unsubscribe treatment, suppression checks, and audience selection a UI-built campaign uses. A campaign created this way opens in the app as read-only, so the block canvas is not offered - the HTML is yours and reopening it in the block editor would rewrite it.
  • Cancelled task state. PATCH /api/v1/tasks/{id} accepts status: "cancelled". Deleting a contact cancels its open tasks rather than marking them completed, so task.updated webhooks fire with the cancelled status. Task-created and task-completed webhook events keep their existing shapes; there is no separate task.cancelled event.
  • Sign-in behind a proxy no longer 404s. Deployments that terminate TLS on Cloudflare, Railway, or a custom platform domain used to fail sign-in on the first request after a redeploy. The auth path now trusts X-Forwarded-Host, so sign-in works on any proxied hostname.

Fixed#

  • Scheduled sends reject impossible times. A timestamp in seconds (not milliseconds) used to be accepted and read as a date in 1970, which the CRM treated as overdue and sent immediately while reporting back that it was scheduled. Times more than a year in the past or ahead are now rejected with an error.
  • The task spec matches what the CRM stores. Fields that the CRM never stored have been removed from the public spec. If you were persisting them client-side because the docs promised them, drop those columns.
  • campaigns:write is selectable on new API keys and gates the campaign create, send, and schedule endpoints above. There is deliberately no campaigns:read scope - the campaigns REST surface has no GET endpoint today, so a grantable scope that authorises nothing would be a promise the API cannot keep. When a GET lands, campaigns:read will land in the same change.

Deprecated#

  • Nothing this release. The 15-event webhook set plus the 11 events added in the prior release remain the current catalog.

Opportunities, Tasks, and Pipelines are documented#

Documentation#

These endpoints shipped earlier and have been live in the product and in the bundled OpenAPI spec, but this reference only described contacts, conversations, and calendars. That was a documentation gap, not a missing feature. The reference now covers them properly.

Opportunities (opportunities:read, opportunities:write)

  • GET /api/v1/opportunities - list opportunities
  • GET /api/v1/opportunities/{id} - get an opportunity
  • POST /api/v1/opportunities - create an opportunity
  • PATCH /api/v1/opportunities/{id} - update an opportunity
  • PUT /api/v1/opportunities/{id}/stage - move to a different stage
  • PUT /api/v1/opportunities/{id}/status - set status
  • DELETE /api/v1/opportunities/{id} - soft-delete an opportunity

Tasks (tasks:read, tasks:write)

  • GET /api/v1/tasks - list tasks, filter by status, assignedTo, contactId, dealId, dueBefore, dueAfter
  • GET /api/v1/tasks/{id} - get a task
  • POST /api/v1/tasks - create a task
  • PATCH /api/v1/tasks/{id} - update a task
  • PUT /api/v1/tasks/{id}/complete - mark a task completed
  • DELETE /api/v1/tasks/{id} - delete a task

Pipelines (opportunities:read)

  • GET /api/v1/pipelines - list pipelines and their ordered stages

The scope table in the REST API reference has been corrected to list these. Two further scopes exist but grant no access to /api/v1/* and are intentionally left out. Record timestamps (createdAt, updatedAt) are ISO 8601 here as everywhere else; the scheduling fields (dueDate, completedAt, expectedCloseDate, closedAt) are epoch milliseconds. The reference now states which is which.

Still not exposed#

  • Invoices. The invoice.paid webhook event exists, but there are no invoice REST endpoints.

Replay-protected webhook signature, and two response fixes#

Added#

  • X-Webhook-Signature-V2 on every outbound webhook delivery. It signs <timestamp>.<body> with your existing per-subscription secret, so a receiver can trust X-Webhook-Timestamp and reject a replayed delivery outside a freshness window. This is additive: X-Webhook-Signature is still sent, unchanged, and integrations that verify it keep working. See Webhook Payloads for the verification snippet.

Fixed#

  • By-id and sub-resource routes resolve. Routes addressing a single record or a nested resource under it were not being matched and returned a not-found response. They now behave as documented. If you worked around this by listing and filtering client-side, you can go back to addressing the record directly.
  • meta.total is the size of the full result set, not the number of records in the current page. If you were treating total as a page count, or computing a total by summing it across pages, correct that when you upgrade.

Expanded Webhook Events#

Added#

The outbound webhook catalog has grown from the original 15 events to 26. The following events are now available to subscribe to, in addition to the launch set:

  • opportunity.updated, opportunity.deleted
  • appointment.cancelled, appointment.rescheduled, appointment.confirmed, appointment.completed, appointment.no_show
  • task.created, task.updated, task.completed, task.deleted

Existing subscriptions are unaffected. See the REST API and Webhook Payloads pages for the full list and payload shapes.


2026-03-27 - Agency-Scoped API Keys#

Added#

  • Agency-scoped API keys - Create a single API key that operates across all sub-accounts under an agency. Prefix: sk_agency_live_ (production) and sk_agency_test_ (sandbox). Requires X-Sub-Account-Id header on every request.
  • GET /api/v1/sub-accounts - Discovery endpoint to list available sub-accounts. Only accessible with agency-scoped keys.
  • New error codes: MISSING_SUB_ACCOUNT (400), INVALID_SUB_ACCOUNT (403)

2026-03-27 - v1 Launch#

Initial release of the public REST API.

Added#

Authentication:

  • API key authentication with sk_live_ (production) and sk_test_ (sandbox) prefixes
  • Scoped permissions: contacts:read, contacts:write, conversations:read, conversations:write, calendars:read, calendars:write, webhooks:manage
  • Test mode keys - messages recorded but not sent to providers

Contacts:

  • GET /api/v1/contacts - list/search contacts, exact email lookup via email param
  • GET /api/v1/contacts/{id} - get contact
  • POST /api/v1/contacts - create contact
  • PATCH /api/v1/contacts/{id} - update contact
  • DELETE /api/v1/contacts/{id} - soft-delete contact
  • GET /api/v1/contacts/fields - list custom field definitions

Conversations:

  • GET /api/v1/conversations - list conversations, filter by contactId
  • GET /api/v1/conversations/{id} - get conversation
  • POST /api/v1/conversations - create or find existing conversation
  • GET /api/v1/conversations/{id}/messages - list messages (cursor-based pagination)
  • POST /api/v1/conversations/{id}/messages - send message (all channels)
  • PATCH /api/v1/conversations/{id} - update status/assignment

Calendars:

  • GET /api/v1/calendars - list active calendars
  • GET /api/v1/calendars/types - list appointment types
  • GET /api/v1/calendars/availability - check available slots
  • GET /api/v1/calendars/appointments - list appointments
  • POST /api/v1/calendars/appointments - book appointment
  • DELETE /api/v1/calendars/appointments/{id} - cancel appointment

Webhooks:

  • GET /api/v1/webhooks - list subscriptions
  • POST /api/v1/webhooks - create subscription
  • PATCH /api/v1/webhooks/{id} - update subscription
  • DELETE /api/v1/webhooks/{id} - delete subscription
  • POST /api/v1/webhooks/{id}/regenerate-secret - regenerate signing secret
  • 15 webhook events: contact.created, contact.updated, contact.lifecycle_changed, contact.tag_added, opportunity.created, opportunity.stage_changed, opportunity.won, opportunity.lost, message.received, message.sent, message.delivered, message.failed, appointment.booked, form.submitted, invoice.paid

General:

  • Per-key rate limiting with separate limits for read and write operations
  • ISO 8601 timestamps in all responses
  • Usage logging per API key
  • Automated cleanup of expired keys and old usage logs
Was this page helpful?