SKU aliasing
Use your own product and material identifiers instead of Viewa IDs.
Your storefront already has SKUs. Rather than maintaining a mapping table on your side, you can register your identifiers as aliases against Viewa catalog objects, then use them anywhere the API takes a catalog reference.
How it works
An alias binds one of your external IDs to exactly one catalog target (a product, a
material or a material set). Once registered, endpoints that accept a catalog ref
resolve your ID exactly as if you'd passed the Viewa public ID. A product alias can also
pin a material, for a SKU that identifies a product and fabric/colour together.
Aliases are scoped to your instance — your SKUs never collide with another client's. SKUs match case-insensitively and ignore surrounding whitespace.
Managing aliases
Manage aliases from your server with your secret key. The SKU itself is the address, so there is no separate alias id to track:
| Call | Does |
|---|---|
PUT /api/v1/aliases/{sku} | Register the SKU, or repoint it if it already exists |
GET /api/v1/aliases/{sku} | Read one registration |
DELETE /api/v1/aliases/{sku} | Remove it |
GET /api/v1/aliases | Audit every registration |
PUT /api/v1/aliases/ELITE-ROLLER-01
Authorization: Bearer sk_…
Content-Type: application/json
{ "target": "prod_3xK9aQ0ZbW7mNc2LpRvT", "material": "mat_8hT3kW1qZr6YbN0cVxLp" }PUT is idempotent, so syncing your catalog is a matter of replaying it for every SKU.
Management writes are limited to 600 a minute per key; on a 429, wait for the
Retry-After seconds and continue. That limit is counted separately, so a sync never
slows your shoppers' uploads or renders.
Changes take effect on the next request. A registration is refused with 422 when its
target isn't in your catalog, when the material isn't offered on the product, or when
the SKU starts with a reserved prefix such as prod_ or sk_.