Skip to main content
The Spotzee API uses date-based versions. Pin a version with the Spotzee-Version request header. See API versioning for the full pinning model.
New features

Template email headers

Email templates support optional data.customHeaders rows with name and value fields. Add per-contact values in email advanced settings across all editor types. Campaigns, journeys and proofs use the template’s values, and preview and proof requests preserve supplied journey variables.Both the campaign wizard and template details form show compact header rows with names inside empty fields and a minus button in the third column. Failed saves keep your form open so you can correct validation errors. WYSIWYG saves preserve header rows, including literal empty values, and accept supported generated list styles.Template names override matching provider headers without regard to case. An empty or whitespace-only rendered value suppresses the matching provider header; removing the template row restores the provider default. Reserved names and duplicate names prevent saving. Unsafe rendered control characters stop the send before provider submission.Existing templates need no migration. See Custom email headers for configuration, variables and validation rules, or Set up email delivery for provider configuration.
Improvements

Improvements

Extended API consolidated onto apix.spotzee.com

Both the Main API and Extended API now serve from the same hostname. Update your client configuration:This is a hard cutover with no overlap. Update your integrations.

Extended API conventions aligned with Main API

The Extended API adopts the following API conventions:Spotzee-Version header: required to be either 2026-04-28 or omitted (server defaults to current). Echoed on every response.X-Request-Id header: req_<id> on every response. Globally unique per request. Quote it in support tickets.application/problem+json: error responses now use the RFC 7807 media type.OpenAPI 3.1: the published spec is now OpenAPI 3.1.0 (was 3.0.0).Canonical error envelope: {status, code, title, message, error, type, request_id} shares field names with the Main API. Follow the Extended API errors reference for field types and optional fields. The legacy error field is kept as the canonical envelope’s optional mirror until a future major version.
New featuresImprovements

Typed JavaScript SDK

These don’t change the API surface but are worth knowing about if you’re building against the spec.The @spotzee/js-sdk package now ships a fully typed client generated from the live OpenAPI 3.1 spec at the /generated subpath. Every operation is exposed as a typed function with inputs, outputs, and the full RFC 7807 error envelope. The hand-written Client / BrowserClient / Spotzee classes for browser tracking are unchanged. The typed surface is purely additive.
Install:

Improvements

Common API types

The generated references document common types such as ErrorResponse, PaginationQuery, Channel, and prefixed identifiers. Follow each endpoint’s contract: sharing a type name does not imply that every endpoint accepts the same pagination parameters.
New features

Public API

The first publicly-versioned release of the Spotzee API.

API keys

Project-scoped surface at https://apix.spotzee.com/api/client with sk_ (secret) and pk_ (publishable) keys.Organisation-scoped surface at https://apix.spotzee.com/api/admin with ok_ keys for cross-project administration.

API conventions

Versioning: Spotzee-Version request header (date-based). Echoed back on every response.Idempotency contract: Idempotency-Key on POST and PATCH, with a 24-hour cache scoped per API key where enforcement is enabled. See Idempotency for rollout availability and limits.Rate-limit contract: per-key read and write budgets are separate from the deployed per-IP limits. See Rate limits before relying on a per-key budget or client-type multiplier.Errors: the documented RFC 7807 application/problem+json contract has stable string code, title, message, request_id, optional param and errors[] for per-field validation breakdowns. Handle application/json responses and omitted optional fields during rollout; see Main API errors.Correlation: every response carries an X-Request-Id header (req_<ULID>). Quote it in support tickets.

Endpoints

Public surface for the first time:Contacts: the API’s /users resource supports list, get, batch upsert up to 100 contacts, and delete. A one-contact upsert still uses an array.Lists: full CRUD. Static and dynamic flavours; dynamic lists are how you express segments via the API.Subscriptions: opt-in management per channel.Templates: multi-channel template management with preview and proof endpoints.Campaigns: full CRUD plus duplicate, preview, and trigger.Journeys: full CRUD plus manual trigger. See Trigger a journey for status and admission considerations.Tags: full CRUD.Events: single + batch ingestion (up to 100 events per call), publishable-key-allowlisted for browser use.Project API keys: manage your own sk_ and pk_ keys.Organisation API keys: manage ok_ keys through an organisation owner’s signed-in session.Webhook endpoints: manage outgoing webhook subscriptions and signing secrets.

Migration notes

This is the first dated release, so there’s nothing to migrate from.

API examples

Endpoint pages offer generated code samples in curl, JavaScript, Python, and Go. Subscribe to the changelog page in your reader of choice for future releases.