> ## Documentation Index
> Fetch the complete documentation index at: https://apidocs.noyax.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Product card

> Fields and validation rules of the product record.

The product card is the main definition used by stock, invoice, order and quote records.

| Operation     | Endpoint                                                 |
| ------------- | -------------------------------------------------------- |
| List          | [`GET /products`](/en/v1/products/list)                  |
| Get           | [`GET /products/{productId}`](/en/v1/products/get)       |
| Create        | [`POST /products`](/en/v1/products/create)               |
| Update        | [`PUT /products/{productId}`](/en/v1/products/update)    |
| Delete        | [`DELETE /products/{productId}`](/en/v1/products/delete) |
| Group details | [`GET /products/groups`](/en/v1/products/groups/list)    |

## Required fields

<ParamField body="Code" type="string" required>
  Product code, unique within the company. Send `"Next"` on create to generate it from the company's **ÜRÜN** serial number definition; `"Next"` cannot be used on update (`2003`). The generation works exactly like the [customer code](/en/v1/customers/customer-code), only the serial number definition differs.
</ParamField>

<ParamField body="Name" type="string" required>
  Product name. At most 255 characters.
</ParamField>

<ParamField body="UnitId" type="string" required>
  Main unit; must be an ID from the [unit definitions](/en/v1/definitions/units/list).
</ParamField>

All other fields are optional.

## Product type

| Value | Product type              |
| ----- | ------------------------- |
| `1`   | Raw material              |
| `2`   | Semi-finished good        |
| `3`   | Finished good             |
| `4`   | Commercial good (default) |
| `5`   | Service                   |

Expense, fixed asset and consumable records are entered from separate screens in the application; they cannot be created through the API and those values are rejected (`2007`).

## Stock type

| Value | Stock type                  |
| ----- | --------------------------- |
| `1`   | No stock tracking (default) |
| `2`   | Stock tracking              |
| `3`   | Lot                         |
| `4`   | FIFO                        |
| `5`   | Serial                      |
| `6`   | LIFO                        |
| `7`   | FEFO                        |

## Tax fields

* `VatRateId`: an ID from the [VAT rate definitions](/en/v1/definitions/vat-rates/list).
* `AdditionalTaxCode1-3` and `AdditionalTaxRate1-3`: code and rate of an additional tax.

## Export fields

`Gtip`, `DeliveryTerm`, `PackagingType`, `TransportMode`, `OriginCountryCode`, `Brand` and `Model` are used in the additional information of export invoices.

| Value | Transport mode               |
| ----- | ---------------------------- |
| `0`   | Not specified (default)      |
| `1`   | Maritime                     |
| `2`   | Rail                         |
| `3`   | Road                         |
| `4`   | Air                          |
| `5`   | Post                         |
| `6`   | Multimodal                   |
| `7`   | Fixed transport installation |
| `8`   | Inland waterway              |

<Warning>
  The `TransportMode` of a product is the export code list; it is **not the same list** as the `TransportMode` of [shipment definitions](/en/v1/definitions/shipment-definitions/create) (1 road, 2 rail, 3 maritime, 4 air).
</Warning>

## Groups

`GroupDetailId1` ... `GroupDetailId5` hold the selected values of the product groups. The ID you send must belong to the matching group in the [group details](/en/v1/products/groups/list): only a group 2 detail can be sent as `GroupDetailId2` (`2011`).

Product groups are **hierarchical**: the parent of a detail (`ParentGroupDetailId`) is always a detail of the previous group.

* Group 1 details have no parent, so all of them are always selectable.
* Once a detail is selected in group 2, only the details **whose parent is that detail** and the details **without a parent** can be selected in group 3. The same rule applies for 3 → 4 and 4 → 5.
* **A detail without a parent can be selected under every parent.** For example a "SUV" body type that is valid for every brand is defined without a parent.

```
AUDİ (group 1)
└── SEDAN (group 2, parent AUDİ)
    └── JETTA (group 3, parent SEDAN)
SUV (group 2, no parent) -> selectable with every brand
```

The rule is validated when a product is saved: if `GroupDetailId3` is a detail whose parent is neither the detail selected in `GroupDetailId2` nor empty, the request is rejected with `2013`.

## Fields outside the API

The marketplace columns (Trendyol, Hepsiburada, N11, ...), images, variant fields, deposit information and the second and third unit fields of the product table are not managed through the API; they keep their database defaults.