Introduction
Imweb (아임웹) is a Korean website builder and e-commerce platform for online stores. The connector reads a store’s orders and products from the Imweb Open API using OAuth 2.0, then reconstructs order-level revenue and product catalog data for dashboards. The default reporting currency is KRW. As an e-commerce connector, order, revenue, and product breakdowns are standardized so widgets can aggregate alongside ad-platform sources without additional configuration. Because e-commerce platforms do not expose their own analytics figures directly, sales performance is reconstructed from raw orders and products; if a figure looks off against the Imweb admin, Adriel support can investigate. To connect this data source, see How to connect Imweb to Adriel.Data refresh strategy
Architecture data
Architecture covers products. The catalog is fully refreshed once per day, scoped to the selected Imweb website unit. Each product becomes a separate record; the snapshot includes product name, price, original (retail) price, SKU, primary image, status, and created / updated timestamps. Product currency is fixed to KRW.Reports data
Reports include order-level financial and status data. Refresh schedule. Orders sync once per day (the connector runs daily, not hourly). At every refresh, orders created or modified in the last 1 day are pulled, and today’s orders are not included in the sync window. Order pages are fetched 100 records at a time and iterated to completion. Historical window. Up to 90 days of historical orders can be back-filled (maxFromDate = 90 days ago). Data older than 90 days cannot be retrieved through this connector.
Timezone. Order fetch windows are computed as start-of-day to end-of-day in the data source’s configured timezone (default Asia/Seoul), which the user selects at setup time.
Cancellations and returns become separate records. To keep order and cancellation timing accurate, the original order record is never overwritten with cancellation detail. Instead, a distinct “cancelled” or “returned” record is created carrying only that information. When retrieving the full history of an order, filter on the order ID with a LIKE (contains) match rather than an exact match, because cancel and return records use suffixed IDs (for example
{orderNo}:cancel1, {orderNo}:return1).Architecture levels
Store (Imweb website unit) → Product, and Order → Order section (line items). Each Imweb website unit becomes a separate Adriel data source, and products are scoped to that unit. Each order can produce a regular record plus one additional record per completed cancellation or return section.Date range limits
Metrics
How to read the columnsThe Data type column uses this vocabulary: Number, Currency, Percentage, Ratio, Duration, Date, Text, URL, Array, Boolean.The API Key column uses code style like
totalPrice for the literal Imweb API field name. Italic text describes how a value is produced when it doesn’t map cleanly to a single Imweb field — typically an Adriel-side computation, an aggregation across order rows, or a value the Imweb API does not provide.Orders
Revenue & sales
Order Cancelled Payment Amount comes from cancel and return records. It is
0 on regular order rows. On a cancellation record it reflects the refunded amount, and on a return record it reflects the return’s available (excluding-refund) amount. Payment amount itself is stored as a negative value on cancellation records.Products
Product Order metrics link products with their orders. When a Product Order metric is used with a product filter, only the portion of the order tied to that product is included, and only orders containing at least one matching product are shown. If a product can no longer be retrieved from the API (for example, it was deleted), the related orders may not appear — use Product Order metrics only when necessary.
Breakdowns
Order details
Product catalog
Time & date grouping
Imweb returns order-level records with timestamps; all time-grouping breakdowns are Adriel-side aggregations of that same order data.
Overview
These grouping options are provided by Adriel and are not tied to an Imweb API field.
Limitations
Based on the current connector, Imweb has:- A 90-day historical limit (
maxFromDate= 90 days ago). Orders older than 90 days from today cannot be back-filled. - Daily refresh cadence. Orders sync once per day on a rolling 1-day window and exclude today’s orders; changes surface on the next daily run.
- No order-level tax. Order Tax Amount is always
0because the Imweb API does not return tax at the order level. - Cancellations and returns as separate rows. Each completed cancellation or return produces its own record with a suffixed order ID; only
CANCEL_COMPLETEandRETURN_COMPLETEsections generate these records. Pending cancel/return requests do not. - Shipping fee not reflected on cancel/return records. Shipping fee is fixed to
0on cancellation and return records, so shipping refunds are not represented. - Currency fixed to KRW. Product currency is always KRW, and order currency falls back to KRW when the raw order omits it.
- No deleted-data retention. Products deleted in Imweb no longer appear, and orders referencing a deleted product may not surface under Product Order metrics.
API references
- Imweb Open API — base API surface the connector uses (orders, products, site-info) over OAuth 2.0.
The public Imweb developer documentation page URLs are not confirmed from source; only the API base host (
openapi.imweb.me) is verified. Replace or extend this list with the canonical Imweb Open API documentation links during review.See also
- How to connect Imweb (paired how-to)
- Cafe24 data reference — Korean commerce platform
- Naver Smart Store data reference — Korean e-commerce platform
- Shopify data reference — direct-to-consumer commerce platform
