A product tag in the T-Gate platform is a free-form label that partners attach to one or more products to group them for downstream use cases — for example, marking a set of products as "Spicy", "Best Seller", or "New Arrivals". Tags are scoped per company: every product tag belongs to a single POS company, and a tag can only be assigned to products that live under the same POS company.

For more details on the hierarchical structure and how different entities relate to each other, please refer to General → High Level Structure Guides.

Model Attributes

The partner portal exposes product tags through two endpoints: POST /partner_portal/v1/product_tags (create) and PUT /partner_portal/v1/product_tags/:id (update). Both endpoints return the full attribute set described below; there is no listing or show endpoint for product tags on the partner portal.

Attribute	Description	Type
id	The unique identifier of that table entity.	Integer
name_en	Product tag name in English. Required, 3–50 characters.	String
name_ar	Product tag name in Arabic. Optional; when provided must be 3–50 characters.	String or Null
name	Localized product tag name returned according to the request's `Accept-Language` header. Resolves to `name_en` for `en` and to `name_ar` for `ar`.	String
item_ids	Array of `Item` ids currently tagged with this product tag.	Integer Array

📘
name VS name_en / name_ar
Responses always include both name_en and name_ar so consumers can render either translation regardless of the current request locale.
The name attribute is a convenience field resolved on the server side from the Accept-Language header. Applications that already maintain their own localization layer can ignore it and read name_en / name_ar directly.
Note that name_ar is optional — when it has not been set on the tag, both name_ar and (when the locale is ar) name will be null.

📘
item_ids
item_ids reflects the current set of products tagged with this product tag. On create and update, the partner application sends an item_ids array; T-Gate then synchronizes the underlying assignments so the tag ends up linked to exactly that set of items.
Items that previously carried the tag but are not present in the new item_ids array are unassigned, and items that are present but were not previously linked are assigned.

Tagging Rules

Tagging is governed by a small set of rules enforced when the partner application sends item_ids:

Rule	Description
Products only	Only items with `item_type = product` can be tagged. Attempting to tag a `modifier_group` or `modifier` item fails the request.
Same POS company	The tagged item and the product tag must both belong to the partner's POS company. Cross-company assignments are rejected.
Unique pair	The same `(product_tag, item)` pair cannot exist twice. Re-sending an already-assigned item is a no-op for that item.

🏢
POS Company Scoping
A product tag is created against the partner's default T-Gate POS company; the partner application does not — and cannot — specify the POS company explicitly. As a result, every tag returned by the API only ever references items that live under the same POS company, and a tag cannot be shared across companies.

🧹
Tag Deletion Cascades
When a product tag is deleted, all of its product_tagging links are removed in the same transaction (the join table is destroyed dependent: :destroy). The underlying items themselves are not affected — only the assignment between them and the deleted tag.

Relationship With Products

The link between a product tag and an item is stored as a product_tagging join record. Each product_tagging references exactly one item and one product tag, and the pair is enforced to be unique.

This relationship is many-to-many:

A single product tag can be applied to many items (exposed as item_ids on the tag).
A single item can carry many product tags.

Partner integrations that want to display the tags attached to a given product should read them from the item's own representation rather than scanning every tag's item_ids array.