Move a design to another project

PUT/designs/{designId}/project

Sample request

cURL

curl -X PUT "https://api.abyssale.com/designs/$DESIGN_ID/project" \
  -H "x-api-key: $ABYSSALE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "project_id": "9d00e9fe-9bd5-4471-acad-baa702a867e9"
  }'

Example request body

{
  "project_id": "9d00e9fe-9bd5-4471-acad-baa702a867e9"
}

Example 200 response

{
  "project_id": "00000000-0000-0000-0000-000000000000",
  "id": "64238d01-d402-474b-8c2d-fbc957e9d290",
  "name": "Summer sale",
  "version": "v2026-10-20"
}

Example 400 error response

{
  "id": "project_not_found",
  "message": "Project UUID '9d00e9fe-9bd5-4471-acad-baa702a867e9' not found"
}

Move one design to another project of your workspace. List the projects, and their ids, with GET /projects.

Behaviour, limits and caveats

Moving a design resets its approval status, since that approval was given within the project it leaves. Moving a design to the project it is already in changes nothing, approval status included.

Any design that GET /designs lists can be moved. Anything else answers 404 template_not_found (see DELETE /designs/{designId}). A destination that is not a project of your workspace, or a deleted one, answers 400 project_not_found.

Path parameters

designId string (uuid) required

Unique identifier (UUID) of the design. A value that is not a UUID does not match the route and answers 404 with id: endpoint_not_found.

Request body

project_id string (uuid) required

The id of the destination project, from GET /projects.

Response 200

The design is now in the destination project.

project_id string (uuid) always

The project the design is now in.

id string (uuid) always

The design's id.

name string always

The design's name.

version string

The API version that produced this response, named by release date (vYYYY-MM-DD). Pattern ^v\d{4}-\d{2}-\d{2}$.

More about version

The API version that produced this response, named by release date (vYYYY-MM-DD). Stamped as a top-level field on JSON object bodies, success and error alike, so a client can always tell which contract answered. There is no version-selection parameter — a single version is maintained at a time.

Two kinds of body are not stamped. Array bodies (the listings) carry no envelope. And a body that already has a version key of its own is left alone — which in practice means Banner, whose version is the generated file's integer counter. So GET /banners/{bannerId} and the synchronous generate are the two responses that do not tell you which contract answered.

The value changes when a new version is released. Match the vYYYY-MM-DD shape rather than pinning today's literal, or your client breaks on the next release.

Errors

Every failure uses the shared error envelope — {id, message, errors?}. Branch on id, never on message. See Errors.

Status	When
400	project_id is missing (missing_required) or not a UUID (invalid_payload), or the project does not exist in your workspace or is deleted (project_not_found).
401	Unauthorized — missing or invalid API key.
404	No design that GET /designs lists has this id (template_not_found): it never existed, is already deleted, is in a deleted project, is a workspace template, or belongs to another workspace.
429	Too Many Requests.
500	Internal Server Error — an unexpected error occurred on our side.

Related

• Designs guide