Set up tracking with Dynamic Reporting
VeraCore does not push tracking numbers to SKU.io. There is no webhook and no "give me the tracking for this order" endpoint. What VeraCore has is Dynamic Reporting — you define a report, ask VeraCore to run it, wait, and collect the result.
So that is what SKU.io does. Every tracking update is a report run, and the Report Tasks tab is the log of those runs.
Understanding this tab is the difference between "tracking is broken" and "the report ran fine, but four of its rows never matched an order". They look identical from the Orders tab.
How a report task works
A report task moves through a fixed sequence:
| Status | Means |
|---|---|
| Created | SKU.io has asked VeraCore to run the report. Nothing has come back |
| Polling | VeraCore accepted the request and SKU.io is waiting for it to finish |
| Done | The report finished and its rows are in SKU.io |
| Processed | Those rows have been applied — tracking numbers written onto orders |
| Failed | Something went wrong. The reason is on the task |
| Superseded | A newer task replaced this one |
Created → Polling → Done → Processed is the whole happy path. The other two are exits.
Retrying does not move a task forward — it creates a new task and marks this one Superseded. That is why Superseded has no route back.
Report tasks are created for you. You do not schedule them by hand:
VeraCore report tasks are created automatically when an inventory or order sync runs.
If the tab is empty, no sync has run yet — not that tracking is misconfigured.
Why polling exists at all
VeraCore runs the report asynchronously. It returns a task id immediately and finishes the work later — seconds for a small window, considerably longer for a busy one.
SKU.io waits inline for about two minutes, checking every ten seconds. If the report is still running after that, the task stays in Polling and a background job picks it up, up to twenty attempts in total before it gives up and fails.
That is why a task can sit in Polling for a while and still be perfectly healthy. A task still polling after several hours is not.
The date window
Each task covers a date range, shown as Date Range in the table and Covers {start} → {end} on the task itself.
Three things about that window are worth knowing:
- It overlaps the previous one by a day. Consecutive windows deliberately share a day so a shipment recorded right on a boundary is not missed by both.
- The first run looks back three days. A brand-new connection picks up recent shipments rather than starting from nothing.
- It never looks back more than seven days. If tracking has not run for a fortnight, the gap in the middle will not be filled by simply running it again.
That last point matters after an outage. A connection that has been down for a week or more needs its missing tracking chased another way — the window will not stretch to cover it.
A VeraCore Dynamic Report returns roughly nine hundred rows. A window busy enough to exceed that will be truncated, which is another reason the windows are kept short. If you ship at high volume, more frequent syncs are better than bigger ones.
The task list
| Column | Notes |
|---|---|
| ID | SKU.io's row id. Opens the task |
| Report Name | Which VeraCore report was run |
| Status | The chip described above |
| Date Range | The window the report covers, e.g. Jul 24 → Jul 31 |
| Rows Matched | How many rows matched an order when the task was processed. — until then |
| Poll Attempts | How many times SKU.io has asked VeraCore whether it is finished |
| Created At | When the task was raised |
Search covers report name, VeraCore task id, and the SKU.io id. The Status quick filter carries the seven values above, and the advanced filters add report name plus date ranges on creation and processing.
Clicking anywhere on a row opens the task.
Retry appears on the row only when the task has failed — there is nothing to retry on one that is polling or already processed. It confirms with Report task retry queued.
When there is nothing to show, the page tells you which of the two situations you are in: No report tasks match your filters with a Clear Filters button, or No report tasks yet with the note that tasks are created automatically by a sync.
Reading a task
Open a task and the first thing to look at is not the status — it is Where the rows went.
A task can be Processed, entirely successfully, and still have left half its rows without tracking. The status describes the report; the funnel describes the outcome.
The four figures
| Card | Means |
|---|---|
| Rows returned | How many rows VeraCore gave back for this window |
| Matched when it ran | How many matched an order at processing time, with the timestamp |
| Tracked now | How many of those orders carry a tracking number today |
| Needs attention | Untracked, unmirrored or unusable rows |
Matched when it ran and Tracked now are different numbers on purpose, and the funnel says why:
Recomputed now, not when the job ran — a row VeraCore reported days ago may have picked up tracking since.
A row that failed to match a week ago may match perfectly well today, because the order has since been synced. Recomputing means an old task tells you the truth about now rather than a frozen snapshot of a problem that has already resolved itself.
Every card except Matched when it ran is clickable and filters the row table beneath.
The five outcome buckets
| Bucket | Means | Do something? |
|---|---|---|
| Tracked | The order carries tracking now | No |
| Tracking not applied | The report had a number, the order has none | Yes |
| Blank tracking in report | Matched an order, but VeraCore sent no number | No |
| No SKU.io order | Never mirrored from VeraCore | Yes |
| Unusable row | VeraCore returned no Order ID | Yes |
Needs attention is the sum of the three marked yes. Blank tracking in report is deliberately excluded from it — VeraCore simply had no number to give, which is information, not a task. Most commonly it means the order has not shipped yet.
Each bucket in turn:
Tracking not applied is the real failure. VeraCore reported a tracking number, SKU.io found the order, and the number is still not on it. Open the row, compare Tracking In Report against Tracking On Order, and look at the order itself.
No SKU.io order means the report mentions an order SKU.io has never seen. Run Refresh From VeraCore on the Orders tab and reopen the task — because the funnel recomputes, these often clear themselves once the order exists.
Unusable row is a row VeraCore returned with no Order ID at all. There is nothing to match it against. A handful is noise; a lot of them suggests the report definition itself is returning the wrong columns, which is a conversation with your 3PL.
The rows
| Column | Notes |
|---|---|
| Order ID | VeraCore's order id. A link when SKU.io mirrored the order |
| Outcome | Which bucket the row landed in |
| Tracking In Report | What VeraCore said |
| Tracking On Order | What SKU.io holds — or a No tracking (by design) chip |
| Carrier / Service | As reported |
| Shipped At | When VeraCore recorded the shipment |
| Freight | The shipping cost on that row |
Those middle two columns side by side are the whole diagnosis. If Tracking In Report has a number and Tracking On Order is empty, the application failed. If both are empty, VeraCore never had one. If they differ, something re-wrote the order after the report ran.
No tracking (by design) is not a failure — it is an order explicitly flagged as one that will never carry tracking, and it counts as Tracked.
Search the rows by order or tracking number, and note that the empty states distinguish an empty report (VeraCore returned no rows — The report completed with an empty result set — nothing shipped in this date range, or the filter matched nothing.) from an empty bucket (Pick another outcome on the left to see the rows that landed there.).
The raw payload
Raw payload from VeraCore loads on demand and shows exactly what came back, with Copy JSON. Use it when a row's outcome makes no sense and you need to know whether VeraCore sent something odd or SKU.io read it wrong. If VeraCore returned nothing at all: VeraCore returned no payload for this task.
When a task fails
A failed task carries its reason in a red banner at the top. Retry Report is enabled only on a failed task — on any other status the button explains itself on hover: Only a failed report can be retried — this one is {status}.
Retrying does not re-run the same task. It creates a new one covering the same window and marks the old one Superseded, and SKU.io follows you to the new task rather than leaving you looking at history.
That is why Superseded exists as a status. A superseded task is not an error and not a duplicate — it is the attempt that a later task replaced.
Common failure causes:
| Cause | Fix |
|---|---|
| The report name does not exist in VeraCore | Check the tracking settings against the report as your 3PL defined it |
| Credentials rejected | See Connect VeraCore |
| VeraCore never finished the report | Retry. A window that repeatedly times out is too large — shorten the sync interval |
| Rejected report parameters | Usually the date format or a filter name. The raw payload will show what was sent |
Configuring it
The report itself is defined in VeraCore, by your 3PL, not in SKU.io. SKU.io only needs to know which report to run and how to read it — configured on the Settings tab under Tracking, covered in the settings reference.
If tracking has never worked at all — every task failing, or no tasks ever created — the problem is almost always there rather than in the pipeline itself.
A quick diagnosis
An order has no tracking. Where do you look?
- Report Tasks — is there a recent task covering the ship date? No task means no sync has run in that window.
- The task's status — failed? Read the banner. Still polling after hours? Retry it.
- Where the rows went — is Needs attention above zero?
- The rows — find the order. Which bucket did it land in?
- Then follow that bucket's fix above.
The one answer this rules out quickly is "tracking is broken". Usually it is not; usually one row of one report did not match.
Next steps
- Sync and link orders — where the tracking numbers end up, and how orders get mirrored in the first place.
- Map shipping methods — the carrier and service that appear on these rows.
- Troubleshooting — when the pipeline is healthy but the numbers still are not arriving.