A documented REST API
Designs, versions, renditions at any loom and client metadata, all under /v1. The OpenAPI 3.1 document is generated from the same schemas the service checks requests against, so the two cannot disagree.
API and integrations
Design data your other systems can read.
A shop that shows colourways, a factory system waiting for approved maps, a configurator on your own site. They connect to the same service your designers use, through the public API.
# The workspace's designs
$ {
"data": [{
"id": "cmh2x...",
"title": "Medallion, indigo",
"drawnFor": { "technique": "HANDWOVEN", "raj": 40, "knotAspectRatio": 1.15 },
"latestVersion": { "sequence": 4, "status": "IN_REVIEW" }
}],
"next": null
}Webhook received
POST https://your-shop.example/toranj
Toranj-Event: version.approved
Toranj-Signature: t=1793520000,v1=9f2c...Webhooks, switched off for now
Events are written in the same database transaction as the change itself, and signing and retries are built. But sending them is not switched on in the current site. If you need them, tell us.
A link that opens the editor
Your system can ask for a one-time link that opens the editor on one design, for one person, and nothing else. They never see a login page and never see anything else.
Keys tied to one workspace
A client key acts inside one workspace with the scopes it was given: read, write, meta. For now we make keys for you, and once revoked a key stops. Each action in the log carries the name of whoever did it.
An AI assistant under the same rules
The MCP server gives an assistant such as Claude the same tools as a designer: draw, place motifs, render, read what changed. It works under its own name in the log and it can never approve a version.
The details
Request access- Protocol
- REST, JSON, OpenAPI 3.1
- Auth
- Bearer key, scoped, one workspace
- Events
- Signed webhooks, with retries; sending is off for now
- Plan
- We make keys for you for now; webhooks are on the Studio plan
- AI
- MCP server