Skip to main content
Twelve paths still answer under an earlier prefix. They serve the same operations on the same data, so nothing you have already shipped needs to change today.

​
What changed

The twelve are marked deprecated in the OpenAPI spec and left out of the reference navigation, so new code lands on the current name. Left out of the navigation, not left out of the spec: download the spec and the twelve are still in it, with deprecated: true on each, so a generated client keeps every method it has and your linter is the one that tells you which to move off. Three things carry the earlier spelling, and each one moves on its own: the path you call, the kind a job reports, and the event name a webhook endpoint receives.

​
How to tell whether this affects you

  • A request URL in your code contains /api/v1/sudoai/2d-mockups or /api/v1/mockups.
  • Your generated client or linter flags one of its methods as deprecated.
  • A job you read back reports kind as 2d_create or 2d_render.
  • A webhook body you receive carries an event that starts with 2d_mockup. or 2d_render..
  • A request to /api/v1/sudoai/2d-mockup/render or /api/v1/sudoai/render answers 404.

​
What to change

​
Photo mockup paths

Everything under /api/v1/sudoai/2d-mockups is the same operation as its /api/v1/photo-mockups twin, on the same data. Moving is a string swap: the headers, the body and the response are identical. The current two step flow, end to end, is in Photo mockups.

​
PSD mockup paths

Five paths under /api/v1/mockups answer for the PSD mockup collection under its earlier prefix.

​
The two retired render paths

The singular render paths were retired and answer 404: /api/v1/sudoai/2d-mockup/render and its older alias /api/v1/sudoai/render. The mockup id moved out of the request body and into the URL, so the body now carries only print_areas and export_options. Render artwork has the shape the body takes now, and Render a photo mockup carries the full contract.
404 Not Found
Seeing this on a path you believe is current points at the id, not the name. Check that the mockup id in the URL belongs to your account before you change anything else.

​
The job kind

A job accepted on an earlier path reports the earlier kind, and the same job accepted on the current path reports the current one. Code that compares the kind literally should accept both spellings while you move.

​
Webhook event names

A webhook endpoint created before the current names were introduced is pinned to the earlier spelling and keeps receiving the same five events under it. The kind inside a payload always follows the endpoint, whichever path accepted the job.
A pinned endpoint's payload
The endpoint object reports the spelling it receives in event_naming. An endpoint follows the spelling its event_types list is written in, and falls back to legacy when the list does not say. Re-pin an existing endpoint to current with Update an existing webhook endpoint once your handler reads the new names.
Change the handler before the endpoint. The switch takes effect on the next delivery, and a handler that still matches only on 2d_render.succeeded will stop recognising its own renders.
Event names, payloads and signature verification are covered in Webhooks.

​
If you are still stuck

  1. Check the path in your request against a current name in the tables above.
  2. Read kind on the job and event on the webhook body, and accept both spellings until every caller has moved.
  3. Regenerate your client from the current spec, so the deprecation warnings point at what is left.
  4. Contact us with the request path and the job id.