Important Reminder (Potential Breaking Change)

🚧 即將上線 - Upcoming

Q3, 2025 Reminder on SHOPLINE Cart & Checkout Page Revamp - Potential Impact on Apps using Storefront App Extensions

This announcement provides important information regarding an upcoming revamp of the Cart Page on the SHOPLINE platform

Background on the Revamp

The current checkout flow revamp involves significant changes to the front-end architecture, including the Cart Page & Checkout Page. While we are working to ensure a smooth transition, we recognize that these changes, particularly to the Document Object Model (DOM) structure, CSS classes, JavaScript events, etc, may impact existing storefront app extensions.
For example, app use cases and implementation that rely on specific "anchor" points (e.g., HTML element IDs, class names, or specific positions within the page structure) for injecting content, modifying styles, or attaching event listeners may experience:

  • Misalignment or incorrect placement: Your app's UI elements might not appear where intended.
  • Non-functional features: Features that interact with specific DOM elements might cease to work.
  • Visual issues: Your app's styling might be affected by the new page structure.

Required Actions for Developers:

To prepare for these changes and ensure the continued compatibility of your storefront app extensions, we urge you to evaluate if following actions are needed:

  1. Participate in Alpha/Beta Programs
    1. Request to be added to beta list & review the cart page in testing Store
    2. Request to be added to beta list & review the checkout Page Testing Store (Coming Soon)
    3. Please contact our partnership team
  2. Update Your App Extensions
    1. Based on your testing result, update your app extensions to align with the new cart & checkout page structure and ensure full compatibility

Identifying the New Cart Page Version during Beta phase:

During the beta phase, the backend determines the traffic split and communicates the assigned version to the frontend.
For backward compatibility and support concerns, you can determine which version of the cart page a customer is using by checking the browser's cookies. There will be a checkout_revamp key in the browser cookie.

  • If the checkout_revamp key's value is control, the customer is on the old version.
  • If the checkout_revamp key's value is variation, the customer is on the new version.

Timeline:

Please notify SHOPLINE if you have any questions. Once partners have joined the Alpha & Beta phase, the feature release timeline will be communicated through the subsequent channel. We understand that breaking changes can be challenging, and we are committed to providing you with the necessary support to ensure a smooth transition.

Thank you for your understanding and cooperation.

Sincerely,
SHOPLINE Open Platform Team


Q3, 2025 SHOPLINE 購物車與結帳頁面改版提醒 – 對使用 Storefront App Extensions 的應用程式可能造成的影響

本公告旨在提供您關於 SHOPLINE 平台即將進行的購物車頁面改版的重要資訊

背景:

結帳流程改版將對前端架構,包括購物車頁面和結帳頁面,進行重構。儘管我們正努力確保系統穩定性,但我們意識到重構,特別是對文件物件模型 (DOM) 結構、CSS 類別、JavaScript 等的改動,可能會影響現有的 Storefront App Extensions 使用者。

例如,依賴特定「錨點」(例如:HTML 元素 ID、類別名稱或頁面結構中的特定位置)來注入內容、修改樣式或附加事件監聽器的應用程式用例和實作,可能會遇到以下情況:

  • 錯位或不正確的放置: 您的應用程式使用者介面元素可能無法按預期顯示。
  • 功能失效: 與特定 DOM 元素互動的功能可能會停止運作。
  • 視覺開題: 您的應用程式的樣式可能會受到新頁面結構的影響。

開發者所需採取之行動:

為了應對這些變化並確保您的 Storefront App Extensions 能夠持續相容,我們敦促您評估是否需要採取以下行動:參與 Alpha/Beta 計劃:

  • 申請加入 Beta 列表並在測試商店中審查購物車頁面
  • 申請加入 Beta 列表並在測試商店中審查結帳頁面(即將推出)
    如有需要,請聯繫我們的合作夥伴團隊申請
    更新您的應用程式擴充功能: 根據您的測試結果,更新您的應用程式擴充功能,使其與新的購物車與結帳頁面結構保持一致,並確保完全相容。

在 Beta 階段識別新版購物車頁面:

在 beta 階段,後端會將流量分配到不同的版本並傳達給前端。為了向後兼容和排查支援考量,您的應用程式可以透過檢查瀏覽器 Cookie 來判斷顧客使用的是哪個版本的購物車頁面。瀏覽器 Cookie 中將會有一個 checkout_revamp 的鍵值 。

  • 如果 checkout_revamp 鍵的值為 control,則顧客正在使用舊版 。
  • 如果 checkout_revamp 鍵的值為 variation,則顧客正在使用新版 。

時間軸:

如果您有任何疑問,請隨時通知 SHOPLINE。一旦合作夥伴加入 Alpha 和 Beta 階段,功能發布時間軸將透過後續管道進行溝通。
我們理解支持此重大變更可能充滿挑戰,但我們致力於提供您必要的支援,以確保平穩過渡。感謝您的理解與合作。

