> ## 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.
# Sync history
> Sync history shows you what a data source actually did each time it ran, how many rows it read, how many it matched and how many it changed.
Sync history tells you what one of your data sources actually did, run by run. Every time a source goes and fetches your supplier's file, it leaves you a line here. That line has the numbers from that run: how many rows your file had, how many of them found a record in your catalog, and how many of those went in.
You open it for one of three reasons. A run tells you it worked and you cannot see any difference in your catalog. A supplier's numbers have stopped arriving with no warning. Or one of your products is not picking up its price and you need the reason for that single row.
You will find it on your data sources list. Go to `Uploads`, select the `Data Sources` tab, and click `History` in the `Actions` column at the right end of a source's row. A dialog opens over the page with a table of that source's runs, newest at the top, going back to its very first one.
One thing shapes everything you see in there: a single run leaves you two lines, not one. `Download` is the trip to your supplier's file. `Mapping` is the writing into your catalog. They can fail separately, so you get them counted separately, and a dropdown at the top of the dialog is how you move between them.
## Before you start
### What your role lets you do
Sync history is inside the `Data Sources` tab, and that tab is Manager and above. If you are an Admin or a Manager you can open the history of any source, download the file a run read, and download its row-by-row report.
An Editor does not see the tab at all, so there is nothing here to open. You set roles in [team, roles and permissions](/team#what-each-pim-role-can-do).
### The detail behind a run does not last
A run's row-by-row report and the saved copy of your supplier's file last 30 days. The run's own line and its counters stay. After that the two buttons stop working instead of giving you an empty file.
So a report you might need later is one you download while it is still there. Once you have downloaded a report it keeps working for you after that, which the section on it explains.
## How to read a run
From `Uploads`, select the `Data Sources` tab and find your source in the table. Click `History` in the `Actions` column at the right end of its row.
The dropdown next to the dialog title says `Download` or `Mapping`. Leave it on `Download` to see what arrived from your supplier. Switch it to `Mapping` to see what got into your catalog.
Your runs are listed newest first, and the `Started` column says how long ago each one began. Click a column header to sort by that column instead.
The `Status` column says how that phase ended. Every column after it counts rows. Hover a column header and a short line tells you what that column counts.
On a `Mapping` line, click `Results` in the `Actions` column for a report with one row per record. On a `Download` line, click `Download file` for the file your supplier sent.
That is the whole screen. A `Completed` status, with numbers in the columns you expected, is a run that went fine and you can close the dialog.
Everything below explains the two phases, every counter on each of them, and the two downloads. You do not need any of it to see whether your run worked.
## Every option in detail
### The two lines every run leaves
You get one line per phase because the two phases can fail separately. `Download` goes out to your supplier, reads the file, and stores its rows. `Mapping` takes those stored rows, finds the record in your catalog each one is about, and writes your values into it.
The order between them is fixed, which is why you sometimes get only one line. You only ever get a mapping line because a download line put rows in front of it.
| What happened | What you see |
| --- | --- |
| Your download failed | One download line, and no mapping line at all |
| Your download worked | Two lines, one on each side of the dropdown |
| Your download worked and the file had nothing new | Two lines, and the mapping line's per-run counters are dashes |
That last row is what a healthy quiet feed looks like, and it is worth knowing before you go looking for a problem. Nothing changed, so nothing was counted for you.
### Switching between the two phases
The dropdown is next to the dialog title, at the top of the dialog. `Download` and `Mapping` are its two choices, and each one gives you its own table with its own columns.
Each side also keeps your sorting, your filtering and your page separately. A filter you set on `Download` does not follow you across to `Mapping`, so switching sides never hides rows you did not mean to hide.
The phase is part of the page address behind the dialog. Copy that address while you are looking at `Mapping` and whoever you send it to opens on `Mapping` too.
### The three columns both sides share
Whichever phase your dropdown is on, your table opens with the same three columns.
| Column | What it shows you |
| --- | --- |
| `Status` | How that phase ended |
| `Started` | How long ago the phase began, written as `2m ago` or `3d ago` |
| `Duration` | How long it took, written as `35.8s`, `2m 15s` or `1h 4m`. Empty while your run is going |
Every other column on either side counts rows, and the two sides count different things.
You see a dash instead of a zero in all of those counting columns. So a cell with a number in it is always something that really happened to your rows. A line of dashes is a quiet run and not a broken one.
### What the download counters count
On the `Download` side of the dropdown, these five columns count rows in your supplier's file. Nothing on this side has looked at your catalog yet.
| Column | What it counts |
| --- | --- |
| `File Rows` | Rows your file had this time |
| `New` | Rows with something this source had never seen before |
| `Updated` | Rows it had seen before whose contents changed |
| `Unchanged` | Rows identical to the ones in your previous download |
| `Removed` | Products that were in your previous download and did not arrive in this one |
You get `Removed` once, on the run where those rows stopped arriving, and then it goes back to nothing. A source that lost 400 of your rows last week shows you nothing today. What happens to the products themselves is in [data sources](/pim/uploads/data-sources).
**There is no `Errors` column on this side.** A download either worked or it did not. When it did not, you get the reason as a sentence on the `Status` badge instead of a number in a column. Errors on single rows are counted for you on the other side.
### What the mapping counters count
On the `Mapping` side, two of the columns are running totals and everything else is only about this run. That is the most misread thing on the screen, so it is worth reading twice. `Matched` and `Unmatched` tell you how much of your feed has a record in your catalog today, counted across every run there has ever been. Neither of them describes the work this run did.
`Matched` and `Unmatched` are where your whole feed stands right now. Every other column on this side counts only what this one run did.
| Column | What it counts |
| --- | --- |
| `Matched` | Rows of your feed that have a record in your catalog right now |
| `Unmatched` | Rows of your feed that have none right now |
| `Newly Matched` | Rows that gained a record in this run, including a row now pointing at a different one |
| `Lost` | Rows that had a record and no longer do |
| `Success` | Matched rows this run wrote cleanly |
| `Not Matched` | Rows this run looked at that found nothing to write into |
| `Warnings` | Matched rows this run wrote with a warning alongside |
| `Errors` | Matched rows this run failed to write |
**`Lost` is the column to watch.** Rows that pointed at one of your products no longer do. Those products have stopped getting this supplier's numbers, and nothing else on this screen will tell you that.
**A run with warnings and no errors is `Completed`, not `Partial`.** A warning means your write went through and one part of the row could not be used, like a brand name your catalog does not have. Your record still got everything else in that row.
### Sorting, filtering and searching the runs
Four text buttons are above the table. They work the same for you on both sides.
| Button | What it does for you |
| --- | --- |
| `Search` | Type `fail`, `part`, `comp` or `run` to keep only runs with that status. It looks at nothing else |
| `Filter` | Opens a panel where you build a condition on any column |
| `Columns` | Hides and shows columns |
| `Density` | Makes your rows taller or shorter |
You can sort and filter on every column, and clicking a column header sorts by it. On a counting column your condition takes a number. Set `Errors` to `greater than (>)` and `0` and you keep every run that failed a row. Set it to `equals (=)` and `0` instead and you get the runs that failed none, which is what the dash in that column stands for.
The `Status` condition is a dropdown, and it lists only the statuses this source has actually had. A short list is normal and does not mean you are missing anything.
You get 50 runs at a time, and the footer under the table gives you 25 or 100 instead.
Drag a column header sideways to reorder your columns, and drag the edge of a header to make a column wider. What you set, along with which columns `Columns` is showing and what `Density` is on, comes back the next time you open sync history on the computer you are using.
`Download` and `Mapping` remember separately, because the two sides give you different columns. None of it changes what anyone else on your team sees.
### Downloading the file a run read
`Download file`, in the `Actions` column of a `Download` line, gives back your supplier's file exactly as that run received it. There is no format for you to pick, because it is the file your supplier sent.
Your file arrives named after the moment the run started, like `feed_2026-08-04-14-30-05.csv`. Open it when a run counted something you did not expect and you want to see what actually turned up.
Two cases leave the button inactive, and hovering it tells you which one you are in. While the run is still going there is nothing to hand you yet. More than 30 days after the run your saved copy is gone, and the message points you at `Run now` on the source's row to fetch a fresh file.
### Asking for the row-by-row report
`Results`, in the `Actions` column of a `Mapping` line, builds you a report with one row per record that run looked at. It is the only place a run explains itself record by record. Open it when a counter tells you something failed and you need to know which of your rows it was.
Clicking it opens a small dialog called `Select file format` with two cards, `CSV` and `Excel`. Pick one and your report starts building.
Building takes a moment and the dialog says so. You can close it: closing cancels nothing, and your download starts on its own when the report is ready. If it takes longer than 2 minutes you get a message asking you to try again shortly. Your report keeps building in the meantime, so clicking `Results` again a little later usually gives it to you at once.
**A report you have already asked for is kept.** It is built once and stored, so asking again gives you the same file with no wait. So a report you pulled inside the 30 days keeps downloading for you long after the detail behind it has gone.
The button is inactive on a run that is still going, and on a run that looked at no records at all. Hovering it tells you which.
### Limits
| What | Limit |
| --- | --- |
| Rows in a `Results` report | 50,000 |
| How long the row-by-row detail lasts | 30 days |
| How long the saved copy of your file lasts | 30 days |
| How long a run's own line lasts | No limit |
| Runs shown at a time | 50 |
| Wait before the report tells you to try again | 2 minutes |
| Time without progress before a run is closed | 30 minutes |
### What sync history cannot do
| You cannot | Do this instead |
| --- | --- |
| Undo a run, or put your catalog back to how it was before one | Fix the values yourself, or through an [import](/pim/uploads/imports) |
| See what a run would change to your catalog before it runs | Run it and read its line here |
| Stop a run that is already going | Wait for it, and `Pause` the source so the next one does not start |
| Delete one run's line, or clear a source's history | Deleting the source takes its history with it |
| Get an email when a run finishes with rows that failed | Open this screen. Email covers whole-file failures only |
| Read every source's history in one place | Open `History` on one of your sources at a time |
| Download the report for a run older than 30 days | Click `Run now` on the source and read your new run |
## What the numbers are telling you
### Why the counters do not add up to your file
On the `Download` side, you get `New`, `Updated` and `Unchanged` adding up to `File Rows` only when your supplier's file repeated nothing and every row saved.
Two rows with the same values in every column this source reads count as one row, and the later of the two is the one kept. So a file that spreads one of your products across several rows shows you a gap on a run that went perfectly.
`Removed` stays outside that sum, so never add it in. It counts products that stopped arriving, not rows that did.
The other reason for a gap is rows that failed to save. That one turns your run `Partial`.
### Why a settled feed shows almost nothing
Every run walks every row that has a record in your catalog, not only the rows that changed. Your counters, though, only count the rows the run had something to say about.
A row whose values still agree with your catalog, and whose last outcome matched this one, is checked and then left out of your counts completely. It is left out of your `Results` report too. So a settled feed of 60,000 rows shows you a handful of numbers, and that is your feed working rather than your feed stopping. What each run checks is in [data sources](/pim/uploads/data-sources).
### When a success hides a dropped field
When a row matches one specific variant of a product that has several, the fields the whole product shares are dropped. Only the variant's own values go in, nothing raises an error, and the row counts under `Success`.
Knowing why lets you work out the next case yourself. One variant's row would otherwise rewrite your shared product on behalf of all its siblings. A row about your red small shirt would be setting the title, the description and the categories for your blue large one too.
`Title`, `Slug`, `Status`, `Description` and `Features` go. So do `Condition`, `Product Type`, `Brands`, `Categories`, `Shopify Category` and `Tags`. And so do `Specifications`, `Information Sources`, `Internal Notes`, `Meta Title`, `Meta Description` and `Resource URLs`.
Everything else in your row is the variant's and goes in normally: its price, its cost, its stock, its measurements and its barcodes.
Images are the exception. `Primary Image URL` and `Gallery Image URLs` go to the variant that matched instead of being dropped. A blank cell there wipes the images of that one [variant](/pim/catalog/variants) and of no one else.
So a feed you mean to own a product's shared fields has to match at product level, on `Slug` or `Title`. A feed matching on a SKU or a barcode is a per-variant feed whatever else you put in its columns, and [data sources](/pim/uploads/data-sources) covers which of your rules match which way.
### What is inside the Results file
The report `Results` builds you, from a `Mapping` line, has one row per record that run looked at. Its columns are built out of the run itself, and they come out in this order.
| Column | What it shows |
| --- | --- |
| `record_id` | The stored row this line came from |
| Your match columns | The columns your rules read, with the values the run saw |
| Your value columns | The columns feeding your catalog fields, with the values the run saw |
| `matched_entity_type` and `matched_entity_handle` | What it matched, and which one |
| `match` | How the link changed: `new`, `existing`, `lost` or `none` |
| `result` | `success`, `warning`, `error` or `not_matched` |
| `message` | Every warning and error for that row, run together |
**Your own match columns are the reason to open this file** on a row that found nothing. The screen tells you a row did not match. Your file shows you the value the run actually compared, which is usually your answer. A SKU with a space in it, an empty cell, a code your supplier changed without telling you.
**`match` and `result` answer two different questions**, and reading them together is what makes your file worth opening. A row can be `existing` and `error`, so it kept its record and your write failed. A row can be `new` and `success`, which is your normal good case.
The screen's `Not Matched` count and its `Lost` count both appear in your file as a `result` of `not_matched`. The `match` column is what separates them for you.
Your report's own column names are always in English, and so are the values in `match` and `result`. Your own columns keep the names your supplier's file gave them.
## When something goes wrong
### What each status means
The `Status` column is the first one on both sides, and it has one of four words in it.
| Status | What it means |
| --- | --- |
| `Running` | The phase is still going |
| `Completed` | It finished with nothing wrong |
| `Partial` | It finished, and some of it did not work |
| `Failed` | It finished and none of it worked |
What separates `Partial` from `Failed` is whether anything at all got through. On the download side, whether any of your rows were stored. On the mapping side, whether any of your records were written. Nothing at all is `Failed`.
**`Partial` is a healthy run.** Your file arrived and the machinery worked, and some rows inside it did not. It does not count toward your source switching itself off, which [data sources](/pim/uploads/data-sources) covers from the health side.
### Finding out why a run failed
Hover the `Status` badge on a `Failed` line and a sentence tells you why. That sentence is your whole explanation, and there is no second place to look for it.
| What the message tells you | What to do |
| --- | --- |
| It could not connect, or the server took too long to answer | Check the host, the port and whether the server is up. A timeout is retried on your next run on its own |
| It could not sign in to the server | Check the username and password on your source |
| Your file was not found, or access to it was rejected | Check the path or the link. A link that asks for a login of its own will not work here |
| Your file downloaded and it was empty, or it could not be read | Ask your supplier what they sent. A data source reads CSV and XLSX |
| Your file is bigger than the limit | Ask for a smaller file, or split it. [Data sources](/pim/uploads/data-sources) has the number |
| Your source is missing part of its setup | Open the source and finish it: the link, the host, the username, the match rules or the field mappings |
| Your file's columns no longer match the setup | Reopen the source and pick the new column for each field marked in red, which [data sources](/pim/uploads/data-sources#when-the-file’s-columns-change) covers |
| Something went wrong on our side | Nothing for you to fix. Your next run tries again |
### When a run never finishes
A line does not stay on `Running` forever. A phase that stops moving for 30 minutes is closed as `Failed` for you, with a message on the chip saying it made no progress. Your source is started again by its next scheduled run.
That matters more than it sounds, because `Run now` on the source's row is inactive while a run is going. A run that died halfway would otherwise keep your button disabled until you noticed.
### When Results or Download file will not work
Both buttons are in the `Actions` column at the right end of a line, and both of them go quiet on you in more than one case.
| What you clicked | What you get | Why |
| --- | --- | --- |
| `Results` on a line that is still running | An inactive button | Your report needs the finished outcome of every record |
| `Results` on a run that looked at no records | An inactive button | There is nothing to put in a report |
| `Results` more than 30 days after the run | `Detailed results for this sync are no longer available. Per-record results are kept for 30 days.` | Unless you downloaded that report once already |
| `Download file` on a download that is still running | An inactive button | Your file is stored when the phase finishes |
| `Download file` more than 30 days after the run | An inactive button pointing you at `Run now` | Your saved copy is gone |
### Two things that happen with no message
Nothing on screen tells you about either of these, so they are worth knowing about.
Your `Results` report stops at 50,000 rows. A run that looked at more of your records than that gives you the first 50,000 and no note saying it stopped.
And a row that matched one variant of a product with several variants loses the product's shared fields, and still counts under `Success` for you.
## Where to go next
The setup behind these runs, and what a blank cell does to your catalog.
Which source decides a field when two of them send it.
Why a per-variant match cannot write the fields a product shares.
The values a match rule compares, and what makes one ambiguous.