Skip to main content

Why does my Imweb order count include cancelled and returned orders as separate rows?

Adriel keeps cancellation and return activity as its own records instead of rewriting the original order. This preserves the timing of both the sale and the later cancellation, so an order that is later cancelled or returned still shows its original purchase alongside a distinct cancel or return row. Only completed cancellations and returns generate these extra records. Pending cancel or return requests do not. Each extra record carries a suffixed order ID (for example, 12345:cancel1 or 12345:return1), so widgets that count raw rows may show more entries than the number of original purchases. To report on genuine order volume, use the Order Count metric, which counts distinct orders. To trace the full lifecycle of a single order, filter the order ID with a “contains” (LIKE) match rather than an exact match, so the original row and its cancel or return rows are grouped together.

Why is my Imweb tax always zero?

Order Tax Amount is always 0 for Imweb. The Imweb Open API does not return tax at the order level, so there is no source value for Adriel to report. This is a platform limitation, not a sync error. Order revenue is still complete: item price, discounts, and shipping are all reconstructed from the raw order, and Order Payment Amount reflects the amount actually charged. Only the tax field is unavailable.

Can I report on Imweb orders older than 90 days?

Imweb limits how far back order history can be retrieved. Adriel imports up to 90 days of orders when the data source is first connected, and orders older than that 90-day window cannot be back-filled afterward. Because Adriel caches the data, the longer the data source stays connected, the more history accumulates going forward, so coverage grows steadily beyond the initial 90 days from the connection date onward. Products are handled separately from this limit: the product catalog is refreshed as a full snapshot rather than a rolling historical window.

Why are all my Imweb amounts shown in KRW?

Imweb is a Korean e-commerce platform, and the connector reports order and product values in Korean won (KRW) by default. Product prices are always stored in KRW, and an order that omits its currency falls back to KRW as well. If the workspace uses a different base currency, Adriel’s e-commerce layer applies conversion rates so Imweb figures aggregate correctly with other data sources. The Order Currency breakdown shows the currency each order was placed in.

Why don’t my Imweb totals exactly match the Imweb admin?

Imweb does not expose its own analytics figures, so sales performance is reconstructed from the raw orders and products the API provides. A few known differences can make Adriel totals differ slightly from the Imweb admin view:
  • Tax is not represented, because the API does not provide order-level tax.
  • Shipping refunds are not reflected on cancellation and return records, so a refunded delivery charge is not subtracted.
  • The most recent day may not yet be included, and newly made changes appear on the next sync rather than immediately. See the data reference for the sync schedule.
If a figure still looks wrong after accounting for the above, email support@adriel.com with the affected dashboard URL and the Imweb order numbers in question.

How to connect Imweb

Connect an Imweb store to Adriel over OAuth.

Imweb data reference

Metrics, breakdowns, refresh cadence, and limits for Imweb.

Cafe24 FAQs

Common questions for the Cafe24 Korean commerce data source.

Shopify FAQs

Common questions for the Shopify commerce data source.