Creating vs updating products at VeraCore
The Offer catalogue flows into SKU.io and is read-only there. Pushing products is the one place the traffic runs the other way: you send a SKU.io product up to VeraCore so the warehouse has an item to receive against, pick, and report stock for.
It is a small feature with one genuinely sharp edge, so it is worth understanding before you use it.
The sharp edge: create replaces, update patches
VeraCore's product endpoint has an asymmetry that is easy to get backwards:
| Call | Behaviour |
|---|---|
| Create | Replaces the whole record. Every field not in the payload is wiped. |
| Update | Patches only the fields sent. Everything else is left alone. |
Read that first row again. A create against an item that already exists is not rejected and is not merged — it overwrites, and anything your 3PL configured at their end and SKU.io does not send (dimensions, warehouse activation, units of measure, packaging) is silently gone. There is no confirmation and no undo.
SKU.io picks the call for you, per product, every time. Anything already mirrored in the Products tab goes through the update path unconditionally. You cannot force a create over an existing item from the UI, and that is deliberate — the destructive call is not exposed.
How SKU.io decides
Before pushing, SKU.io builds the set of VeraCore item codes it already knows about from the mirrored catalogue, and checks each SKU against it. Match → update. No match → create.
The comparison ignores case and surrounding whitespace, but not punctuation — SKU-1 and SKU_1 are treated as different items here.
That is stricter than the match ladder, which does collapse punctuation, and the difference is intentional. If the check is too loose, a near-miss turns into a destructive overwrite of the wrong record. If it is too strict, the worst case is a spare item created at VeraCore that you can clean up. Given one of those two mistakes has to be possible, this is the one to choose.
The practical consequence: sync the catalogue before pushing. The existence check reads the mirror, so a stale mirror is what makes a push behave unexpectedly.
What actually gets sent
SKU.io deliberately sends very little. It owns the identity of a product; your 3PL owns how that product is handled in their building.
On create:
| Field | Value |
|---|---|
| Product ID | The SKU.io SKU |
| Product Title | The product name, or the SKU if it has no name |
| Lot tracked | Always false |
| Build type | Kit for kit products, Standard for everything else |
On update:
| Field | Value |
|---|---|
| Product ID | The SKU.io SKU |
| Product Title | The product name, or the SKU if it has no name |
Nothing else. Dimensions, weights, warehouse activation, and packaging rules stay under your 3PL's control — pushing a product later never disturbs configuration they have done.
A pushed product exists at VeraCore, but your 3PL may still need to activate it in a facility or set up handling before it can be received or picked. Pushing is the first step of that conversation, not the whole of it.
The two limits
VeraCore constrains two fields, and SKU.io handles them differently on purpose.
Product code — 50 characters, hard stop
SKU longer than 50 characters cannot be represented at VeraCore. Rather than truncate — which would create an item under a code that is not your SKU, quietly breaking every future match — the whole push is refused before anything is sent, with an error naming the offending SKUs:
VeraCore product codes are limited to 50 characters. Shorten these SKUs before pushing:
<the SKUs>
Nothing is pushed at all, not even the valid rows. Shorten the SKUs and run it again.
Product title — 255 characters, truncated
Titles are descriptive, not identifying, so an over-long name is simply cut to 255 characters and the push proceeds. Nothing fails and nothing is blocked.
The asymmetry is the point: truncating an identifier is dangerous, truncating a description is not.
What you get back
A push reports three numbers:
| Result | Meaning |
|---|---|
| Created | Items that did not exist at VeraCore and now do |
| Updated | Items that already existed and had their title patched |
| Failed | Items VeraCore rejected, each with the reason |
Failures are per product. One rejected item does not stop the rest of the batch — the run continues and reports what went wrong at the end, so a single bad row never costs you the other 499. Fix the listed items and push those again; the ones that succeeded are already updates, so re-pushing them is safe.
When to push, and when not to
Push when you have added products in SKU.io that your 3PL needs to stock — most often just before announcing the purchase order that will deliver them.
Do not push your entire catalogue by reflex. VeraCore is a warehouse system; items you never send to that warehouse only add noise to your 3PL's item list, and every one of them becomes another offer to mirror and map.
For the step-by-step, see Push products to VeraCore.