Reference · Changelog

API versions · platform releases

Changelog

PrintedSimply uses date-based API versioning. Pin your integration to a specific version by sending the X-API-Version header with your requests. Below the versions is the platform's release history — the dashboard, the docs and the tools, release by release.

What shipped this week

The newest 50 as a feed: RSS · JSON Feed

22 changes in the last 7 days, the newest on Thu, Oct 22 · show

Thu, Oct 22

~The webhook delivery log lists by when each event happened (DX-31)

Wed, Oct 21

Mon, Oct 19

Sun, Oct 18

Machine-readable spec

The full OpenAPI 3.1 document is published at /api/openapi.json. It carries the current version in info.version (2026-07-26) and the full supported-version list — statuses and sunset dates included — in x-api-versions, so a client can check its own pin without reading this page.

How versioning works

Each API version is identified by its release date (e.g. 2026-03-14)
If you do not send an X-API-Version header, the latest version is used
Non-breaking changes (new fields, new endpoints) are added without a version bump
Breaking changes are released under a new version date with at least 30 days notice
Deprecated versions are supported for a minimum of 12 months

Check the version you were served

Every response — successes, errors, and idempotent replays alike — carries the version it was actually served under, in MF-Version and, under the same name as the request header, X-API-Version. The two always carry the same value.

Compare it against the version you pinned. A pin is not always honoured, and neither case is an error response:

A version id we don't recognise resolves down to the nearest older supported version.
A version id older than 2026-02-15 (the published minimum) resolves up to the current version.

So a typo in a pin gets you a contract you did not ask for, quietly, with a 200. The echo is the only place that shows up. Both SDKs record it after every call — client.lastApiVersion in TypeScript, client.last_api_version in Python — including on calls that raised.

Deprecation headers

When you use a deprecated API version, responses include these headers:

Deprecation: @<unix seconds> — this version is deprecated, and since when (RFC 9745)
Sunset: <date> — when this version will stop working
Link: <url>; rel="deprecation" — migration guide

2026-07-26Current

Changed (12 of 69) · show