此致,
SHOPLINE Open Platform Team


☑️ 已上線 - Released

Mar. 27, 2025 App Webhook 異動:調整 remove 相關 Topic 的 Payload 結構(App Webhook Update: Changes to Payload Structure for Remove-Related Topics)

預計上線時間 Target Release Date

  • 預計上線時間 Target Release Date : Mar. 27, 2025
  • 通知公告日期 Announce Date : Nov. 29, 2024

影響範圍 Scope of Impact

只影響透過 Developer Center 訂閱的以下 App webhook topics,不影響透過 Open API 以 staff token 訂閱的 Merchant webhook topics。

This change only affects the following app webhooks subscribed to via the Developer Center. Merchant webhooks subscribed through the Open API using a staff token will not be impacted.

  • app_metafields/remove
  • category/remove
  • channel/remove
  • delivery_option/remove
  • membership_tier/remove
  • metafields/remove
  • metafield_definitions/remove
  • order/remove
  • payment/remove
  • product/remove
  • tag/remove
  • user/remove

異動情況 Description of Changes

基於底層架構優化與標準化,App webhooks 中 remove 相關 topics 的resource 欄位僅會發送 idresource 欄位其餘 payload 將停止發送。

As part of our infrastructure optimization and standardization efforts, the resource field in remove-related app webhook topics will only include the id. All other payload data of resource field the will no longer be sent.

{
  "event": "Product",
  "merchant_id": "6327e262c7ef5b176ba75166",
  "resource": {
    "id": "651150e49e161b00408e40bf" 
  },
  "topic": "product/remove",
  "trace_id": "51c34d32-8f9f-46d5-ac6a-ef833adc3d7a",
  "ts": "1695712956784492000"
}

建議修改 Suggestions for Modification

請檢查 App 程式碼內是否有訂閱上述 remove 相關 App webhook topics,如有使用resource 欄位中的 payload,除id之外,請勿使用其他回傳的 payload 值。

Please review your app code to check if it subscribes to the above-mentioned remove-related app webhook topics. If your code utilizes the payload in the resource field, ensure that only the id is used and avoid relying on any other returned payload values.


2024 Webhook topics transition - webhook topic 名稱改動

預計上線時間 Target Release Date

  • 預計上線時間 Target Release Date : ETA 2024 內
  • 通知公告日期 Announce Date : Feb 5, 2024

影響範圍 Scope of Impact

只影響透過 Developer Center 訂閱的以下 App webhooks,不影響透過 Open API 以 staff token 訂閱的 Merchant webhooks。

This change only affects the following app webhooks subscribed to via the Developer Center. Merchant webhooks subscribed through the Open API using a staff token will not be impacted.

  • user/new_member webhook
  • user/send_info_reward webhook

異動情況 Description of Changes

  • 改動原因:加強底層架構優化與 customer webhook 標準化的必要改動
  • 預計停止發送 user/new_member webhook 和 user/send_info_reward webhook

建議修改 Suggestions for Modification

  • user/new_member webhook --> 請改訂閱 customer/new_member webhook (即日起已開放訂閱)
  • user/send_info_reward webhook --> 請改訂閱 customer/send_info_reward webhook (即日起已開放訂閱)
  • 請修改 APP 程式碼裡面解析 topic 的部分,由 user/ 改成認 customer/


Aug 21, 2024 Go Version Upgrade & potential Webhook Signature breaking change

Background

We are doing Go version upgrade. As part of the update, our system will handle special characters according to the RFC 8259 standard. This change aim to reduce the chance of signature mismatches and enhance the reliability of webhook interactions.

Scope of Impact & Description of Changes

Scope of Impact:

The special character handling logic of webhook signatures, which is used to verify that the payload is sent by SHOPLINE.

Description of Changes:

  • After upgrading to the new Go version, Go will follow the RFC8259 standard for handling special characters.
  • As part of this update, the system will add support for the \b and \f characters. This means that our system will handle all five control characters (\b, \f, \n, \r, \t) according to the RFC8259 standard.

Summary Table

AspectAs isTo be
Special Character Handling & Signature VerificationSpecial characters are not always handled according to RFC 8259. For example, a payload containing special characters like \b and \f was previously not handled according to the RFC8259 standard.

Risk of incorrect handling of special characters can cause signature mismatches, affecting verification.
With the new Go version, special characters \b and \f will also be consistently handled and escaped according to RFC 8259.

Aligning to the same standard ensures the correct handling and therefore accurate signature verification, preventing mismatches.
Example for illustrationFor example, content with \b would be converted to \u0008.For example, content with \b will be retained as-is, without conversion.

Suggestion / Action Item

Review if these changes could affect your system logic & ensure that the handling of special characters in webhook signatures' JSON payloads is based on RFC 8259 in order to avoid this risk of signature mismatches.