Product sources
Connect the place your products come from, choose how often we read it, and decide what should happen to your products if it ever stops answering.
The sources table
Brand → (your brand) → Products → Sources lists every catalogue feeding this brand.
| Column | What it tells you |
|---|---|
| Name | The source name, with its address underneath. A push-only API source shows its push address instead. |
| Type | CSV feed or Product API. |
| Status | See the badges below. |
| Refresh | "Every day", "Every 3 days", "Push only", or "Stopped after 3 failures". |
| Last successful fetch or push | The date of the last successful read. A push-only source shows "Pushed …" with the date your shop last sent us changes, instead of "Never". |
| Products | How many base products this source currently holds. Versions are not counted here. |
Status badges
| Badge | Meaning |
|---|---|
| PENDING | Created, but nothing has been read from it yet. A push-only source leaves this state as soon as your shop's first push succeeds. |
| PROCESSING | A read or a push is running right now. |
| ACTIVE | The last read succeeded. |
| WARNING | The last attempt failed. We keep retrying every hour. |
| INACTIVE | Stopped after three failures in a row. |
Hover the information icon beside a badge for the plain-English reason, including the raw error when there is one.
Adding a source
Press Add source. The first choice is the source type, and it is the one thing you cannot change later.
Fields for every source
https://; a CSV feed may use plain http. Leave it empty on a Product API source to make it push-only: the schedule switch turns itself off and cannot be switched on, no first read is started, and the source simply waits for your shop to send it products.Extra fields for a Product API source
Signature header on every read, so your shop can check the request really came from Yaplet. The secret itself never travels.Signature, Host or Content-Length.Fields that become keys
This is the setting that connects your catalogue to your product rules.
A rule applies to a product when the two share a key. A product gets its keys from two places: the rule_keys list your shop sends with it, and the values of any product fields you name here.
So if your shop sends an Ingredients field and you add Ingredients to this box, every ingredient becomes a key on that product — and any rule carrying that ingredient's name applies to it automatically.
Changing this setting re-derives the keys of every product of that source immediately. There is no refresh to wait for and nothing is re-read.
If the source keeps failing
This choice only takes effect once reading has stopped after three failures in a row.
Products you switched off by hand are never switched back on by this.
What happens when a read fails
Within a single read we try three times — 30 seconds each, waiting 5 then 15 seconds between attempts — but only when the problem looks temporary (a timeout, a network error, or a server error on your side). A rejection like "not found" or "forbidden" fails at once.
Then:
| What happens | |
|---|---|
| 1st and 2nd failure in a row | Status WARNING. We keep retrying every hour. Nobody is told. |
| 3rd failure in a row | Status INACTIVE. Scheduled reading stops. Your organisation's owner gets a notification and an email. |
Two things deliberately do not count as strikes: a Fetch now you ran yourself (it only sets WARNING, and nobody is emailed), and a failed push from your shop (it shows in the run report only).
The email you get
One email per organisation per hour, however many sources are involved — it cannot nag you. It tells you what happened, why, how to fix it, and what happens if you do nothing, with a button straight to this page.
Fetch now
The circular-arrow button reads the source immediately, in the background.
- There is a five-minute cooldown per source. Inside it, the button tells you how long is left.
- It is also how you restart a stopped source: a successful manual read clears the strikes, sets the source back to ACTIVE, and brings back any products that were hidden.
The last run report
The chart icon opens the report for the most recent run. Only the latest run is kept for each source — read it before you trigger the next one.
It shows whether the run was scheduled, manual or a push; whether it was a full snapshot or only changes; and a grid of counters.
The ones worth knowing:
| Counter | What it means |
|---|---|
| Items received / Items used | How many products arrived, and how many survived validation. |
| Products added / updated / unchanged / removed | What changed at the base-product level. |
| Versions stored / Versions removed | The same, for versions. On a healthy run this is at least as large as the product count. |
| Search card pieces indexed | How much searchable text the AI re-read. A product becomes one to a few pieces depending on how much it carries. |
| Overview pages rewritten | The catalogue pages that were rebuilt — one for the catalogue as a whole, plus one per category. |
| Skipped as invalid | Items that were left out. The reasons are listed underneath. |
| Versions that stopped a product | A version that failed validation takes its whole product out of the run, so this being non-zero explains a missing product. |
| Product prices ignored (versions sent) | You sent a price on the product and versions underneath it. The versions win and the product-level price is ignored — see the Product API reference. |
| Search terms cut for length | A product sent more search terms than one product may carry; the rest were dropped. |
Below that, up to three lists:
- Skipped items — which items were left out and why (the first 50).
- Products cut for length — products that sent more keys or more search terms than one product may carry.
- Fields the shop sent — every field name seen in this run. This is the same list the "fields that become keys" chips come from.
Row actions
Fetch now, Last run report, Edit, Delete — plus two more on Product API sources: Copy push URL, and a shortcut to the API tab with that source already selected, so the code samples carry its real address.
Limits worth knowing
| Limit | Value | What you see if you hit it |
|---|---|---|
| Products per source | 20,000 | The read fails and asks you to split the catalogue across several sources |
| Products per organisation | 20,000 | The read fails; write to support to have it raised |
| Versions per organisation | 100,000 | The read fails, naming the number it would have reached |
| Versions per product | 500 | The product is skipped as invalid |
| Sources per organisation | 100 | Saving the source fails |
| Response size | 50 MB | "The response is larger than 50 MB" |
| Read timeout | 30 seconds per attempt | "The request timed out after 30 seconds" |
| Extra headers | 20 per source | The Add header button stops |
| Fields that become keys | 20 per source | The box stops accepting more |
| Keys per product | 500 | Counted as "Keys cut for length" in the report |
| Search terms per product | 100 words, versions included | Counted as "Search terms cut for length" in the report |
| Category depth | 6 levels, 100 characters each | The item is skipped as invalid |
| Description per product | 20,000 characters | The item is skipped as invalid |
Smaller limits while nobody is paying
An organisation with no active subscription and no credit balance gets deliberately smaller feed limits, because it could never store a catalogue that size anyway:
| Limit | While nobody is billed | On a paid plan or with credits |
|---|---|---|
| Response or push size | 5 MB | 50 MB read / 25 MB push |
| Products in one read or push | 1,000 | 20,000 |
| Pushes per minute | 6 | 60 |
Adding credits or starting a subscription lifts these immediately — there is nothing to switch on and nothing to wait for.