Modelry

Delete a product via DELETE /v1/products/{id}. DESTRUCTIVE AND IRREVERSIBLE. Deletes the product, and with it the assets and the product viewers that hang off it -- including any viewer a storefront has already embedded, which stops rendering wherever it was published. Modelry answers 204 with no body and publishes no undelete.

Delete a product asset via DELETE /v1/products/{product_id}/assets/{id}. DESTRUCTIVE AND IRREVERSIBLE. Removes one asset from the product. If that asset is what a published viewer renders, the viewer is left with nothing to show. Modelry publishes no undelete.

Delete a product viewer via DELETE /v1/products/{product_id}/embeds/{id}. DESTRUCTIVE AND IRREVERSIBLE. Deletes the viewer. If it had been published, every storefront page carrying its embed stops rendering at that moment. Modelry publishes no undelete.

List modeling requests via GET /v1/modeling-requests. The modeling jobs Modelry's 3D artists are working for this account, newest first by default. `workspace_id` narrows to one workspace (get the id from List workspaces); `keywords` text-searches title, sku and batch_uid; `sort_by` takes an attribute and a direction as two array members and accepts sku, batch_uid, title, finished_at or created_at. `per_page` caps at 100 and defaults to 25.

Show a modeling request via GET /v1/modeling-requests/{id_or_sku}. One modeling request, addressed by EITHER its numeric id OR its SKU -- the same argument accepts both, which is Modelry's own contract. The reply carries `status`, `pipeline` (high_poly/low_poly/render), `price`, `inCustomerQa` and `customerQaUrl`, which together say whether this job is waiting on the customer to approve or reject it.

List a modeling request's assets via GET /v1/modeling-requests/{modeling_request_id_or_sku}/assets. The files delivered for this modeling request. Addressed by id or by SKU. THE SEALED REFERENCE DECLARES NO PARAMETER for the `{modeling_request_id_or_sku}` its own path carries; this build declares it, with the vendor's prose from the sibling operations, because an undeclared placeholder makes FastAPI refuse the route and takes the whole provider down at import.

List products via GET /v1/products. The workspace's 3D products, newest first by default. Nine filters, five of which are ARRAYS the vendor spells with brackets (`?tags[]=a&tags[]=b`) and this integration sends that way: `tags`, `source_label` (either 'Modeling request' or the name of the user who created it), `content_labels` (asset kinds such as 'Delivery Files', 'Renders', 'glTF Files', or a 3D file extension like '.max'), `tool_kinds` ('3D', '360HD', 'QR', 'AR') and `sort_by`, which takes an attribute and a direction as two members (`sort_by[]=title&sort_by[]=desc`). `per_page` caps at 100 and defaults to 25.

Show a product via GET /v1/products/{id}. One product by its numeric Modelry id -- not its SKU. Returns the product's attributes and the assets and viewers attached to it. A 403 here is Modelry's documented shape for a product the token cannot see (another workspace), not a bad credential; a refused credential is a 401 with an empty body.

Download a product's assets via GET /v1/products/{product_id}/assets/download. Modelry answers this one with a BINARY body rather than JSON (the reference types the 200 as `string`/`binary`), so Agentic Fabriq returns it under a `raw` key as decoded text: useful to confirm the download exists and what it is, NOT a way to move a 3D file intact. `source_file` and `delivery_files` narrow which assets are included; with neither, the account's default selection applies.

List a product's viewers via GET /v1/products/{product_id}/embeds. The product viewers configured for this product. A viewer is the embeddable 3D/AR widget a storefront renders; listing them is how you find the one to publish or to read a share URL from.

Show a product viewer via GET /v1/products/{product_id}/embeds/{id}. One product viewer by its numeric id, with its configuration, its viewer kind ('3D', '360HD', 'QR' or 'AR') and its embed details. Both ids are required and both are Modelry's own: the product's, then the viewer's -- a viewer id from a different product answers 404 rather than the viewer.

List workspaces via GET /v1/workspaces. The token owner's own workspaces, and the cheapest read Modelry publishes -- it is the probe on record for this provider. Use it FIRST: a workspace id from here is what narrows the modeling-request list, and it is the only place this API tells you which workspaces the pasted token can see. Page-numbered (`meta.page`, `meta.per_page`, `meta.total_records`).

Create a direct-upload blob via POST /v1/blobs. Step one of Modelry's two-step direct upload, for files too large to inline. It creates a `blob` record and returns a SIGNED BLOB ID plus the storage URL to PUT the bytes to; the bytes do not travel through this API at all. Step two is Attach an asset to a product, which takes that blob id. Use Upload a file instead for something small.

Create a modeling request via POST /v1/modeling-requests. Orders 3D modeling work from Modelry's artists, from a `modeling_request` object. THIS COMMISSIONS PAID WORK: a modeling request carries a `price` and is a real order against the account, not a draft record. Grant it only to an agent you mean to be able to spend.

File review issues on a modeling request via POST /v1/modeling-requests/{modeling_request_id_or_sku}/review_issues. Files a list of `review_issues` against the delivered model -- the specific corrections an artist works from. Send these BEFORE rejecting the request. Addressed by id or by SKU.

Create a product via POST /v1/products. Creates a product from a `product` object. This is the record the assets and the embeddable viewers hang off, so it is the first call in most write flows.

Attach an asset to a product via POST /v1/products/{product_id}/assets. Attaches an already-uploaded file to the product. `blob_id` is the SIGNED BLOB ID that Create a direct-upload blob returns after the file itself has been PUT to the storage URL in that reply -- this call moves no bytes. `tags` is a list of strings.

Create a product viewer via POST /v1/products/{product_id}/embeds. Creates a product viewer from a `product_viewer` object. THE PATH IN THE SEALED REFERENCE IS WRONG FOR THIS ONE OPERATION and this build ships the measured route: the reference keys it `/v1/{product_id}/embeds`, which answers 404 on the live API, while `/v1/products/{product_id}/embeds` answers 401 -- the same form the other four viewer operations use. Creating a viewer does not publish it; Publish a product viewer does.

Upload a file via POST /v1/uploads. The one-step upload, for a small file: `filename`, `content_type` and the file itself BASE64-ENCODED in `base64_file`. The whole payload travels as JSON in this request, so it is the wrong call for a large 3D asset -- use Create a direct-upload blob for those.

Approve a modeling request via PUT /v1/modeling-requests/{id_or_sku}/approve. Accepts the delivered model, ending customer QA for this request. A one-way step in Modelry's workflow -- the reference publishes no un-approve -- and it is what releases the request as finished. Address it by id or by SKU.

Reject a modeling request via PUT /v1/modeling-requests/{id_or_sku}/reject. Sends the delivered model back to the artists for rework. File the specific problems with File review issues on a modeling request first: a rejection without them tells the artist nothing. Address it by id or by SKU.

Update a product via PUT /v1/products/{id}. Replaces the product's attributes from a `product` object. Modelry publishes no field-level PATCH for a product, so send the attributes you mean to keep as well as the ones you mean to change.

Publish a product viewer via PUT /v1/products/{product_id}/embeds/{id}/publish. Publishes the viewer, which is what makes its embed render outside Modelry. This is a write with an EXTERNAL effect: after it, the widget is live wherever its snippet is pasted, and deleting the viewer later breaks that page.