~2026-10-15GET /v1/me's spend_controls.spent_today_cents is documented as nullable (DX-42). It is null when the key has no daily cap, or when the day's tally could not be read, as it always was; the document and both SDKs said it was always a number.
~2026-10-15On the PrintedSimply portal, GET /v1/setup lists only what the portal offers (DX-42). It listed two optional steps for ways of selling the portal does not offer, each sending an account to a page or an operation the portal refuses, and the first real order's hint ended by pointing to one of them. The portal's answer now leaves them out, and its document's step key lists the six steps it reports. On the full product nothing changed.
~2026-10-15Unknown paths and methods answer in the envelope (DX-40). A v1 path no operation is at got the site's HTML 404 page, and a method a path does not take got a bare 405 with no body; neither carried a request id. Both are now JSON with X-Request-Id and the MF-Version echo: 404 not_found, whose message names the path, and 405 method_not_allowed (a new code) with Allow naming the methods the path takes and details.allow the same list. A method no path takes at all (PROPFIND, PURGE: anything but GET, HEAD, OPTIONS, POST, PUT, PATCH and DELETE) got an empty 400; it is now 501 method_not_implemented (also new), with Allow where the path exists. A family this portal does not offer still answers not_available first, and TRACE and CONNECT are refused by the web server before the API sees them. On the API host and under the app's /api/v1 alike, and as problem details when Accept asks for them. HEAD on a path that takes GET, and OPTIONS wherever an operation is, answer as before, and an operation family a deployment does not offer keeps its 404 not_available, which now carries the version echo as well; on PrintedSimply, a path under a family no operation has (a typo such as ordr for order) is now the 404 not_found rather than not_available.
~2026-10-15API responses set no cookies (DX-40). A response under /api/v1 on the app's own host carried the sign-in library's authjs.csrf-token and authjs.callback-url cookies, because the session reader ran in front of every request there. The v1 API authenticates by key and reads no session, so the reader no longer runs for it, and no v1 response — a success, an error, a 404 or a 405 — carries Set-Cookie. The API host never set them.
~2026-10-15destination_unavailable names a remedy the deployment serves (DX-40). Its message named a remedy for each cause, and on PrintedSimply none of the six was one a caller could take there: three sent it to an operation PrintedSimply does not serve, and the other three named a lane it does not have. There, every cause now says to send a US address, as the suggestion already did; the full product's messages are unchanged.
~2026-10-15Webhooks go out in seconds, not at the next minute (DX-39). Every event is delivered from a durable queue that a dispatcher drained in one pass each minute, so an event raised just after a pass waited for the next one, up to a minute. Each minute's dispatch now keeps passing over the queue every 2 seconds for about 40 seconds after it starts: an event raised in that window is attempted on the next pass, about 2 seconds later, and one raised in the rest of the minute on the next minute's first pass. The retry ladder is unchanged (a failed delivery is tried again after 1 minute, 5 minutes, 15 minutes, 1 hour, 3 hours, then 6 hours, up to 7 attempts), and an attempt is still made once however many passes run: a delivery's last attempt now holds its event while it is in flight, so a later pass cannot send it a second time. An endpoint whose deliveries in a pass mostly fail (a 429, a 5xx, a timeout) is not sent more until the next minute's first pass, so a backlog for an endpoint asking to slow down goes out at the pace it did before, a page a minute, not in a burst. Payloads, signatures and the delivery log are unchanged.
~2026-10-15On the PrintedSimply portal, product.updated and catalog.synced are about the products it sells (DX-39). Both were already sent there only for our own plant's catalog; a product.updated now also leaves out a SKU in that catalog which the portal does not list (one the router also sends to another facility, or a row GET /v1/products hides as an internal, QA or $0 placeholder product), and catalog.synced's product_count and changed_count count the products GET /v1/products lists and the changes among them. On the full product nothing changed.
~2026-10-15On the PrintedSimply portal, order.rerouted is not offered to a new subscription (DX-39). An order there is made at our own plant and never re-routed to another facility (a stranded order is left for a person to resolve rather than moved), so the event is never raised, yet the subscribe dialog, the webhooks docs, the events page, llms-full.txt and POST/PATCH /v1/webhooks all offered it. A request whose events names order.rerouted is now refused with 400 event_not_available, as an event from a family the portal does not offer is; a subscription that already names it keeps it, and an update that sends its own list back still works. On the full product nothing changed.
~2026-10-15POST /v1/orders/multi-ship counts as one request (DX-38). It places its shipments through the same path POST /v1/orders/bulk uses, and that second pass was counted as a request of its own: each call spent two units of your per-minute window and of your daily quota, so a client reached 429 at half its plan's rate, and it was written to the request log, counted in your usage and billed twice. It now counts once, as the call you made, in every window, in your usage and in the log; the batch it places still checks your key, its scopes and its Idempotency-Key. The response is unchanged.
~2026-10-15Deprecation is an RFC 9745 date (DX-38). A response served under a deprecated version carried Deprecation: true, the value of the drafts before RFC 9745. It now carries @ and the Unix time the version was deprecated — Deprecation: @1774137600 for 2026-02-15, deprecated on 2026-03-22 — the Structured Fields Date a client written to the RFC parses. Sunset and Link are unchanged.
~2026-10-15Live address and shipping amendments answer the published shape (DX-37). PUT /v1/order/{id}/address and PUT /v1/order/{id}/shipping answered a sandbox order with order_id, portal_order_id and the change, and a live one with the facility's raw reply, so a client built against a test key read nothing live. A live answer is still the facility's reply, every key it sends kept as it sent it, now with order_id and portal_order_id (and on an address change ship_to, the address the order now ships to) filled from our record wherever the reply has none. The status and the money are never filled: on a live order they are the facility's own words and figures (GET /v1/order/{id} has ours). One schema per amendment covers both modes, AddressAmendment and ShippingAmendment; SandboxAddressAmendment and SandboxShippingAmendment stay as other names for them, in the document and in both SDKs. Additive: no key a live reply carried changed.
~2026-10-15A test key's $0 is for a real SKU only (DX-37). While pricing is unavailable on a test key — the items' facility is not configured, or our plant gave no answer — POST /v1/orders/quote, POST /v1/pricing/estimate, POST /v1/order and POST /v1/{id}/item (on a test order) answered a $0 marked pricing_degraded for any string, so sticker-nope became a sandbox order and an integration passed its tests with a SKU the first live order refuses. Now a SKU must be one the price book prices (every size of the families it prices), one of our plant's named products, or one in the synced catalog; any other is 400 unknown_sku with details.skus, from all four, before anything is recorded, and a POST /v1/orders/bulk row fails alone with an error starting unknown_sku:. And when our plant answers that it does not carry a SKU, a test key's order, added line and bulk row now get the 400 pricing_error its quote and estimate already gave (a bulk row's error starts pricing_error:), where they were recorded at $0. Live keys are unchanged. GET /v1/products/{sku} agrees: while our plant does not answer it serves the price book's row, stale and orderable: false, for another size of a product the book lists (STICKER-DIE-CUT-2X2 beside the listed 3×3), where it answered 502. unknown_sku is now listed with the pricing codes on /docs/errors, and its suggestion is no longer about drops.

Deprecated (2) · show

!2026-10-15page (and offset) on GET /v1/orders, GET /v1/order/{id}/events, GET /v1/assets and GET /v1/products (DX-43). Still accepted and answered as before, each with its own earlier page size, now with meta.has_more and meta.next_cursor; cursor wins when both are sent. Walk with cursor instead; the MCP tools no longer offer page.
!2026-09-26pricing_model.processing_fee_pct on GET /v1/pricing/tiers. The single fee it described is now two lines; it holds the platform fee rate so a parser that requires it still parses. Read platform_fee_pct, card_fee_pct and card_fee_fixed_cents instead

2026-03-14Stable

Added (7) · show

+2026-07-18Signed, expiring order quotes — POST /v1/orders/quote
+2026-07-18$0 sandbox — time-compressed order lifecycle with real signed webhooks
+2026-07-18Webhook delivery replay
+2026-03-22Artwork validation, design lint, and mockup generation
+2026-03-22Template rendering API
+2026-03-22Product recommendations
+2026-03-22Multi-address shipping and bulk orders

Changed (1) · show

~2026-03-22Order response now includes estimated_delivery field

2026-03-01Stable

Added (3) · show

+2026-03-22Shipping estimation endpoint
+2026-03-22Volume pricing tiers
+2026-03-22Product search and filtering

Changed (1) · show

~2026-03-22Rate limit increased from 30 to 60 req/min

Deprecated (1) · show

!2026-03-22Legacy product IDs (use product_type instead)

2026-02-15Deprecated

Added (3) · show

+2026-03-22Webhook signature verification
+2026-03-22Idempotency key support
+2026-03-22Order events endpoint

Changed (1) · show

~2026-03-22Error response format standardized to include request_id

Platform releases

A dated log of what shipped on the dashboard, the docs and the tools, newest first. An entry records what was true when it shipped; a later entry corrects it rather than an edit. The newest 50 releases are a feed: RSS or JSON Feed; the API's own changes, above, are another: RSS or JSON Feed.

v43.1.0New FeatureAugust 3, 2026

Replay-resistant webhook signatures and event ids

•New X-MF-Signature-V2 header (t=<unix>,v1=<hex>) signs the timestamp together with the raw body, so you can reject a captured request replayed later — the body-only signature it replaces stayed valid forever
•New X-MF-Event-Id header, mirrored as id in the payload — stable across our retry attempts and any manual redelivery, so you can dedupe instead of processing a retry twice
•New X-MF-Timestamp header exposing the signed timestamp directly
•X-MF-Signature (sha256=<hex> over the raw body) is unchanged and still sent on every request — existing verifiers keep working, no migration required
•TypeScript SDK: client.webhooks.verify() now accepts either header and enforces a 5-minute replay window by default (override with { toleranceSeconds })

v42.0.0ReleaseMarch 22, 2026

Phase 42 — Stripe Billing Portal & Plan Management

•Stripe Customer Portal — self-service billing management (invoices, payment methods, billing history) via hosted Stripe portal
•Usage summary — billing page now shows current plan, monthly order count, and month-to-date spend
•Billing portal API — POST /api/portal/billing/portal creates Stripe Customer Portal session
•Pricing page update — plan tiers now show monthly pricing alongside rate limits and discounts

v41.0.0ReleaseMarch 22, 2026

Phase 41 — Audit & Polish

•Error boundaries — added error.tsx to 9 dashboard pages (api-keys, assets, audit-log, billing, notifications, orders, settings, team, webhooks)
•Loading states — added skeleton loading.tsx to notifications page
•Page metadata — added title/description to webhook logs, webhook testing, and order detail pages
•Brand cleanup — replaced all legacy PS_ variable names with MF_ in WooCommerce integration code examples and blog posts
•Code example cleanup — renamed ps → mf variable names across all blog post code snippets

v40.0.0ReleaseMarch 22, 2026

Phase 40 — API Versioning & Deprecation

•Date-based API versioning — send X-API-Version header to pin your integration to a specific API version (Stripe-style)
•Version negotiation — middleware resolves requested version, falls back to nearest older version for unknown dates
•Deprecation headers — deprecated versions return Deprecation, Sunset, and Link headers per RFC 8594
•API version config — centralized version registry with status (current/stable/deprecated) and sunset dates
•Version context — apiVersion now available in withApiAuth handler context for version-specific behavior
•Docs update — API changelog page now documents deprecation header format

v39.0.0ReleaseMarch 22, 2026

Phase 39 — Admin Dashboard Enhancement

•System health page — /admin/health shows database, Redis, and fulfillment provider status with response times and uptime
•API usage analytics — /admin/usage with 24h/7d request counts, error rate, avg latency, top endpoints, top API keys, and errors by status code
•Orders pagination — 30 per page with status filter preserved across pages
•Admin sidebar — added API Usage and System Health nav items, fixed its branding

Breaking changes are always announced at least 30 days in advance.
Questions? Read the API docs or contact us at developers@printedsimply.com.

Platform releases

v43.1.0New FeatureAugust 3, 2026

Replay-resistant webhook signatures and event ids

•New X-MF-Signature-V2 header (t=<unix>,v1=<hex>) signs the timestamp together with the raw body, so you can reject a captured request replayed later — the body-only signature it replaces stayed valid forever
•New X-MF-Event-Id header, mirrored as id in the payload — stable across our retry attempts and any manual redelivery, so you can dedupe instead of processing a retry twice
•New X-MF-Timestamp header exposing the signed timestamp directly
•X-MF-Signature (sha256=<hex> over the raw body) is unchanged and still sent on every request — existing verifiers keep working, no migration required
•TypeScript SDK: client.webhooks.verify() now accepts either header and enforces a 5-minute replay window by default (override with { toleranceSeconds })

v42.0.0ReleaseMarch 22, 2026

Phase 42 — Stripe Billing Portal & Plan Management

•Stripe Customer Portal — self-service billing management (invoices, payment methods, billing history) via hosted Stripe portal
•Usage summary — billing page now shows current plan, monthly order count, and month-to-date spend
•Billing portal API — POST /api/portal/billing/portal creates Stripe Customer Portal session
•Pricing page update — plan tiers now show monthly pricing alongside rate limits and discounts

v41.0.0ReleaseMarch 22, 2026

Phase 41 — Audit & Polish

•Error boundaries — added error.tsx to 9 dashboard pages (api-keys, assets, audit-log, billing, notifications, orders, settings, team, webhooks)
•Loading states — added skeleton loading.tsx to notifications page
•Page metadata — added title/description to webhook logs, webhook testing, and order detail pages
•Brand cleanup — replaced all legacy PS_ variable names with MF_ in WooCommerce integration code examples and blog posts
•Code example cleanup — renamed ps → mf variable names across all blog post code snippets

v40.0.0ReleaseMarch 22, 2026

Phase 40 — API Versioning & Deprecation

•Date-based API versioning — send X-API-Version header to pin your integration to a specific API version (Stripe-style)
•Version negotiation — middleware resolves requested version, falls back to nearest older version for unknown dates
•Deprecation headers — deprecated versions return Deprecation, Sunset, and Link headers per RFC 8594
•API version config — centralized version registry with status (current/stable/deprecated) and sunset dates
•Version context — apiVersion now available in withApiAuth handler context for version-specific behavior
•Docs update — API changelog page now documents deprecation header format

v39.0.0ReleaseMarch 22, 2026

Phase 39 — Admin Dashboard Enhancement

•System health page — /admin/health shows database, Redis, and fulfillment provider status with response times and uptime
•API usage analytics — /admin/usage with 24h/7d request counts, error rate, avg latency, top endpoints, top API keys, and errors by status code
•Orders pagination — 30 per page with status filter preserved across pages
•Admin sidebar — added API Usage and System Health nav items, fixed its branding