> ## Documentation Index
> Fetch the complete documentation index at: https://docs.readyforcommerce.com/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> Ready for Commerce is an ecosystem that currently contains two products, PIM and Repricer, standing on one shared foundation: one identity, one organization, one team, one bill. Do not call it a platform with features, and never hint at an unreleased product.
> PIM connects to Shopify, Amazon, Square, Google Merchant Center and BigCommerce. Repricer connects to Amazon, Walmart, Shopify, BigCommerce, eBay and Square. The two products do not share one list, and each integration is authorized separately inside each product. The roster grows on purpose, so describe what the product does and let a table carry which integrations do it today, instead of counting them or writing that only one does something.
> Integration is the word this product uses, and it is the default in the documentation: the connection, the account, the Integrations screen, the per-account settings and the sync state are all integrations. Channel is reserved for the narrow sense of a destination where a listing lives, as in a product being live on a channel or archived on the channel.
> Newegg is not a supported channel. Do not describe it.
> On Amazon, PIM manages the offer only: price, availability and condition. It does not publish listing content such as titles, descriptions, images or specifications.
> Sign-in is passwordless: a single-use code emailed to the user, or Google. There are no passwords anywhere, so never describe a password, a sign-up with a password, or an email confirmation link.
> There is no public API for customers and no customer-facing webhooks. There is no organization-wide activity feed and no audit export, but the PIM does keep version history on products, brands, categories, tags and specifications, with who changed what and a restore, so never write that changes are not recorded or that an edit cannot be undone. Do not describe capabilities that are not documented here.
> Never write that the products have no AI, and never write that anything is AI-powered. Both are wrong. The PIM's image Optimizer runs AI-backed transforms the seller starts on purpose: Upscale, Remove background, and the region selection behind Refine. The Repricer reads competitor prices off web pages on the server. No control, badge or tooltip in either product names AI, and the seller never writes a prompt, so describe what the buttons do in the app's own words instead of reaching for the word.
> A PIM product, brand, category or variant can be switched off per connected integration account. Hover the channel badge and the switch is beside the account name in the card that opens. It carries no visible caption, so never call it the Sync switch: Sync is only its accessible name. On a variant-grained provider, Amazon today, the switch moves into the variant editor. On a product it asks whether to delete it from the channel, archive it there, or leave it live. Disabling stops publishing, not reading. There is still no per-field sync toggle.
> The PIM's image Optimizer replaced a feature called Squarify, which no longer exists. It resizes to an aspect ratio or to exact dimensions, removes backgrounds, upscales, trims the transparent margin around a cutout and re-centers it, pads, fills and re-encodes, and it always publishes a new asset instead of changing the original. Nothing crops into the picture: the subject is always contained whole.
> The PIM has no repricing engine and never reacts to a competitor's price. It does build the price it publishes to each integration account from the seller's own fields, configured in that account's settings, so do not write that the PIM has no pricing rules.
> Neither product has an in-app notification center, bell or inbox. Notifications are delivered by email only.
> Billing is per organization and per product, and only the organization owner can see or change it. Team members are free and uncounted, so never describe seats or per-user pricing.
> The seller never picks a plan. Each product has twelve price tiers assigned automatically from usage: the PIM from catalog product count, which includes drafts and archived products, and the Repricer from trailing 30-day sales. Nothing is feature-gated by plan and exceeding a tier never blocks work, so never write that a feature requires a higher plan.
> A subscription that is past due or paused makes the product read-only, which stops repricing and blocks edits without deleting data. Only a canceled subscription locks the seller out. Nothing is ever charged without a payment method on file.
> Pages containing the text 'This page has not been written yet', or its Spanish equivalent 'Esta página todavía no está escrita', are placeholders. Do not treat their headings as documented behavior.
# Identifiers
> Every code that identifies your product is in one list on the variant, and each integration you connect takes the ones it needs from that list.
An identifier is a value that lets something outside the PIM recognize your product. A scanner reads a barcode, Amazon matches an ASIN, and every integration you connect finds your variant by its SKU. Your own spreadsheets and labels use them too.
The PIM keeps all of a variant's identifiers in one list. You type each value once, and every connected integration with a field for it gets it from that same list. You never paste the same barcode into 3 places.
You will find the list in the product editor. From `Catalog`, open `Products` and click a product: the `Identifiers` section is between `Taxonomy` and `Assets`. Once a product has options, that section is gone, and each variant keeps its own list instead, which you open through the `Variants` section one variant at a time.
The section moves because identifiers are set on your variant, not on your product. A red shirt and a blue shirt are 2 different things to scan, so each variant needs its own barcode and its own SKU. The page on [variants](/pim/catalog/variants) explains options and variants themselves.
## Before you start
You need the `Editor` role or above to change a product, and identifiers are part of the product. Roles are set in [team, roles and permissions](/team#what-each-pim-role-can-do).
Check an ASIN against the Amazon listing before you save. The link between your SKU and the ASIN is set the first time the offer is sent, and a wrong ASIN puts your price on someone else's product page.
## How to add an identifier
From `Catalog`, open `Products` and click the product you want. The `Edit Product` dialog opens over the page.
Scroll to `Identifiers`, between `Taxonomy` and `Assets`. If the product has options, open the `Variants` section instead and click the variant you want: the `Edit Variant` dialog opens with `Identifiers` at the top.
Click `Add` at the bottom of the section. A row appears with a `Type` dropdown and a `Value` box. Your first row arrives as `SKU`, and after that new rows arrive as `Barcode`.
Set `Type` to the kind you are adding and type into `Value`. An `ASIN` row also asks for a `Marketplace`, and a `Custom` row also asks for a `Custom Label`.
Click `Update`. While any row shows an error, the button stays off, so fix the row or remove it.
That is the whole job. Each row checks its value as you type, and a moment after you stop typing the PIM also checks that the value is not already taken elsewhere in your catalog. Once every row is clean, your save goes through, and the next sync sends your new values out.
Everything below is detail: what each type is for, which values have to be unique, and what each of your integrations does with them. You do not need any of it to give a product a SKU and a barcode.
## Every option in detail
### The six types
The `Type` dropdown gives you six kinds of identifier, and the type decides what you can put in `Value`.
| Type | The value it accepts | The extra field |
| --- | --- | --- |
| `SKU` | Any text. This is the value integrations match your variant on | None |
| `Barcode` | Digits only, and exactly 8, 12, 13, or 14 of them. The box drops anything else as you type | None |
| `Part Number` | Any text, usually the number your manufacturer uses | None |
| `ISBN` | Exactly 10 or 13 digits, plus a final `X` on some 10-digit ones. You can type hyphens and spaces | None |
| `ASIN` | Exactly 10 letters or digits, uppercased as you type | `Marketplace`, required |
| `Custom` | Any text, for anything the other types do not cover | `Custom Label`, required |
There is no UPC, EAN, or MPN type, and none is missing. A UPC-A is 12 digits, an EAN-8 is 8, an EAN-13 is 13, and a GTIN-14 is 14, which is exactly the set `Barcode` accepts.
Your manufacturer's part number goes in `Part Number`. If you are reading down the `Type` list for UPC or EAN, `Barcode` is your row.
**A barcode or an ISBN has to be real.** The PIM checks a barcode's last digit the way a scanner would, and an ISBN against the published ISBN rules. A value with one digit mistyped is rejected, which is the point: you catch the typo here instead of on a printed label.
A barcode must pass the GS1 check, where the last digit is calculated from all the others, so any single digit you mistype breaks it. An ISBN-10 has its own version of the same idea, and an ISBN-13 must also start with `978` or `979`.
You can paste a hyphenated ISBN such as `978-3-16-148410-0`. The PIM checks and stores the digits alone, then shows you the value hyphenated again. The hyphens go where the official ISBN ranges put them, which is not always where you typed them.
### Let the PIM write the SKU for you
Every `SKU` row has a generate button at the right end of its `Value` box. Click it and the PIM fills in a value for you, shaped like `ABC-234-XYZ`, 3 letters, 3 digits, 3 letters, guaranteed unused in your organization. The alphabet leaves out characters people misread, so you never get an `I`, `L`, or `O`, and never a `0` or `1`.
If the row already has a value, the PIM asks before replacing it, with `Replace` and `Cancel`. A short `SKU generated` message confirms it worked.
### Put the rows in the order you want them sent
Once a variant has 2 or more rows, a drag handle appears on the left of each one, and you can drag the rows into any order. The order you set here is the order your integrations see.
Where an integration has room for only one value of a type, the PIM sends your first row of that type and the rest stay in the PIM. Where it has room for a list, your rows go out in your order. So dragging a row to the top is not tidying: it changes what leaves the PIM.
`SKU` is the one type where order never matters, because your variant only ever has one.
### The uniqueness rules
Some identifiers have to be unique, and the PIM rejects a save that breaks a rule instead of warning you. Each type answers two questions its own way: how many rows of it your variant can have, and where the value must be unique.
| Type | Rows on one variant | Where the value must be unique |
| --- | --- | --- |
| `SKU` | 1 | Your whole organization |
| `Barcode` | As many as you want | Your whole organization |
| `ISBN` | As many as you want | Your whole organization |
| `Part Number` | As many as you want | Only among products sharing one of its brands |
| `Custom` | As many as you want | Nowhere. The label is the unique part, once per variant |
| `ASIN` | 1 per marketplace | Nowhere, and two products can have the same ASIN |
Because your variant has only 1 SKU, the `Type` dropdown stops showing `SKU` on your other rows once one exists. The row that has it keeps it.
**`Part Number` collides only inside a brand.** Two products conflict only when they share at least one brand. You can use the same part number under two different brands, and a product with no brand conflicts with nothing. The rule runs in both directions: you also cannot attach a brand to a product while that brand already has one of the product's part numbers elsewhere. That is the same conflict arriving from the [brands](/pim/catalog/brands) side.
**`Custom` rows watch the label, not the value.** Any number of variants can share a value, and nothing checks it. What one variant cannot have is two custom rows with the same label, capitals or not. Nothing flags that while you type, so it arrives at save time as a general message about a value that already exists. If you get that message and every value looks unique, compare your custom labels.
The same value twice on one variant is rejected for every type, and both rows are marked the moment you type the second one.
Duplicating a product copies almost everything and deliberately leaves the identifiers behind, because every value with a uniqueness rule would collide the moment you saved the copy.
- `SKU`, `Part Number`, and `Custom` values ignore case and extra spaces: `abc-123` and `ABC-123` are one value, and so are `A B` and `A B`. A hyphen and a single space still count, so `ABC-123` and `ABC 123` are two different values.
- Two barcodes are compared as full 14-digit codes, with zeros added in front of the shorter one. The UPC-A `012345678905` and the GTIN-14 `00012345678905` are the same barcode and cannot both exist in your catalog.
- Two ISBNs are compared with hyphens and spaces removed, and a final `x` counts the same in either case, so neither ever makes two ISBNs look different.
### Add an ASIN for each Amazon marketplace
An ASIN tells the PIM which Amazon listing your offer goes on. The marketplace is part of the answer, because the same product is a separate listing on amazon.com and on amazon.ca. So every `ASIN` row has a `Marketplace` dropdown beside its value, with 22 Amazon marketplaces in it, and a new row starts on `United States (amazon.com)`.
A variant you sell in the United States, Canada, and Mexico has 3 ASIN rows, one per marketplace. A second row on a marketplace that already has one is rejected before you can save.
**Every ASIN in your catalog is typed by a person.** There is no ASIN lookup and no Amazon catalog search in the PIM. Your [imports](/pim/uploads/imports) and [exports](/pim/uploads/exports) move the other identifier types by file and leave ASINs out. Reading your Amazon account in does not add any either: the PIM only uses the ASIN rows you typed to recognize offers you already have. Copy the ASIN from the listing page on Amazon and paste it in.
### Find a product by an identifier
The search box above the [products](/pim/catalog/products#reading-the-products-table) table, marked `Search...`, matches what you type against product titles, identifier values, and custom labels. Pasting a SKU or a barcode into it is usually the fastest way to your product.
The table also has an `Identifiers` column, which shows you up to 3 of each variant's values. To search one type alone, filter that column. Click `Filters` above the table, set `Filter by` to `Identifiers`, and pick a condition such as `contains` or `equals`. Then start your text with a type prefix: `sku:ABC-123` matches SKUs only. The prefixes are `sku:`, `gtin:`, `pn:`, `isbn:`, and `custom:`, there is no ASIN prefix, and you cannot sort the column.
### Limits
| What | Limit |
| --- | --- |
| A value you type | 100 characters |
| A `Custom` label | 50 characters |
| `SKU` rows on a variant | 1 |
| `ASIN` rows per marketplace | 1 |
| Values shown in the `Identifiers` column | 3 per variant |
### What identifiers cannot do
| You cannot | Do this instead |
| --- | --- |
| Look up an ASIN from inside the PIM | Copy it from the listing page on Amazon |
| Bring ASINs in or out by file | Type each one on its variant |
| Sort the products table by the `Identifiers` column | Filter the column, or use the search box |
| Give one variant a second `SKU` row | Put the second value in `Part Number` or `Custom` |
## What your integrations get
What goes out depends on the fields each of your integrations keeps. Every integration gets a SKU, because the SKU is how it recognizes your variant. Most keep one barcode field, and everything else goes out only where there is somewhere to put it.
| Integration | What it gets |
| --- | --- |
| Shopify | Your SKU and 1 barcode in its own fields, plus every ISBN, part number, and custom pair in fields the PIM creates |
| Square | Your SKU and 1 barcode in its own fields, plus the SKU and the first part number as named attributes |
| BigCommerce | Your SKU, 1 barcode, and your first part number |
| Google | Your SKU as the listing's identity, up to 10 barcodes, your first part number, and the brand |
| Amazon | Your SKU and your ASIN for that marketplace, and nothing else |
**Which barcode goes where one fits.** Square and BigCommerce read your `Barcode` and `ISBN` rows top to bottom and take the first value they accept: 12, 13, or 14 digits. An ISBN-10 is converted to its 13-digit form on the way. An 8-digit barcode is skipped instead of sent, so a longer row further down still goes out. Google takes up to 10 of your values and accepts 8-digit codes. Shopify takes exactly your first `Barcode` row, and later barcode rows stay in the PIM.
### What Shopify gets
Shopify keeps the widest set. Its own SKU and barcode fields take your SKU and your first `Barcode` row. Your ISBNs, part numbers, and custom rows go out whole, in your order, into three fields the PIM creates in your store and manages.
Those three fields are filled from here and nowhere else. Somebody can still edit one in the Shopify admin, because Shopify offers no way to lock a field like that, and your next push writes your version back over the edit. [The Shopify integration](/integrations/shopify) covers the rest.
Shopify shows them on the variant as `ISBN`, `Part number (MPN)`, and `Custom identifier`, and your storefront can read them. Custom rows arrive as `label=value` pairs, split at the first `=`. So a value may contain `=` and a label may not: a label with `=` in it does not make it across.
### What Square gets
Square's own fields take your SKU and one barcode. Square also gets two named attributes the PIM creates on each variation, `SKU` and `Part Number`. The `SKU` attribute always has your own SKU row, even when the `SKU field` setting below sends something else as the SKU, so your original never disappears from Square. The part number is your first row only.
If your variant's only barcode row is 8 digits, with no ISBN below it, Square gets no barcode at all.
Square receipts do not show a SKU. The account setting `Identifiers in the variation name`, on the account's settings page under `Integrations`, adds it to the variation name instead, where receipts and your Square Online store can show it. Your choices are `Don't add`, `SKU`, `Part Number`, and `SKU and Part Number`. Products without options are left alone.
### What Google gets
Google finds a listing by its SKU, so a variant with no SKU is not sent, and the product tells you so. With the SKU go up to 10 barcodes, your first part number, and the brand. A variant with no barcode and no part number is still published: the PIM tells Google your product has no standard identifiers instead of keeping it back.
Google never writes identifiers into your catalog. On first connect it uses your SKUs, part numbers, and barcodes to recognize listings you already have, and that is all.
### What Amazon gets
Amazon gets an offer, not a product page. With the SKU-to-ASIN link go the condition, the price, and, for offers you ship yourself, the quantity. It never gets your titles, descriptions, images, brands, categories, or specifications, in either direction. That is why [the integrations section](/pim/integrations) describes an ASIN as a link to a listing Amazon already has.
An offer goes out once your variant has all three of a SKU, an ASIN for that marketplace, and a price the account's settings can produce. With no SKU or no ASIN, nothing is sent and nothing is flagged. With no price, the product is flagged, with a message naming the gap.
### Send a different identifier as the SKU
Shopify, Square, Google, and BigCommerce accounts each have a `SKU field` setting, in the `Identity` section of the account's settings page under `Integrations`. It gives you `SKU`, `Part Number`, and `Barcode`, and it decides which of your identifiers that account gets as its SKU. It is per account, so one integration can run on your part numbers while another runs on your SKUs. Amazon has no such setting, because Amazon treats the first SKU it gets as the offer's permanent name.
Two things happen behind that choice:
- **A duplicate is made unique for you.** When the chosen value is not unique across your organization, the PIM puts the product's brand in front, as `BRAND-VALUE`. The integration still gets something unique. If even that collides, the product does not sync, and tells you so.
- **A variant missing that identifier does not sync at all.** The product is flagged with a message naming what is missing. There is no quiet fallback to your SKU, because a silent replacement would publish two different names for the same variant.
Your own `SKU` row never changes: the setting only decides what the integration is told. [Integration settings](/pim/integrations/settings) has the rest of the per-account settings.
### What a read writes into your list
Connecting an integration can also write identifier rows, so a variant's list is not only what you typed.
A barcode from an integration always arrives as `Barcode`, whatever it really is. A store keeps one barcode field, and nothing in it says whether the value is a UPC or an ISBN. So the PIM files them all under `Barcode` and leaves the judgment to you. If one is really an ISBN, open the product and set that row's `Type` to `ISBN` once, and the next sync sends it to the right field.
A variant with no SKU in the store gets a placeholder, because nothing can be matched without one. A Shopify variant arrives with a SKU built from `_shopify-` plus the product's handle and the variant's own number. A Square variation arrives as `_square-` plus its own number, and a BigCommerce variant starts with `_bigcommerce-`. Replacing placeholders with your own SKUs is normal work, not a repair.
A value your catalog already uses is dropped, not merged. On a Shopify first sync, a duplicated barcode or ISBN is skipped, and the product is flagged so you can settle the collision yourself. A duplicated SKU stops that whole product from importing. Square drops a barcode that fails the digit check, and nothing tells you it happened.
| Integration | What a read writes |
| --- | --- |
| Shopify | The SKU and the barcode, on the first sync |
| Square | The SKU and the barcode, on the first sync |
| BigCommerce | The SKU, the barcode, and the part number, on the first sync |
| Google | Nothing |
| Amazon | Nothing. Your ASIN rows are only read, to recognize existing offers |
## When something goes wrong
### Reading the error on a row
A row with a problem tells you under its `Value` box as you type. The messages name the type on the row, so `SKU` below stands in for whichever type yours is.
| What happened | The row says |
| --- | --- |
| The value is empty | `SKU requires a value` |
| A barcode with the wrong number of digits | `Barcode must be exactly 8, 12, 13, or 14 digits` |
| A barcode with anything but digits in it | `Barcode must contain digits only` |
| A barcode whose last digit does not check out | `Barcode check digit is invalid. Verify the last digit against the GS1 Mod10 checksum` |
| An ISBN of the wrong length | `ISBN must be exactly 10 or 13 digits` |
| An ISBN-13 starting with anything else | `ISBN-13 must start with 978 or 979` |
| An ISBN whose check digit does not match | `ISBN-10 check digit is invalid` or `ISBN-13 check digit is invalid` |
| An ASIN that is not 10 letters or digits | `ASIN must be exactly 10 letters or digits (e.g. B0XXXXXXXX)` |
| An ASIN row with no marketplace | `ASIN requires a marketplace` |
| A second ASIN row on one marketplace | `Each Amazon marketplace can have only one ASIN` |
| A `Custom` row with no label | `Custom identifiers require a label` |
| The same value on two rows | `SKU ABC-123 is duplicated`, shown on both rows |
| A second `SKU` row | `Only one SKU can be assigned to the same product or variant` |
The checks run while you type, so a longer code flashes a check-digit error at the lengths it passes through. Type your whole number before you read the message.
### The check you do not see
A moment after you stop typing, the PIM checks whether your value is already taken elsewhere in your catalog, and answers on the row.
| Row type | The row says |
| --- | --- |
| `SKU` | `SKU already in use elsewhere in your catalog` |
| `Barcode` | `Barcode already in use elsewhere in your catalog` |
| `ISBN` | `ISBN already in use elsewhere in your catalog` |
| `Part Number` | `Part number already in use for one of the selected brands` |
Your `Custom` and `ASIN` rows are never checked this way, because neither has a value that must be unique.
While any of your rows shows an error, or that check is still running, the save button stays off. Fix the row, or remove it, and the button comes back.
### When the save itself is rejected
Two people can claim the same value in the same few seconds, and whoever saves second finds out then. The message you get is worded from the product instead of the row.
| Message | What to do |
| --- | --- |
| `One of these SKU values is already in use elsewhere in your catalog` | Another product took your SKU first. Change yours |
| `One of these Barcode values is already in use elsewhere in your catalog` | The same, for a barcode |
| `One of these ISBN values is already in use elsewhere in your catalog` | The same, for an ISBN |
| `One of these Part Number values is already in use for one of the selected brands` | Change the part number, or the brand you share |
| `A product with one of these values already exists` | Usually two `Custom` rows sharing a label. No row is highlighted, so compare your labels yourself |
The messages in this table and the previous one show in English even when you use the app in Spanish.
The generate button has one failure of its own, `Could not generate a unique SKU. Try again or enter one manually.`, which means it kept hitting values that were already taken and gave up, so you type one in yourself.
### Messages from a sync
When a sync cannot use your identifiers, the product's sync status for that integration says so.
| Message | What it means |
| --- | --- |
| `No Part Number is available to send to Shopify as the SKU.` | Your `SKU field` choice names an identifier your variant does not have. Each integration has its own version of this message |
| `Could not derive a unique SKU for Shopify from the Part Number.` | Even with the brand in front, the chosen value collides. Change the value, or the setting |
| `Google identifies a product by its SKU, and this variant has none.` | Give your variant a SKU |
| `No price is available for Amazon (none of the configured price sources has a value).` | The offer has its SKU and ASIN and no price. Set one |
| `Amazon couldn't match this listing to the ASIN.` | Amazon rejected the pairing. Check your ASIN against the listing again |
| `Barcode is already used by another product; not imported.` | A Shopify read hit a value your catalog already has. That row was skipped, and the rest of the product arrived |
## Where to go next
Why identifiers move off the product the moment it has options.
The scope that decides when two part numbers collide.
Every per-account setting, including which identifier goes out as the SKU.
Bringing identifiers in by file, and the one type that cannot.