Skip to main content

Introduction

Cafe24 is one of the largest Korean DTC (direct-to-consumer) e-commerce platforms, powering individual merchant malls. Each mall has its own subdomain, and a single mall account may operate multiple shops. The connector authenticates against Cafe24’s Admin REST API v2 over OAuth2 and syncs order and product data for dashboards. The connector exposes orders, products, and reconstructed sales metrics. Cafe24 issues values in the mall’s currency (typically KRW), and a single connection can be split across multiple shops by creating one data source per shop. Pre-aggregated dashboard data (visits, ad effect, category sales, and similar) is exposed separately by the Cafe24 Analytics data source. As an e-commerce connector, order, revenue, and product breakdowns are standardized so widgets can aggregate alongside ad-platform sources without additional configuration. To connect this data source, see How to connect Cafe24 to Adriel.

Data refresh strategy

Architecture data

Architecture covers products and their catalog metadata. Products are fully refreshed once per day. Each product record carries name, SKU, price, retail (compare-at) price, image, status, and category metadata, paged in cursor batches of 100 (by last product number).

Reports data

Reports include order-level financial and status data. Orders are refreshed daily (there is no hourly refresh cadence for this connector). At every refresh, orders made or modified in the most recent 3-day window are re-pulled to capture status transitions such as payment, cancellation, and refund. Orders are fetched in two parallel passes and then deduplicated by order ID:
  • Regular orders are pulled by payment date (pay_date) when the data source uses payment-date mode, or by order date (order_date) otherwise.
  • Cancelled orders are pulled by cancellation-complete date (cancel_complete_date).
An order appearing in both passes (for example, paid and cancelled on the same day) is kept once. Orders are paged in batches of 1000 with item lines embedded inline. Revenue is reported in the asset’s configured currency, converted from the mall currency (default KRW) at sync time.

Architecture levels

Mall → Shop → Product catalog → Order → Order line. Each order line is a separate row on the order. A cancelled order additionally produces a separate cancellation record.

Date range limits

Historical orders can be back-filled up to 90 days; data older than 90 days cannot be retrieved through this connector.

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 order_price_amount for the literal Cafe24 field name. Italic text describes how a value is produced when it doesn’t map to a single Cafe24 field — typically an Adriel-side aggregation across order rows or a computed formula.

Orders

Revenue & sales

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 has been deleted in Cafe24, the related orders may not appear — use Product Order metrics only when necessary.

Customers

Buyer anonymization. Cafe24 returns buyer details with each order, but buyer fields are anonymized before persistence, so dashboards do not expose customer PII.

Fulfillment & delivery

Discounts & abandonment

Breakdowns

Products

Order details

Customer type

Order Customer Type is resolved by Adriel from the buyer’s first-order flag on the order.

Time & date grouping

Time groupings are Adriel-side aggregations of the same underlying order data.
When the “from” and “to” filters do not align with the start and end of a period, the entire period is still displayed, though the filters still apply to the Total row.

Overview & status

These groupings are provided by Adriel and do not map to a Cafe24 field.

Limitations

Based on the current connector, Cafe24 has:
  • A 90-day historical limit. Orders older than 90 days from today cannot be back-filled.
  • Daily refresh cadence. Orders sync daily on a rolling 3-day look-back window; there is no hourly refresh.
  • One-time-use refresh tokens. Each token refresh issues a new refresh token that replaces the previous one. If a refresh response is missing the new refresh token, the connection is unrecoverable until it is reconnected.
  • Shared OAuth app account cap. Adriel’s own Cafe24 OAuth app is limited to five accounts. Beyond that, customers must supply their own developer-app credentials (client_app_id / client_app_secret) on the connection, which then take priority over the platform default.
  • Per-shop scoping. A mall may expose multiple shops; each data source is scoped to exactly one shop. Reporting across several shops requires separate data sources sharing the underlying mall connection.
  • Cancellations are separate records. A cancelled order produces a distinct cancellation record (order ID suffixed :cancel) that carries only Order Cancelled Payment Amount as non-zero; all other monetary values on it are 0.
  • No deleted-data retention. Products or orders deleted in Cafe24 no longer appear. Orders that reference a deleted product may not surface under Product Order metrics.
  • Rate limiting. Requests are throttled to one per 500 ms per asset.

API references

See also