Changes and deprecations

What v1 and v2 mean

v1 and v2 are part of each operation’s path. They aren’t two versions of the whole API, and both are current. The v2 operations cover sales orders, quotes, their lines, jobs, shipments, invoices and payments. The v1 operations cover customers, products, settings, webhooks, exports and reports. One key calls both. See Base URL and versions.

There’s no version header and nothing to pin. An operation changes in place, at its own path.

What to expect

• Additions come without notice. YoPrint adds operations, fields in answers, optional fields in requests and error codes as it builds features. Write your code to ignore fields and codes it doesn’t know.
• Replacements are marked first. When a newer operation or field replaces an older one, the reference marks the old one Legacy or deprecated and names the new one. Deprecated operations also say so in every answer (see below).
• Nothing deprecated has a removal date yet. Each deprecated operation and field keeps working for now. When one gets a date, it’s added on this page.

How a deprecated operation tells you

Every answer from a deprecated operation carries two headers:

Deprecation: @1794009600
X-YoPrint-Successor: POST /v2/api/store/{team_slug}/v2/invoice/filter

• Deprecation is when the operation was deprecated, in seconds since 1970 (RFC 9745). @1794009600 is November 7, 2026.
• X-YoPrint-Successor is the method and path of the operation to use instead.

There’s no Sunset header yet. To find the calls you still need to move, log any answer that has a Deprecation header, with its successor.

The deprecated operations

These 18 operations send the headers. Some of them no longer work at all, as their reference pages say. Move each one to its successor.

Invoices

• GET List invoices (v1) /v1/api/store/{team_slug}/invoice, use POST Filter invoices /v2/api/store/{team_slug}/v2/invoice/filter
• GET Get an invoice (v1) /v1/api/store/{team_slug}/invoice/{hash_id}, use GET Get an invoice /v2/api/store/{team_slug}/v2/invoice/{unique_key}
• PUT Change an invoice number (v1) /v1/api/store/{team_slug}/invoice/{hash_id} and PATCH Change an invoice number (v1) (same as PUT) /v1/api/store/{team_slug}/invoice/{hash_id}, use PUT Update an invoice /v2/api/store/{team_slug}/v2/invoice/{unique_key}

Sales orders and quotes

• POST Filter sales orders (retired v1) /v1/api/store/{team_slug}/sales_order/filter, use POST List sales orders /v2/api/store/{team_slug}/v2/sales_order/filter
• POST Filter quotes (retired v1) /v1/api/store/{team_slug}/quote/filter, use POST List quotes /v2/api/store/{team_slug}/v2/quote/filter
• GET Get an order's history (retired v1) /v1/api/store/{team_slug}/sales_order/{hash_id}/history, use GET List the history of a sales order or quote /v2/api/store/{team_slug}/v2/sales_order/{order_unique_key}/history
• GET List the messages of an order (v1) /v1/api/store/{team_slug}/sales_order/{hash_id}/message, use GET List the messages of an order /v2/api/store/{team_slug}/v2/sales_order/{hash_id}/message
• POST Send a message to the customer (v1) /v1/api/store/{team_slug}/sales_order/{hash_id}/message, use POST Send a message to the customer /v2/api/store/{team_slug}/v2/sales_order/{hash_id}/message

Jobs and shipments

• GET Get a job (retired) /v1/api/store/{team_slug}/job/{hash_id}, use GET Get one job of an order /v2/api/store/{team_slug}/v2/sales_order/{hash_id}/job/{job_id}
• PUT Change a job's status (retired) /v1/api/store/{team_slug}/job/{hash_id}/status, use PUT Change a job's status /v2/api/store/{team_slug}/v2/job/{hash_id}/status
• PATCH Delete all shipments of an order (retired) /v2/api/store/{team_slug}/v2/sales_order/{hash_id}/shipment/delete_all, use DELETE Delete a shipment /v2/api/store/{team_slug}/v2/shipment/{unique_key} for each shipment

Card payments

• PUT Refund a card payment (v1) /v1/api/store/{team_slug}/sales_order/{hash_id}/payment_gateway_refund/{id}, use PUT Refund a card payment through the gateway /v2/api/store/{team_slug}/v2/sales_order/{hash_id}/payment_gateway_refund/{id}
• POST Check a pending card payment (v1, not usable) /v1/api/store/{team_slug}/sales_order/poll_pending_payment, use GET List the payments of a sales order /v2/api/store/{team_slug}/v2/sales_order/{hash_id}/payment
• POST Prepare a card payment (v1) /v1/api/store/{team_slug}/sales_order/{hash_id}/payment/{payment_gateway}/pre_execute, POST Charge a card through the gateway (v1) /v1/api/store/{team_slug}/sales_order/{hash_id}/payment/{payment_gateway}, POST Start a Square Terminal checkout (v1) /v1/api/store/{team_slug}/sales_order/{hash_id}/square_terminal/create and PATCH Cancel a Square Terminal checkout (v1) /v1/api/store/{team_slug}/sales_order/{hash_id}/square_terminal/{checkout_id}/cancel: their v2 successors are internal, built for YoPrint’s own payment screens. See Cards and the API.

Deprecated fields

Some answers still carry an older copy of a newer field, such as an order’s calc_total. The reference marks each one deprecated. See Deprecated fields for each field and the one to read instead.

Changes

November 2026

Your team's plan now matters

The API, webhooks and Zapier need a plan with API access: Pro or higher, with an active subscription or trial. Other teams get 403 api_access_not_in_plan on every request, and no webhook deliveries. See Authentication.

• This site. The API reference, guides and concepts are public at developer.yoprint.com, with a Markdown copy of every page and the OpenAPI file.
• Bearer keys. Send your key as Authorization: Bearer YOUR_API_KEY. The older ways (the key alone in Authorization, or user_api_key in the query string or body) keep working. See Authentication.
• Plan check. Requests for a team without API access answer 403 api_access_not_in_plan, and its webhooks stop delivering until the team is back on a plan with it.
• Deprecation headers. The 18 operations above send Deprecation and X-YoPrint-Successor.
• A key can’t manage itself. Reading, creating or resetting your key through the API answers 403 self_credential. Manage it in Profile.
• Purchase orders for Zapier. GET Get a purchase order /v1/api/store/{team_slug}/purchase_order/{hash_id} and PUT Change a purchase order's status /v1/api/store/{team_slug}/purchase_order/{hash_id}/status work again at their v1 paths.
• Payments and credit. An amount with decimals on a payment, a refund or any customer credit call answers 422 validation_failed instead of 500. Nothing is recorded.
• Customers and contacts. Creating, updating or upserting a customer or a contact ignores is_external and external_type, so a value read back and sent again can’t make a record read-only.
• Customer assignment. Assigning a user who isn’t a member of the team answers 422 (error.fields.user_id). Unassigning someone who isn’t assigned changes nothing and answers 200 with the list.
• Customer export. The customer CSV export leaves out deleted contacts.
• Profile. The API Access card shows when your key was last used, and a first request to copy.