Skip to main content
在 X 上追蹤我們、收聽 Social Media API Podcast，或訂閱電子報以取得最新更新。

​
2026 年 10 月

  • 10月14日 - 現已提供每月貼文配額重置日期與代碼 106 的說明文件。 文件現在說明了每月貼文配額：配額會在每月 1 日（UTC）重置，而非您的帳單日期；失敗及被封鎖的發文嘗試也會計入配額。如果 /post 回傳 HTTP 429 及 code: 106，而您以為觸發了速率限制，實際上是該 profile 已用完其每月貼文配額。請參閱我可以發多少貼文與呼叫多少 API？，了解哪些項目會計入配額以及如何查看您的用量。
  • 10月14日 - Bluesky 影片保留真實長寬比。 從 Amazon S3 URL（任何 amazonaws.com 主機）發佈到 Bluesky 的方形或直式影片，在 Bluesky 動態、貼文檢視和應用程式中都會在兩側顯示黑邊，儘管上傳的檔案本身是正確的。貼文記錄無論影片的實際形狀為何都宣告 16:9 的長寬比，而 Bluesky 會根據該宣告決定播放器尺寸。現在，只要能讀取影片，Bluesky 影片貼文就會帶有影片實測的寬度和高度，因此 1:1 或 9:16 的影片會以其真實形狀呈現。發佈方式無需任何變更：照常傳送相同的 mediaUrls 即可。此修正之前發佈的貼文會保留建立時的長寬比；請重新發佈以進行更正。請參閱 Bluesky 媒體指南。
  • 10月13日 - Facebook 與 Instagram 推廣的活動預算。 推廣現在可以使用 budget.level: “campaign” 將預算設定在活動上而非廣告集上，並可搭配每日預算或總額預算。此功能使用推廣請求主體的巢狀格式。若為每日活動預算，歷史記錄中的 budgetDaily 會顯示該活動的預算。請參閱 Facebook 推廣與 Instagram 推廣。
  • 10月13日 - X 媒體上傳在額度用盡時回傳代碼 416。 當 BYOK X/Twitter 帳戶所註冊的 X Developer 帳戶的 API 額度用盡時，圖片和影片上傳現在會回傳 code: 416（HTTP 402，X CreditsDepleted），並在 details 中附上 X 的說明。先前，圖片上傳失敗時回傳 code: 117 (“Please check the media file size, dimensions, and content-type”)，影片回傳 code: 115，兩者都把問題指向一個從未出錯的媒體檔案。解決方法是在 console.x.com 購買額度（Billing → Credits）。這些上傳不會重試，因為在帳戶取得額度之前，任何重試都不會成功。這讓媒體上傳與發佈和分析路徑保持一致，後兩者早已回傳 416。如果您的整合依據 117 或 115 判斷 X 上的媒體問題，請加入對 416 的處理。
  • 10月13日 - 遭鎖定的 X 帳戶在媒體上傳時回傳代碼 224。 當 X 暫時鎖定帳戶時，向 X 發佈圖片或影片會失敗：圖片回傳 code: 117 (“Please check the media file size, dimensions, and content-type”)，影片回傳 code: 115，導致您去檢查一個本來沒有問題的媒體檔案。這些上傳現在會回傳 code: 224 (“X/Twitter account locked. Please go to twitter.com to unlock.”)，並在 details 中附上 X 自己的說明。要解決此問題，請登入 x.com 並完成 X 的解鎖步驟，然後重新發佈。無需重新連結，帳戶仍與 Ayrshare 保持連結。
  • 10 月 13 日 - Facebook 留言 webhook 現已正常觸發。 為 Facebook 粉絲專頁註冊的 comments webhook 先前從未收到任何事件：Ayrshare 沒有訂閱承載粉絲專頁留言的 Meta 欄位，因此沒有任何事件送達，也沒有任何錯誤。現在 Facebook 粉絲專頁已完成訂閱，只要個人檔案啟用了訊息功能（Messaging Add-On），留言事件就會送達。已連結的粉絲專頁會自動重新訂閱，無需重新連結或重新註冊。Facebook 留言以 Meta 粉絲專頁 feed 結構 (comment_id, post_id, message, from.name) 送達，與 Instagram 的結構不同；兩者請參閱 Comments Action。Instagram 留言 webhook 維持不變。
  • 10 月 13 日 - 可開啟聊天的推廣按鈕。Facebook 或 Instagram 推廣的按鈕現在可以開啟 Messenger、WhatsApp 或 Instagram Direct 對話，而非網頁，因此您現在可以推廣能與您的企業展開聊天的貼文。請傳送 callToAction.destination（messenger、whatsapp 或 instagramDm）並搭配相符的按鈕類型、不帶 link，同時使用 engagement 或 interactions 目標。廣告會因此針對對話進行最佳化。此功能使用推廣請求主體的巢狀格式。請參閱 Facebook 推廣與 Instagram 推廣。
  • 10 月 9 日 - 推廣至您現有的 Facebook 與 Instagram 活動。推廣不再需要建立自己的活動。使用 attachTo.campaignId 時，會在您已於 Meta 中執行的活動內新增廣告集與廣告。使用 attachTo.adSetId（加上該廣告集的 attachTo.campaignId）時，只會新增廣告，且您需省略 budget、targeting 與 bidAmount，因為廣告集會保留自己的設定。之後暫停或啟用推廣只會變更推廣所建立的項目，絕不會變更您的活動或廣告集。此功能使用推廣請求主體的巢狀格式。請參閱 Facebook 推廣與 Instagram 推廣。
  • 10 月 9 日 - 減少 Instagram 誤報的重新連結錯誤，輪播發布更快。現在，對於 Instagram 剛剛接受的貼文，我們會在發布前稍作等待，並在發布輪播前檢查其是否已就緒，因此 Instagram 拒絕首次嘗試的情況大幅減少。先前，在媒體處理完成後立即發布的貼文可能會以 code: 259 失敗，並提示您取消連結並重新連結 Instagram 帳戶，即使帳戶本身沒有問題、重試該貼文也能成功；此外，由於 Instagram 拒絕了首次發布嘗試，大多數輪播比實際需要多花約 10 秒。您無需做任何變更；因此原因而出現的 259 並不需要重新連結。
  • 10 月 8 日 - Instagram 與 Threads 影片貼文發布更快。我們最佳化了影片發布流程以加快即時發布速度：Instagram 上的典型等待時間從約 20 秒縮短至 5 秒，Threads 上從約 31 秒縮短至 6 秒。較長或解析度較高的影片仍可能需要 25 到 30 秒，因為這是 Meta 本身處理它們所需的時間。你無需做任何變更。
  • 10 月 8 日 - 可依帶 act_ 的帳戶 ID 列出 Facebook 與 Instagram 廣告。當 accountId 帶有 act_ 前綴（例如 act_1234567890）時，Facebook 與 Instagram 已推廣廣告現在會傳回你的廣告。先前只有純數字形式有效：帶前綴的形式會傳回空的 ads 清單，彷彿該帳戶沒有任何廣告。相同的修正也適用於 GraphQL ads 查詢與 MCP list_ads 工具。在這些介面中，不是有效廣告帳戶 ID 的 accountId 現在也會傳回 code: 101，而不是空清單。
  • 10 月 8 日 - Facebook 與 Instagram 留言錯誤現在包含平台提供的原因。當 Facebook 或 Instagram 拒絕透過發布留言或回覆留言送出的留言或回覆時，錯誤現在會在 details 中包含平台提供的原因及其錯誤代碼與子代碼，例如 “Instagram Comment Not Added: Your Instagram comment was not added (code 20, subcode 1772107)“。先前這些錯誤只會回傳一般訊息，你無法得知留言失敗的原因。
  • 10 月 7 日 - Threads 短暫未就緒時，Threads 貼文不再因 Code 379 而失敗。部分 Threads 貼文即使本身沒有任何問題，也會因 code: 379（“Error posting to Threads.”）與 HTTP 500 而失敗。Ayrshare 現在會等待最多 30 秒讓 Threads 接受貼文，Threads 留言、回覆與首則留言也會獲得相同的等待。若 Threads 仍未準備好接受貼文，你將收到 code: 522（HTTP 400，retryAvailable: true），而非 379。關於如何安全地重試，請參閱 Code 522。
  • 10 月 7 日 - Connect Accounts 電子郵件寄送失敗時仍會回傳連結 URL。如果你請我們以電子郵件將連結 URL 寄給使用者，而電子郵件無法寄送，產生連結 URL 與 建立 Link Session 現在仍會回傳該 URL，並附上 emailSent: false 與一個 emailError 物件，讓你可以透過其他方式將它交給使用者。先前寄送失敗會回傳 code: 333 且不回傳 URL；而缺少 termsUrl, privacyUrl, company 或 contactEmail 的 email 物件會被默默略過。現在這種情況也會回傳 emailError，並由 details 列出缺少的欄位。如果你在收到 code: 333 時會重試，請檢查這一點：請改為在成功回應中尋找 emailError，詳見 Connect Accounts 電子郵件。
  • 10 月 6 日 - Pin 支援 Pinterest AI 揭露。Pinterest 發布 現在接受 pinterestOptions.aiDisclosures，讓你在建立圖片、輪播或影片 Pin 時傳送 AI_MODIFIED、SYNTHETIC_PERFORMER 或兩者。揭露資訊會套用至整個 Pin。若省略此欄位或為空，則不會有任何變更；若欄位無效，Pin 仍可發布，且 Pinterest 結果中會附上警告，說明揭露資訊未被轉送。
  • 10 月 6 日 - Facebook Reels 可邀請協作者粉絲專頁。在 Reel 貼文的 faceBookOptions.collaborators 中加入 Facebook 粉絲專頁 ID，即可邀請該粉絲專頁成為協作者；每則 Reel 支援一個粉絲專頁。邀請會在 Reel 發布後送出，你可以使用 協作者請求狀態 查詢其狀態。Facebook 仍可能拒絕邀請，例如當該粉絲專頁與你的粉絲專頁位於同一個 Business 資產組合時：Reel 仍會維持已發布狀態，回應中的 warnings 會附上警告。若要排程這類 Reel，請使用 scheduleDate，而非 draft 或 scheduledPublishDate。請參閱 Facebook Reels。
  • 10 月 5 日 - 即時 Facebook 與 Instagram 廣告洞察報告。歷史記錄 顯示我們計費的每日支出，每晚複製過去 30 天的資料。新的洞察報告端點則改為即時讀取 Meta，因此現在您可以針對過去 37 個月內任何範圍的廣告活動或廣告產生報告。每一列代表一天，包含 spend、impressions、reach、clicks、cpm、cpc、ctr、actions、conversionValue 以及廣告帳戶的 currency。使用 metrics 選擇您需要的指標，使用 breakdowns 依 age、gender、country 或 placement 細分每一天的資料，並使用 cursor 分頁瀏覽較長的範圍。使用 breakdowns 時，Meta 僅報告過去 13 個月的 reach。目前尚無法產生廣告組合報告。請參閱 Facebook 洞察報告 與 Instagram 洞察報告。
  • 10 月 5 日 - LinkedIn 個人檔案的每日粉絲成長。Analytics on a Social Network（/analytics/social）中的 followersDaily 對 LinkedIn 個人檔案一律回傳空陣列。現在會回傳過去 30 天的每日粉絲數。
  • 10 月 5 日 - Pinterest 使用者名稱。對於 Pinterest 帳戶，User Profile Details 回應中的 username 傳回的是所選圖板的名稱而非帳戶使用者名稱，因此 profileUrl 指向一個不存在的個人檔案。現在 username 會傳回帳戶使用者名稱，profileUrl 會開啟正確的個人檔案，無需重新連結。displayName 仍會傳回圖板名稱。
  • 10 月 5 日 - Threads 使用者名稱。對於 Threads 帳戶，User Profile Details 回應中的 username 傳回的是帳戶的顯示名稱而非其帳號名稱（handle），因此 profileUrl 指向一個不存在的個人檔案。現在 username 會傳回帳號名稱，profileUrl 會開啟正確的個人檔案，無需重新連結。如果您將 username 顯示為帳戶名稱，請改用 displayName。
  • 10 月 2 日 - 支援在美國以外推廣特殊廣告類別貼文。 帶有 specialAdCategories（例如 housing）且鎖定美國以外地點的 Facebook 或 Instagram 推廣會失敗並傳回 “You’ve chosen audience locations that are outside of the countries you selected for your Special Ad Categories”，同時在您的廣告帳號中留下一個空活動。Meta 需要知道特殊類別廣告投放的國家/地區，而我們先前沒有告知，因此 Meta 預設使用美國。現在我們會從您的 locations 中取得這些國家/地區，包括每個地區和城市所屬的國家/地區，因此您現在可以在美國以外推廣住房、就業和金融類貼文。如果推廣在活動建立後失敗，我們現在也會嘗試刪除該活動，因此失敗的推廣應該不會再留下空活動。請參閱 Boost Post。
  • 10 月 1 日 - 釐清並記錄 Facebook 社群守則封鎖錯誤碼 249。 隨 249 回傳的訊息不再表示貼文本身違反了 Facebook 的社群守則。Facebook 通常將封鎖套用在帳號或粉絲專頁上，而非貼文，且不會透過 API 回傳具體原因，因此訊息現在會引導至 Facebook 的 Account Status 頁面：登入 Facebook，點擊右上角的個人檔案照片，開啟「Help」區段並選擇 Account Status。該頁面會顯示真正的原因並提供申訴流程。當 Facebook 提供措辭時，仍會原封不動地透過 details 傳遞。錯誤碼 249 現在首次公開記錄於文件中，請參閱 Facebook 社群守則封鎖。僅訊息文字有所變更；數值錯誤碼、HTTP 狀態與回應結構皆維持不變。用戶端應比對數值 code，而不是確切的訊息文字。
  • 10 月 1 日 - 連結頁面現在會提示連結已過期。 連結 URL 預設有效期為 5 分鐘。以前，如果連結在您的使用者仍在登入社群網路時過期，連結頁面會顯示通用的 “There was an error linking” 訊息，導致您的使用者繼續使用同一個已過期的連結重試。現在，他們會被告知連結已過期，需要取得新連結。在 Snapchat 和 TikTok 上，您的使用者可能會回到一個未登入的頁面，現在他們會看到 Link expired 頁面，而不是 Ayrshare 登入畫面。如果您使用 Ayrshare Connect Widget，此類失敗的 error 事件現在會包含 code，連結過期時為 503，因此您的程式碼可以為使用者建立新連結。如需給使用者更多時間，請在建立連結時調高 expiresIn（最多 2880 分鐘，Max Pack）。

​
2026 年 9 月

  • 9 月 29 日 - 使用 GraphQL 查詢 Ayrshare API。 現在除了 REST API 之外，還新增了位於 https://api.ayrshare.com/graphql 的 GraphQL 端點，讓你可以在一次請求中要求多項受支援的操作，而不必逐一呼叫。它使用相同的 API Key、profile 範圍與方案限制，而 REST 仍是功能完整的 API。由於 GraphQL schema 是型別化且自我描述的，你的編輯器可以自動完成每個可用的操作與引數，程式碼產生器也能據此為你的程式語言產生型別。每個由 API 支援的根欄位都算作一次 API 呼叫，與對應的 REST 呼叫完全相同：包含四個根操作的查詢會計入你配額中的四次呼叫，而不是一次；選取巢狀回應欄位則不會增加呼叫次數。單一請求最多可進行五次 API 呼叫，且請求 body 上限為 64 KB，這表示媒體位元組無法透過 GraphQL 傳送。請使用 mediaUploadUrl 取得上傳 URL，將你的檔案直接 PUT 到其 uploadUrl，然後在貼文中使用傳回的 accessUrl。撰寫錯誤處理時有一點需要注意：失敗的操作仍會傳回 HTTP 200，並在回應 body 中回報失敗，因此請務必檢查 errors，而不要只依賴狀態碼。GraphQL 錯誤列出了確實會改變狀態碼的情況。你可以在 GraphQL Explorer 中試用，不必撰寫任何程式碼，並參閱 GraphQL API 概觀開始使用。
  • 9 月 29 日 - Facebook 粉絲專頁上的 DM 自動化。 Automations 現在可在與 profile 連結的 Facebook 粉絲專頁上執行，不再僅限於 Instagram。建立一個設定 “platform”: “facebook” 並使用 dm_keyword 或 dm_reaction 觸發條件的自動化，當有人傳送關鍵字給你的粉絲專頁或對你的訊息表情回應時，就能在 Messenger 中自動回覆。send_dm 會從粉絲專頁發送，fire_webhook 與 send_email 的運作方式與 Instagram 相同。該 profile 需要為 Facebook 啟用 Messaging。留言與限時動態觸發條件仍僅限於 Instagram。請參閱 Facebook 粉絲專頁。
  • 9 月 29 日 - Facebook 不重複觸及數回歸。 自從 Meta 於 6 月 15 日淘汰其 unique-impression 指標後，Facebook 分析僅回報總觀看數（mediaView 與 pageMediaView），同一人可能被重複計算。貼文分析現在會傳回 totalMediaViewUnique，即貼文被播放或顯示給的不重複人數；社群網路分析則會針對你的 Page 傳回 pageTotalMediaViewUnique。兩者皆來自 Meta 的 Total Unique Media Views 指標，也就是 Meta 用來取代已淘汰欄位的指標。Meta 以每日為單位回報 Page 數值，因此 pageTotalMediaViewUnique 會將這些每日數值加總：在兩個不同日子觀看你內容的人會被計算兩次。所有現有欄位皆維持不變。請參閱 6 月 15 日遷移說明，了解各個已淘汰欄位對應的替代欄位。
  • 9 月 29 日 - Meta 無法抓取你的媒體時，錯誤訊息更清楚。 媒體抓取／爬蟲遭封鎖導致的失敗（Meta 子代碼 2207052）先前會傳回通用、可重試的 code: 440（Instagram；Facebook Reels 為 code: 108），現在改為傳回專用、不可重試的 code: 479（HTTP 400）。當 Ayrshare 已將媒體重新託管到自己的 CDN 上，Meta 仍無法抓取時，就會傳回此代碼。錯誤訊息會指出可能的原因（主機透過 robots.txt 或 CDN/WAF 規則封鎖了 Meta 的爬蟲 facebookexternalhit / Facebot）以及解決方法（允許這些爬蟲，或改用 Meta 能存取的主機提供媒體）。真正暫時性的接收失敗（子代碼 2207032 / 2207003）仍會傳回 code: 440（Instagram；Facebook Reels 為 code: 108），並附上重試建議。請參閱Meta 媒體爬蟲被封鎖與錯誤代碼參考。
  • 9 月 28 日 - 更新貼文會拒絕未變更任何內容的請求，並可單獨接受 disableComments。 先前當 disableComments 是你傳送的唯一欄位時，更新貼文會傳回 code: 101，因此你必須再加上另一個欄位（例如 notes）才能開啟或關閉留言。現在它可以單獨使用。另一方面，沒有任何內容需要更新的請求先前會傳回 status: “success”，卻什麼也沒變更。這包括只有 id、空的 youTubeOptions，以及將 visibility 放在最上層而非 youTubeOptions 內傳送的請求，因此打錯字看起來也像是成功了。這些請求現在會傳回 code: 101。如果你在最上層傳送 visibility，請注意：它從未變更過影片，現在會傳回錯誤而非成功。請將它移到 youTubeOptions 內。
  • 9 月 28 日 - 變更 YouTube 影片的可見性不再重設其授權。 先前透過更新貼文變更 youTubeOptions.visibility 時，會將影片的授權重設為 Standard YouTube License，因此以 “creativeCommon” 發布的影片一旦被設為公開或不公開，就會失去其 Creative Commons 授權。現在授權會被保留。如果你在此修正之前曾變更 Creative Commons 影片的可見性，請到 YouTube Studio 檢查其授權。
  • 9 月 25 日 - 推廣的 Facebook 貼文現在會鎖定您選擇的性別。 推廣 Facebook 貼文先前會忽略文件中記載的 gender 參數，因此使用 “gender”: “female” 或 “male” 傳送的推廣會顯示給所有性別，而請求本身仍然成功。現在 gender 已生效，Instagram 推廣同樣適用。如果您傳送了 gender，請注意：all、male 或 female 以外的值現在會傳回 code: 101，而不是悄悄地鎖定所有人。不含 gender 的請求不受影響。
  • 9 月 25 日 - 精確查看每個自動化發送了什麼。Get Automation Activity 中的每個動作結果，現在都會記錄該動作發送的內容：發送給那個人的 DM 文字、排入佇列時的電子郵件，或帶有其送達 id 的 webhook 事件資料。它位於新的 sent 欄位中，旁邊是 config，記錄該動作在當下的設定。在此之前，活動只會顯示每個動作的狀態，因此一旦你編輯了自動化，就無法得知先前的執行實際發送了什麼。兩個欄位在發送失敗時也會記錄，過長的文字會被截短以符合限制，發生時會設定 truncated。請見sent 包含的內容。
  • 9 月 24 日 - 使用你自己的伺服器撰寫每則自動化 DM。在此之前，send_dm 自動化會對每個人發送相同的模板，只有像 這類預留變數會變動。在動作上設定 messageUrl，每當規則比對成功，我們就會詢問你的端點要對那個人說什麼，並將它的回應當作 DM 發送，讓每位留言者都能收到由你自己的系統為他撰寫的訊息，例如附上他專屬追蹤連結的回覆。若你的端點回應緩慢、回傳錯誤，或回傳無法使用的內容，我們會改為發送該動作的一般 message。我們絕不會重試對你端點的失敗呼叫，因為重試可能會發送第二則 DM。在 Get Activity 上，messageSource 會顯示 send_dm 是以哪段文字建立的：你端點的文字或一般的 message。它在文字選定後就會被記錄，包括之後發送失敗的情況，因此請查看 status 以確認 DM 是否已送出。請見動態訊息內容。
  • 9 月 24 日 - Instagram 自動化 Webhook 現在攜帶其上下文，並可回報結果。自動化觸發的 webhook 現在包含 activityId、actionId、eventId、commentId、commentText、postId 與 storyId，因此你可以將它與 Get Activity 的資料列精確配對，而不必從 recipientId、triggerId 與關鍵字去猜——當兩個人同時留言同一個關鍵字時，那種方式會產生歧義。在自動化的 fire_webhook 動作上設定 “sendCompletedEvent”: true，即可在派送完成時額外收到 automation.completed，其中帶有 status 與每個動作的結果，因此你通常不需輪詢即可得知結果（Get Activity 仍是用於核對的正式紀錄）。兩種事件現在都帶有 type 欄位（automation.triggered 或 automation.completed）；所有既有欄位維持不變，未選擇加入的接收端每次觸發仍會收到剛好一個 payload。請見 webhook 事件。
  • 9 月 24 日 - 讓留言自動化在每一則貼文上執行，而不必每則貼文各建一個。comment_keyword 觸發條件現在可以將 “all” 作為其 postId，因此當有人在已連結帳號上的任何貼文或 Reel 留言關鍵字時，規則就會觸發。先前 postId 必須指定某一則特定內容，這表示你每次發布都得建立一個新的自動化——若忘記了，規則就會悄悄地什麼都不涵蓋。限時動態觸發條件同樣接受以 “all” 作為 storyId。“all” 絕不會觸及另一個 profile 的內容，你的每日 DM 上限與錨定於互動事件的發送規則，與單一貼文規則完全相同地適用。去重是以每個自動化計算，因此在 “all” 規則上，於去重視窗內在兩則貼文留言的人只會收到一則 DM。將 dedupWindowMinutes 設為 0 則會為每則符合的留言發送 DM，包括在同一則貼文上的重複留言。值必須剛好是小寫的 “all”；像 “ALL” 這類變體現在會被拒絕，而不會被儲存為一個永遠不會觸發的規則。你自己的留言現在也不會再執行自動化的 fire_webhook 或 send_email 動作。過去以關鍵字回覆你的粉絲會觸發這些動作，而 “all” 規則會在每則貼文上如此；這些活動現在會記錄為 skipped，與 DM 先前的行為相同。既有的自動化不受影響——具體的 postId 仍只比對該則貼文。請見常青規則。在限時動態觸發條件上，省略 storyId 的行為仍與 “all” 相同，但請優先使用明確的值：省略的用法將在未來版本淘汰，並會提前於 Upcoming API Changes 公告。
  • 9 月 24 日 - 對回覆貼文取得 X 留言，現在會回傳其回覆。先前向 Get Comments 請求本身為回覆的 X 貼文時，即使該貼文底下有自己的回覆，仍會回傳空清單，因為 Ayrshare 查詢了錯誤的對話。這類貼文現在會回傳其回覆。自行開啟對話的 X 貼文維持不變，仍會回傳與先前相同的所有內容。此外，當 X 以你自己的 X Developer 帳號為由拒絕讀取時，你現在會收到具類型的錯誤，而非空清單：X 點數耗盡時為 code: 416（HTTP 402），X 對請求施加速率限制時為 code: 364（HTTP 429），因此「點數用完」不再看起來像「沒有留言」。兩者皆不會被快取，所以你一修正原因，讀取就會重試；在多平台讀取中，回應為 status: “partial”，失敗的 X 分支會列在 errors[] 中，與其他失敗分支的處理方式相同。已刪除的貼文，或你的 X 憑證無法查看的貼文，仍會回傳空清單且不帶錯誤。請參閱錯誤碼 364 與 416。
  • 9 月 21 日 - Get Messages 在 X/Twitter 上也回傳有界分頁。未帶 limit 送出的 X/Twitter Get Messages 請求，現在最多回傳 100 則已儲存的訊息——或在使用 conversationsOnly 時最多回傳 100 個對話——並附上一個 meta.pagination 游標。這正是先前會在一次回應中回傳你整個儲存歷史的請求，因此從未跟隨游標的整合現在只會看到最新的 100 筆，必須跟隨 meta.pagination.next 取得其餘部分。只要 meta.pagination.hasMore 為 true 就繼續。status、action 與 conversationsOnly 仍適用於該請求，但現在是一次套用在一個有界的分頁上：經過篩選的分頁可能較短，或為空但 hasMore 仍為 true，因此請跟隨游標，而不要把較短的分頁當作結束。在 X/Twitter 上傳送 limit 的行為維持不變，仍會透過 X 自己的游標分頁讀取 X 的即時時間軸，而該方式不會套用上述三個篩選條件。游標現在會記錄它來自這兩者中的哪一組，因此跟隨游標時加上或省略 limit 都不會將你悄悄切換到另一組。
  • 9 月 21 日 - Google Business Profile 分析現已支援日期範圍與每日數值。社群網路分析現在會對 gmb 遵循 quarters 與 daily，與 Facebook、Instagram、Snapchat、TikTok 和 YouTube 既有的行為相同。傳入 quarters（1–4，每季 90 天）可針對近期的時間視窗產生報表，而不再是固定的過去 24 個月總計；傳入 daily: true 則會讓每個指標以逐日的 values 序列加上 total 回傳，讓你能以 Google Business Profile 的資料建立上個月或上一季的報表與時間序列圖表。先前這兩個參數在 gmb 上會被靜默忽略，只能取得 24 個月的總計。如果你已經在包含 gmb 的請求上傳送 quarters 或 daily，請留意：這些參數先前在此網路上會被忽略，因此同一個未變更的請求現在會回傳較窄的時間視窗；而在 daily: true 時，每個 gmb 指標會以 物件送達，而不再是單一數字——繪製圖表或加總這些數值的程式碼需要改讀 total（或 values 序列），而不是直接讀取指標本身。傳送 gmb 但未帶任一參數的請求則完全不變。當日期範圍生效時，回應也會帶有 quarters。
  • 9 月 21 日 - quarters: 0 現在在 Facebook 與 YouTube 上也代表全時期。在社群網路分析上，傳入 quarters: 0 的文件說明一直是「不套用日期範圍」——與省略該參數所取得的全時期資料相同——而 Instagram、Snapchat 和 TikTok 也確實如此運作。Facebook 與 YouTube 則不然：它們會將任何 quarters 值視為對日期範圍的請求，並悄悄回傳單一季度，因此 quarters: 0 在 Facebook 上得到的約是 85 天而非完整的時間視窗，而這些網路無法解讀為數字的值則完全無法回傳可用的時間視窗。兩者現在都與文件記載的行為以及其他所有網路一致。如果你會向 Facebook 或 YouTube 傳送 quarters: 0、負值的 quarters 或非數字的 quarters，請留意：同一個未變更的請求現在會回傳完整的全時期時間視窗而非單一季度，因此數字會變大，且回應涵蓋的期間也更長。傳送 quarters: 1 即可取得你先前意外得到的單一季度。quarters 為 1 到 4 的請求，以及完全省略該參數的請求，在所有網路上皆維持不變。
  • 9 月 18 日 - 在你自己的儀表板內連結社群帳號。Ayrshare Connect 小工具就是一個 script 標籤：載入它，在版面中每個網路所屬的位置放一個插槽，我們就會在那裡渲染一顆已經顯示該帳號是否連結的連結按鈕。在此之前，讓使用者連結帳號的唯一方式，是把他們送到我們代管的頁面，或自己動手建置——每個網路一個工作階段、在點擊處理常式中同步開啟的彈出視窗、一個 event.origin 檢查，以及帶緩衝時間的 popup.closed 輪詢，全都是在第一個帳號連結成功之前你必須做對的瀏覽器管線。小工具接手了這一切，還包括取消連結，並透過十個事件回報發生的事——其中包括 state，它在掛載時與每次變化時提供每個網路的即時帳號狀態，讓你永遠不必為此輪詢。以 —ayr-connect-* 設計 token 設定樣式；若你的頁面會送出 Content-Security-Policy，請加入 script-src 與 frame-src 項目。小工具需要 Max Pack。請參閱 Ayrshare Connect 小工具。
  • 9 月 17 日 - Get Messages 現在回傳有界的儲存歷史分頁。Get Messages 現在在 Facebook、Instagram 和 WhatsApp 上預設最多回傳 100 則訊息或對話。先前若省略 limit，可能會載入整個儲存歷史，耗盡伺服器記憶體，並以 503/504 錯誤中斷其他請求。預設值與最大值皆為 100；將 limit 設為 1 到 100 的整數可取得較小的分頁。若要取得更多內容，請將 meta.pagination.next 作為下一個請求的 next 參數傳入，並保持相同的使用者設定與篩選條件。只要 meta.pagination.hasMore 為 true 就持續請求，即使遇到較短或為空的篩選頁面也一樣。現有的回應欄位維持不變，但先前預期一次回應即包含全部歷史的 Facebook、Instagram 和 WhatsApp 整合現在必須跟隨游標。X/Twitter 的行為及其現有的可選供應商游標協定維持不變——X/Twitter 已於 9 月 21 日跟進，請見上方該條目。
  • 9 月 14 日 - 你的 X 與 Threads 選項現在也適用於 Thread。過去發布 thread 時，隨之傳送的選項幾乎全數會被捨棄。長影片是其中最明顯的案例：longVideo: true 搭配 thread: true 會在貼文送達 X 之前就以 code: 182 被拒絕——「140 seconds maximum」——因此長影片在 thread 中根本無法使用。現在它可以正常發布，並以 4 小時的長影片上限（而非標準的 2 分 20 秒）進行驗證。較不易察覺的另一半影響的貼文更多：altText、字幕、地區限制、replySettings、subscribersOnly 與 Pro Media 選項會被靜默地捨棄——thread 照常發布，選項則單純未被套用，且回應中沒有任何提示。在 Threads 上，allowCountries 也以同樣的方式被捨棄。這些選項現在全部都會套用。大多數會套用到 thread 中的每一則貼文；poll、quoteTweetId、replyId 與 replySettings 僅套用到第一則貼文，因為 X 只在那裡接受它們。altText 與字幕僅套用到第一則貼文的媒體——後續貼文的媒體會在沒有它們的情況下發布，因此暫時不要期待多媒體 thread 能有逐張圖片的描述。請參閱哪些選項適用於 thread。如果你已經在 thread 上傳送選項，有兩項變更需要你的注意。帳號無權使用的選項現在會讓 thread 失敗，而不是被忽略：從沒有 X Subscriptions 的帳號傳送 subscribersOnly 會回傳 code: 111 且不會發布任何內容，而先前該 thread 會公開發出。在 Threads 上，從 Meta 尚未賦予地區限制資格的帳號傳送 allowCountries 會回傳 code: 101 且不會發布任何內容，而先前該 thread 會在不受限制的情況下發出——請先檢查 /user 上的 isEligibleForGeoRestrictions。這兩者都與單一貼文一直以來的行為一致。最後，同時傳送 longPost 與 thread 現在會回傳一則警告，說明 longPost 已被忽略；該 thread 仍會發布，因為 thread 會將你的文字拆分成多則獨立貼文，無法以長文形式發布任何內容。錯誤碼 182、101、111 與 275 現在已記錄在錯誤碼中。
  • 9 月 14 日 - 為 Instagram Reel 附加授權音樂。你現在可以搜尋 Instagram 的音訊目錄，並在發布 Reel 時附加授權曲目。使用 GET /media/instagram/audio/search 尋找曲目，透過音訊查詢檢查你已有的曲目，然後在貼文中以 instagramOptions.audioConfiguration.audioId 傳入其 id。可選的 audioVolume 與 videoVolume（0 到 100 的整數）設定曲目與影片自身音訊的混音方式；省略它們時，Instagram 會套用預設值 100。你不需要 reels: true 或 isVideo: true——影片 URL 會自動被偵測為 Reel，並以相同方式接受音樂。音樂僅限 Reels：stories、圖片與輪播會回傳 code: 515。既有的 audioName 不變，仍然只設定影片中已有音訊的顯示名稱；若你同時傳送兩者，audioConfiguration 會勝出，audioName 會被捨棄，並在 postIds[].warnings[] 上回傳非致命的 code: 518 警告，貼文仍會發布。有一項需求要先確認：Meta 僅向透過 Facebook Login 連結的 Instagram 帳戶提供其 Audio API，而這需要一個已連結到該 Instagram 帳戶的 Facebook 專頁。以 Instagram Login（預設方式）連結的帳戶在每個音訊呼叫上都會回傳 code: 514，且沒有任何權限或方案可以改變這一點。切換方式請參閱音樂附加資格，以及錯誤碼 514 到 518。
  • 9 月 11 日 - Facebook 推廣廣告：行動呼籲按鈕、流量目標，以及類別感知的興趣搜尋。推廣貼文現在接受新的 traffic 目標（針對站外連結點擊進行最佳化），以及一個 callToAction 物件，用於在推廣貼文上要求顯示按鈕——APPLY_NOW、SHOP_NOW、LEARN_MORE 及另外六種——按鈕會開啟你指定的任何 URL。在儀表板中，選擇 Drive Traffic（推動流量）即可設定目的地 URL、按鈕類型與選填的標題。按鈕在現有貼文上如何呈現由 Meta 決定。callToAction 會在推廣回應中回傳，之後也可透過已推廣廣告端點在廣告上取得。興趣端點新增 specialAdCategories 查詢參數，讓住房、就業、金融或政治類活動可以只搜尋 Meta 允許其定位的興趣，而不必挑選日後導致廣告被拒絕的 ID。在這兩個端點上，financial_product_services 與 financial_products_services 現在被視為同一類別——credit（Meta 對它的舊名稱）亦然——因此本文件中的拼寫與你可能從 Meta 複製來的拼寫都可使用。有三項變更在符合你的情況時需要採取行動。第一，callToAction 先前在任何目標下都會被接受並被悄悄忽略，產生沒有按鈕的廣告；現在除非目標為 traffic，否則會回傳 code: 101。第二，推廣貼文端點上無法識別的 specialAdCategories 值先前會被捨棄，活動以未分類的方式建立，讓受監管的廣告在未聲明任何類別的情況下持續投放；現在會回傳 code: 101 並列出可接受的取值。第三，興趣端點在提供 specialAdCategories 時現在要求 accountId，因為 Meta 僅在廣告帳戶上提供類別感知的興趣搜尋——未帶 specialAdCategories 的興趣搜尋完全不變，仍然不需要 accountId。當你確實提供時，accountId 必須是數字（帶 act_ 前綴也可以）；其他任何值現在都會被拒絕並回傳 code: 101，而不是原樣送給 Meta。
  • 9 月 8 日 - 一次呼叫回傳每個網路的帳號狀態。GET /profiles 現在接受 include=state，它會為 User Profile 的每個社群網路回傳恰好一個正規化的 state——linked、unlinked、suspended、restricted、rateLimited 或 identityVerificationRequired——每個都帶有 actionable、message 與 helpUrl。先前你必須自己從 suspension、socialHealth 與 linkingErrors 區塊拼出同樣的全貌，並判斷哪個狀況優先。每個網路一定都會出現，因此從未連結的網路會回報 unlinked 而不是缺席，而 actionable 正是告訴你是否該向使用者顯示按鈕的欄位。需要 refId，因此這是單一 profile 的查詢。
  • 9 月 7 日 - 立即取消月付方案，並自動退款。從「Account」頁面取消月付訂閱時，現在提供第二個選項：方案於今天結束，款項會自動退回原付款方式，並以向你計費時所用的貨幣退還。若在扣款後 48 小時內取消，我們全額退還該筆付款；超過之後，我們退還計費週期中尚未使用的部分。無論哪種情況，儀表板都會在你確認前顯示相關金額。先前唯一的自助選項是在計費週期結束時取消，因此若要退款就得寄信給支援團隊，並等待人工計算處理。使用前有三件事需要了解：你的存取權限在確認的那一刻即終止，而非等到週期結束，這也會讓貼文、分析資料與已連結社群帳戶的刪除更早開始；尚未開立帳單的按量計費用量會另行計費，而不會從退款中扣除；且這是每個帳戶僅限一次的選項。年付方案仍於計費週期結束時取消。另外，若你最近一次付款失敗，取消現在會在任何方案上立即結束方案，而不是排定在稍後生效；若該筆付款首次失敗距你取消不到 48 小時，未付款的帳單會被作廢。請參閱如何變更或取消訂閱。
  • 9 月 7 日 - 較舊 LinkedIn 貼文的分析重新整理頻率降低，並由 nextUpdate 告訴你時間。發布超過大約十天的 LinkedIn 貼文，其分析現在會從快取提供，一次最長可達數天，而不再每十一分鐘重新擷取一次。貼文的互動大多發生在最初幾天；在那之後，同樣未變動的數字每天仍被重新擷取約 130 次，而 LinkedIn 對我們的應用程式每天可發出的分析請求數量設有跨所有帳號的總上限——因此這個上限被花在不可能改變的資料上。較新的 LinkedIn 貼文不受影響，維持相同的十一分鐘頻率，其他社群網路則完全沒有變化。所有地方共同的改變是：nextUpdate 現在會回報實際套用於你手上這份回應的間隔，而不再是固定的十一分鐘——在某些網路上，該間隔原本就已長於十一分鐘，只是先前未被準確回報。若你會輪詢，請從每份回應中讀取它，而不要使用固定的計時器。沒有任何欄位被移除或改名、沒有任何請求會被拒絕，且帳號分析仍保有自己的間隔。請參閱資料有多新。
  • 9 月 7 日 - 在使用者連結帳號的當下即刻得知。在建立 link session 時傳入 origin，在彈出視窗中開啟回傳的 url，你自己的頁面就會被告知裡面發生的事：帳號連結成功時是 connect:success，失敗時是帶錯誤碼的 connect:error，使用者中途退出時是 connect:cancelled。先前唯一能得知的方法是輪詢，或使用 redirect 參數讓你的頁面被導離並重新載入——這會遺失使用者眼前的所有狀態。事件會以 postMessage 傳送到該確切來源且不會送往其他任何地方，而 connect:success 只會在帳號儲存完成後送達，因此緊接其後的 GET /user 已經會顯示該連結。每次連結恰好送達一個結果事件。未帶 origin 建立的連結沒有任何改變，redirect 也維持與以往完全相同的運作，包括它的 origin=true 查詢參數——它與上述新的 origin body 參數無關，也沒有被棄用。如果你無法使用彈出視窗，取得 Link Session 現在也會回報 completedAt、lastCompletedAt 與 completedNetworks，這是不經瀏覽器的同一種訊號——也是 Telegram 唯一的訊號，因為它在頻外完成。請參閱連結完成事件。
  • 9 月 2 日 - Reels 現在接受帶有查詢字串的影片 URL。使用簽章 CDN 或 Firebase Storage 媒體 URL——也就是檔名後帶有 ? 查詢字串的任何 URL——發布 Facebook 或 Instagram Reel 時，先前會在貼文送達社群網路之前就以 code: 170 被拒絕，並回報媒體資產不正確，儘管影片本身是有效的。媒體類型現在會從 URL 的路徑讀取，因此像 https://cdn.example.com/reel.mp4?Expires=1756700000 這樣的 URL 會被辨識為影片並正常發布。你不再需要以 isVideo: true 作為因應方式——它仍然有效，而明確設定的 isVideo: false 仍會強制以圖片處理。若未帶 isVideo: true，路徑上沒有影片副檔名的 URL 的 Reel 仍會以 code: 170 被拒絕——但錯誤訊息現在會指明這正是原因，並指向 isVideo 而非媒體規範。同樣的修正也適用於 Facebook、LinkedIn、Pinterest 與 TikTok 上每則貼文的媒體數量限制（這些平台的影片上限低於圖片上限）：帶查詢字串的影片 URL 現在會計入影片上限而非圖片上限，因此一則貼文中包含兩支這類影片會被正確拒絕，而先前會被放行。請參閱媒體規範。
  • 9 月 2 日 - WhatsApp 現已列入支援的社群網路清單。WhatsApp 現在會出現在文件各處的支援社群網路清單與數量中，讓你不必刻意搜尋也能找到它。在 Ayrshare 上，WhatsApp 是一個訊息網路：透過 Messaging API 使用 GET /messages/:platform 取得對話與進站訊息，並使用 POST /messages/:platform 傳送訊息；可附加的內容請參閱 WhatsApp 媒體規範。本次發布並未變更 WhatsApp 的任何行為——改變的只有它在文件中所記載的位置。
  • 9 月 1 日 - Bluesky 影片最長可達 10 分鐘、最大 300 MB。Bluesky 已於 8 月 26 日提高其影片限制，Ayrshare 現已接受新的上限：Bluesky 影片現在最長可達 10 分鐘、大小可達 300 MB——高於先前的 3 分鐘與 100 MB。先前更長或更大的影片會在發布前就被拒絕，並回傳影片過長或影片過大的驗證錯誤，儘管 Bluesky 本身其實會接受該影片。你的發布方式完全不變：照舊送出相同的 mediaUrls 即可。完整需求請參閱 Bluesky 媒體規範。

​
2026 年 8 月

  • 8 月 31 日 - 無需 Private Key 即可建立社群帳號連結 URL，並可撤銷它們。建立 Link Session 只需你的 API Key 和一個 Profile-Key 即可建立社群帳號連結 URL——不需要 privateKey，也沒有任何東西需要簽署。先前每個連結 URL 都要求你傳送我們核發給你的 RSA private key，這意味著你得儲存它、每次呼叫時從磁碟讀取它，並在 PEM 中混入多餘換行時除錯 code: 189「no start line」錯誤。你現在還可以透過取得 Link Session 查看連結是否已被開啟，並透過撤銷 Link Session 在連結過期前終止它——過去發錯地址的 URL 會一直保持有效直到逾時，且沒有任何收回方式。產生連結 URL 繼續運作：privateKey、base64 與 verify 仍會被接受並且現在會被忽略，domain 仍為選填且仍會被驗證，你已發出的連結不受影響。如果你是將回傳的 url 原樣交給使用者，那麼對你而言完全沒有變化。有一種情況確實需要調整：token 現在是以 ayr_ls_ 開頭的不透明字串，而不再是可解碼的 JWT，因此透過解碼它來讀取 apiKey、profileKey 或 exp 宣告的整合會停止運作。到期時間請改從 expiresIn 欄位讀取；至於另外兩個值，請使用你原本就送出的值，因為 token 從來只是將它們原樣回傳給你而已。
  • 8 月 27 日 - Instagram 的 Generic Internal Error（通用內部錯誤）不再要求你重新連結。因 Meta error_subcode 2207085（「Generic Internal Error」，通用內部錯誤）而失敗的 Instagram 貼文，現在會先自動重試最長約 50 秒，然後才回傳該錯誤，且 code: 258 回應不再設定 relink: true。該旗標過去告訴整合方帳號已中斷連線，導致客戶取消連結並重新連結原本從未損壞的帳號——同一個帳號在多次失敗之間，仍以未變更的 token 持續成功發佈。請於幾分鐘後重試發佈該貼文；僅當錯誤持續超過 24-48 小時，才需要重新連結，或攜帶現在會在 details 中回傳的 fbtrace_id 聯絡 Meta 支援。請參閱錯誤碼。
  • 8 月 26 日 - Messages Webhook 現在會在社群連線中斷時告訴你。Facebook 或 Instagram 的訊息 webhook 現在會在我們無法從社群網路解析該訊息的中繼資料時，帶有 connectionDegraded: true。conversationId 與 senderDetails 是在每則訊息到達時查詢取得的，只要該查詢失敗就會設定此旗標——通常是因為 User Profile 的連線已過期或失效，但暫時性的 Graph API 錯誤也會設定它。先前唯一能察覺的方式是注意到這些欄位缺少，而一個只負責監聽的整合永遠不會發現；若某個 profile 的每則訊息都帶有此旗標，代表憑證已失效，若只出現在單一訊息上，則只是短暫波動。進站訊息在此期間仍會持續送達，因此不會遺失任何資料，但在旗標設定期間，透過 API 回覆與取得對話記錄也會失敗，因為兩者都需要同一份憑證。請將其視為需要該 profile 重新連結帳號的訊號。另外，Facebook 訊息現在會在連線降級期間，從你已儲存的訊息記錄中復原其 conversationId，讓進行中的對話串維持串接，而不會以未關聯的形式送達；Instagram 先前已如此。健康的連線上一切不變——該欄位會被省略，而不是以 false 送出。請參閱新訊息事件。
  • 8 月 25 日 - Webhook 傳遞現在能撐過 Endpoint 停擺。失敗的 webhook 傳遞先前只會重試兩次——分別在 5 秒與 30 秒之後——因此每次嘗試都會在大約 35 秒內結束。只要 endpoint 停擺超過這段時間，該事件就會永久遺失。暫時性失敗現在會在大約一小時內獲得最多 9 次傳遞嘗試——首次送出加上 8 次重試——之後再依遞減排程於約 5 分鐘、30 分鐘、2 小時與 12 小時後再次嘗試傳遞，因此傳遞最晚可能在原始事件後約 16 小時才送達。endpoint 在事故或維護視窗期間無法連線、逾時或回傳 5xx，不再讓你失去該通知。請注意，這取決於 endpoint 如何失敗：部署期間因路由尚未註冊而回傳 404，屬於拒絕而非暫時性失敗，仍會在第一次嘗試即視為最終結果。此機制適用於 429、408 與 425 回應、任何 5xx、逾時與連線中斷。其他任何 4xx——400、401、403、404、410——現在會在第一次嘗試即視為最終結果，因為重複送出一個被你的 endpoint 直接拒絕的請求，並無法改變結果；Webhook 歷史（Premium）會列出你近期的傳遞，讓你看出哪些失敗了——它是唯讀的，不會重新送出。由於重試現在最晚可能在許多小時後才送達，你的去重鍵必須至少保留 24 小時；更早過期的鍵無法辨識延遲抵達的重試，你會重複處理同一個事件。完整契約請參閱 Webhooks 概觀。
  • 8 月 24 日 - 留言與提及 Webhook 現在會攜帶 Ayrshare 貼文 ID。 comments 與 mentions webhook payload 現在會包含 postId——即事件所在貼文的 Ayrshare id，與你建立貼文時 Post 回傳的 id 相同。先前 payload 只帶有社群網路自身對該貼文的 id（Instagram 留言為 media.id、Instagram 提及為 media_id、Facebook 為 post_id），因此要將事件對應到你建立的貼文，就得自行維護原生 id 與 Ayrshare id 的對照表。現在可以捨棄這張對照表了。postId 為盡力提供，無法判定時會被省略，而不會以空值送出：例如貼文是直接在 Instagram 或 Facebook app 中建立而非透過 Ayrshare、貼文在此功能推出前就已發布（不會回溯補齊），或該貼文屬於連結到同一帳號的另一個 User Profile。在 mentions 上通常不會出現，因為提及一般發生在他人的貼文上。請將缺少 postId 視為「不是我的貼文」，而非錯誤。請參閱將留言關聯到你建立的貼文。
  • 8 月 24 日 - 留言與提及 Webhook 現在會標明所屬社群網路。 comments 與 mentions webhook payload 現在會攜帶一個 platform 欄位，指出事件來自哪個社群網路。這在 comments 上最為關鍵：Instagram 留言送達時帶有 id、text 與 media.id，而 Facebook 粉絲專頁留言則以 feed 變更形式送達，帶有 comment_id、post_id 與 message——因此同時為兩者註冊的 endpoint 過去只能靠出現的欄位名稱推斷來源網路。改用 platform（instagram 或 facebook）進行分支。在 mentions 上一律為 instagram，因為目前不會送達 Facebook 粉絲專頁的提及。其他欄位皆維持不變，因此你現有的處理程式可繼續運作。請參閱 Comments Action 與 Mentions Action。
  • 8 月 19 日 - 透過 API 編輯你的 WhatsApp 商家檔案。 更新使用者現在除了 gbp 之外也接受 whatsapp，讓你不必離開 Ayrshare 就能變更客戶在你的 WhatsApp 商家檔案上看到的內容：about、description、address、email、最多兩個 websites、位於 vertical 的商家類別，以及透過 profilePictureUrl 設定的商家檔案相片。只需傳送你想變更的欄位。商家檔案相片必須是正方形的 JPEG 或 PNG——建議使用 640×640——且 Ayrshare 會替你將它上傳至 WhatsApp，因此你只需要一個可公開存取的圖片 URL。WhatsApp 商家檔案會回傳你目前的商家檔案。你的 WhatsApp 顯示名稱無法在此編輯：它與你的電話號碼綁定，且需要經過 WhatsApp 自身的審核。
  • 8 月 18 日 - 媒體檢測服務故障不再歸咎於你的媒體主機。 如果 Ayrshare 在發佈前使用的媒體檢測服務無法連線或傳回無效回應，發佈現在會傳回可重試的 499，而不是把這次失敗轉換為 164，並要求你修改原本正常的媒體 URL、CDN 或 user-agent 規則。真正的媒體存取失敗仍會傳回現有的驗證錯誤。兩者的差異請參閱媒體抓取／爬蟲存取錯誤。
  • 8 月 18 日 - Analytics 現已支援 YouTube Engaged Views。 Post Analytics 與 Social Analytics 現在會針對 YouTube 回傳一個 engagedViews 欄位——即播放初始秒數之後才被計入的觀看次數。2026 年 8 月 24 日起，YouTube 會將其 views 指標改為從影片開始播放的當下就開始計算，且不設最低觀看時間，適用於所有影片格式——因此請預期 views 會在該日出現一次性的階梯式上升。若你的報表依賴先前的計算方式，請將這些報表切換為使用 engagedViews，它會沿用舊的計算方式持續計數。完整細節請參閱即將推出的 API 變更。
  • 8 月 17 日 - 你的品牌色現在也會套用到對話框主要按鈕。連結帳號對話框中的 Submit 與 Yes 按鈕，過去即使你的 CSS 檔案設定了 ，仍會保留 Ayrshare 由藍到粉的漸層——而該漸層完全無法從樣式表覆寫，因為它是位於任何你所設定顏色之上的背景圖片，且該按鈕在 CSS 上與旁邊的 Cancel 無法區分。現在它會以你設定的 作為單色使用，讓對話框中最醒目的控制項與你的品牌一致。按鈕上的文字，以及按鈕處理中顯示的載入圖示，會依據你的強調色自動選擇，在黑色與白色之間取較易閱讀的那一個；滑鼠停留時，強調色會往遠離文字顏色的方向調整，而不是一律加深，因此文字在該狀態下同樣清楚可讀。請依照它同時會上色的已選取圓鈕來挑選強調色，文字顏色會自動跟上。若你需要特定的文字顏色，例如你自己配色中的米白色或近黑色，請設定 ，它會覆寫自動選擇，並將對比度交由你自行負責。若你未設定 ，一切維持不變。
  • 8 月 17 日 - 排程的 Instagram 貼文現在會發布其第一則留言。單獨排程至 Instagram 的貼文，其 firstComment 過去會被接受，卻在發布時靜默地被丟棄：貼文照排程送出、留言從未出現，而且不會回傳任何錯誤。立即發布到 Instagram 一向都可運作，讓人以為問題出在排程，而不是留言本身。排程的 Instagram 貼文現在會以與立即發布相同的方式加入第一則留言。將 Instagram 與其他接受第一則留言的網路（例如 Facebook 或 LinkedIn）一起排程的貼文從未受到影響，立即發布的貼文行為也維持不變。若你先前透過手動加留言、或將這些貼文改為立即發布來因應此問題，現在可以恢復使用 firstComment 進行排程。
  • 8 月 17 日 - 新的 Suspended Webhook，用於 Profile 停權事件。註冊新的 suspended webhook 動作，就能在 User Profile 被停權或重新啟用的當下收到通知，而不必透過 403 回應才發現。suspend 事件在有記錄時會帶上 reason（例如 Facebook 的身份驗證要求）、在由社群網路造成時帶上觸發它的 platform、停權的 origin 以及時間戳；unsuspend 事件則會通知你 profile 已再度啟用，可恢復發文。註冊方式與其他任何動作相同，透過 註冊 Webhook，並可參閱 Suspended 動作文件了解 payload 內容。
  • 8 月 16 日 - 自訂 CSS 現在可為連結對話框上色。白牌連結帳號頁面上的對話框——解除連結確認、Facebook 與 LinkedIn 的頁面選擇器、Bluesky 與 X 的憑證表單，以及 Telegram 啟用碼輸入框——過去無論你的 CSS 檔案為何，都會以 Ayrshare 的預設淺色主題渲染，因此在深色的連結頁面上會開啟一個白色面板。現在有十個新的自訂屬性可為它們上色：、、、、、、，以及 、 與 。請將它們設定在 :root 上，而不是卡片上，因為對話框是在頁面內容之外渲染的。任何你未設定的屬性都會保留今天的顏色，因此既有的樣式表在你選擇加入前不會受到影響。完整清單與可運作的範例，請參閱 Linking Dialog Colors。
  • 8 月 15 日 - 在你的自訂 CSS 載入前不再閃現預設主題。使用你自己的 CSS 檔案的白牌連結帳號頁面，會在你的樣式表接手之前，短暫顯示 Ayrshare 的預設淺色頁面。若你的樣式表是深色的，那看起來就像每次載入都閃過一下白色——包含使用者每次從連結帳號流程回來時（因為會被帶回同一個頁面）。這個頁面現在會等你的樣式表就緒後才顯示任何內容，讓你的使用者永遠不會看到底下的預設頁面，而且它會記住你的樣式表，因此回訪時會立刻套用你的顏色，而不是等到你的檔案抓取完成後才套用。若無法讀取你的 CSS 檔案，這個頁面仍會正常載入而不會一直等待。未使用 CSS 檔案的連結頁面則維持不變。
  • 8 月 14 日 - 自訂 CSS 觸及 Connect Accounts 卡片的內部。白牌連結帳號頁面上的 Max Pack 自訂 CSS 現在再新增五個可用的 class 名稱：social-account-avatar 位於已連結帳號的個人頭像上、social-account-icon 位於承載某網路 logo 的方塊上、social-account-name 位於網路名稱上，以及 social-linking-page-column 與 social-linking-header 位於承載頁面的兩個容器上。這個欄刻意與 main-content 分開，讓你可以在不縮窄頁面背景的情況下加寬卡片；以 display: contents 攤平頁首之後，就能用 order 重新排序 logo、卡片、Close 按鈕與說明區塊。「Connected」與「Messaging」徽章也會讀取兩個自訂屬性 與 ，你可以在 social-account-card 上一次設定；「Relink required」等警告徽章仍保有自己的顏色，這樣一個已停止運作的帳號看起來仍然像是需要處理。若你的樣式表是透過計數元素或選取 Mui class 名稱來抵達這些元素，請以上述名稱改寫這些規則——只有這些名稱會持續運作。完整清單與範例，請參閱 Customize CSS。
  • 8 月 14 日 - 連結頁面上方有更多留白空間。白牌連結帳號頁面的內容會從頁面更下方開始，因此你的 logo 與標題不再緊貼瀏覽器視窗頂端。其餘位置皆未變動，且若樣式表已在 main-content 上設定 padding-top，該值會保留。
  • 8 月 13 日 - YouTube 頻道身分資訊加入 social webhook。 social webhook 現在包含一個選填的 account 物件，用於識別被連結或取消連結的特定社群帳號。YouTube 是第一個填入此物件的平台，因此對於 YouTube 連結，你不再需要額外呼叫 /api/user 來確認事件指的是哪個頻道：account.id 是頻道 id，account.title 是頻道名稱（不同於最上層的 title，後者仍然是你的使用者設定檔標題），另外還有 account.handle 與 account.profileUrl。每個鍵都是個別選填的（沒有自訂 URL 的頻道沒有 handle），且 account 會在 link 與 unlink 事件中傳送。所有既有欄位均維持不變。請參閱 Social action webhook 參考文件。
  • 8 月 12 日 - AI 揭露資訊可在圖片格式轉換後存活。當 Ayrshare 為不接受來源格式的網路將 WebP、HEIC、HEIF 或 AVIF 圖片轉換為 JPEG 時，圖片的 AI 揭露資訊現在會被帶過，而不會被丟棄。Ayrshare 會寫入一個小型全新的 XMP 封包，內含 Iptc4xmpExt:DigitalSourceType（IPTC 的 AI 揭露屬性），並且在 C2PA manifest 聲明 AI 來源但 XMP 並未記錄時合成等值的值。Facebook 與 Instagram 會僅根據該屬性顯示自己的 AI 標籤，無須設定任何平台端的 AI 旗標。其他資訊都不會被帶過：該封包是從頭建立而非複製，因此原始圖片的 EXIF、GPS，以及作者、版權、關鍵字或位置欄位都不會送達平台。無論如何色彩呈現都會被保留——HEIC 或 HEIF 圖片會保留其 ICC 色彩描述檔，而 WebP 或 AVIF 圖片會被轉換為標準 sRGB，讓即使在會捨棄內嵌描述檔的網路上色彩仍然正確。C2PA 加密簽章無法在重新編碼後存活，也不會被保留——揭露資訊存活，簽章則否。JPEG 與 PNG 圖片仍會原封不動地通過，影片不受影響，而 media 上傳會繼續原封不動地儲存你的位元組。請注意，Instagram 的 autoResize 選項會透過一個獨立步驟進行縮放，且不會攜帶任何 metadata，因此若揭露資訊需要送達 Instagram，請關閉此選項。完整政策與各平台結果，請參閱 圖片 Metadata 與 Content Credentials。
  • 8月12日 - LinkedIn Company Page 選擇不再逾時。 如果您管理著非常大量的 LinkedIn 公司頁面，連接 LinkedIn 時可能會在頁面選擇清單出現之前就逾時，導致沒有任何可選項——即便在下方 8月10日的探索改良之後也是如此。建立您的頁面清單現在快了許多倍，可以遠遠在請求上限內完成。另外，先前依 LinkedIn 回傳頁面的方式，某些頁面可能會被遺漏；這些頁面現在都會出現在清單中。
  • 8月11日 - 自訂 CSS 對連結帳號卡片排版的控制。 白牌的連結帳號頁面現在多帶有兩個 class 名稱可供你的 Max Pack 自訂 CSS 選取：位於承載社群網路卡片之 grid 上的 social-accounts-grid，以及位於承載每張卡片之格子上的 social-account-card-wrapper。這兩者共同控制卡片之間的間距以及每列可容納幾張卡片，這兩件事先前都沒有選取器可用。若你的樣式表是透過從 main-content 開始逐層計數（例如 .main-content > div > div > div）來抵達卡片區域，儀表板重建後這些規則會匹配到不同的元素，且可能一次調整所有卡片的大小；請改以上述兩個名稱重寫。你的規則仍需 !important 才能覆蓋頁面自身產生的樣式。詳細範例請見 變更卡片排版。
  • 8月11日 - 自訂 CSS 的連結頁面固定為淺色。 使用你自己的 CSS 檔案的社群連結頁面現在會固定為淺色配色，且不會再向你的使用者顯示其上的淺色／深色切換。樣式表是針對淺色頁面所撰寫，因此當使用者切換到深色時，雖仍保留你的顏色，但周圍的文字顏色會改變，可能導致你卡片上的社群網路名稱難以閱讀。現在頁面的外觀將完全由你的樣式表決定。沒有 CSS 檔案的連結頁面則維持不變，並保留該切換。
  • 8月11日 - 簡化的 Instagram 連結流程。 先前在連結頁面上點選 Instagram 時，會先跳出一個對話框，提示僅支援 Instagram Business 或 Instagram Creator 帳號，之後才開始登入。現在，Instagram 自身的登入流程會在授權過程中提示將個人帳號切換為專業帳號，因此這個多餘的步驟已經移除。點選 Instagram 會直接進入登入流程：若您啟用了 Instagram 自身的登入，就走 Instagram 登入；若您已停用 Instagram Login，則走 Facebook 登入。若您為連結頁面設定了自訂的 Instagram 彈窗，您的自訂說明仍會與先前完全相同地顯示。
  • 8月10日 - 連結帳號頁面上的自訂 CSS Class Hooks 已恢復。 白牌的連結帳號頁面再度帶有你的 Max Pack 自訂 CSS 所選取的穩定 class 名稱。頁面重建時這些 class 名稱曾被移除，因此既有樣式表雖仍會載入，卻靜默地什麼都匹配不到：例如原本用來隱藏頁面標題、重新設計 Close 按鈕、或替說明文字換色的規則就直接失效，且沒有任何錯誤訊息。已恢復於頁面上的：main-content、company-logo、heading-social-accounts、additional-info、additional-info__body、additional-info-text、troubleshooting-guide 與 close-button。已恢復於每張社群網路卡片上的：connected-card 與 click-to-link。此外新增：每張卡片上的 social-account-card、代表尚未連結狀態的 unlinked-card，以及帶有網路 key 的 data-platform 屬性，因此未連結卡片可被重新設計為按鈕；這在先前並不可能，因為在 CSS 中無法區分已連結與未連結的卡片。你的規則需要 !important 才能覆蓋頁面自身產生的樣式。完整清單與範例請見 CSS Class Hooks。
    • 檢查你的樣式表。 基於這些 class 名稱撰寫的規則不需你做任何變更即可再度生效。基於頁面自行產生的 class 名稱（任何你從瀏覽器開發者工具中複製的名稱，例如以 chakra- 開頭者）所撰寫的規則則無法恢復，需要改以文件中所列的選取器重寫。請參閱 更新較舊的樣式表。
    • 有一個較舊的 class 名稱不會回來。 linked-tag 刻意不屬於契約：已連結的卡片現在也可能顯示「Relink required」或「Identity check」，因此隱藏它的規則會把使用者需要處理的警告一併隱藏。請改為對 connected-card 設定樣式。請參閱 更新較舊的樣式表。
  • 8月10日 - 改良的 LinkedIn Company Page 探索。 如果您管理著大量的 LinkedIn 公司頁面，在連接或重新整理 LinkedIn 時，其中一些頁面可能會遺失——這些頁面無法被選取，也無法發文到這些頁面。公司頁面探索現在會讀取超過先前提前停止的位置，因此因此原因遺漏的頁面現在可供選取並發文。
  • 8月7日 - Dashboard 3.0。Ayrshare Dashboard 已從頭重建，採用現代化的設計系統、全新的導覽，並在每個頁面上提供更快、更簡潔的工作流程。
    • 深色模式與全新設計 —— 預設為深色模式，並可在側邊欄一鍵切換亮／暗主題，另有跨所有頁面的全新字體、卡片與版面配置，帶來更好的可讀性與資訊密度。
    • Billing，現已整合至 dashboard —— 全新的 Billing 區塊（取代原本的 Account 頁面）讓您無需離開 dashboard 即可管理訂閱：檢視目前方案、下次帳單日期與付款方式；變更方案、檢視發票並更新帳單資訊；並可直接啟用或管理附加服務（Max Pack、Messaging 與 Facebook Boost Ads）。
    • Publish a Post —— 網路切換選項具備即時選取數量、Select all / Deselect all，以及可將貼文僅發送至單一網路的 「Only」快捷鍵；View API Code（原 View JSON）會顯示您所編寫貼文的實際 API 請求；而更簡潔的 Additional Options 面板則會依情境顯示平台特定設定（如 Instagram Post Type）。
    • Post History —— 可與現有狀態篩選器（Success、Scheduled、Paused、Awaiting Approval、Error）並用來搜尋您最近的貼文，每則貼文皆有媒體縮圖，並在每張卡片上顯示平台圖示、狀態標籤、可複製的 Post IDs，以及可折疊的 API Request & Response 檢視器。
    • User Profiles —— 重新設計的個人檔案卡片，具備頭像與結構化欄位（Created、RefId、Accounts、Messaging）、新的角色徽章（Owner、Team Member 與 Active profile），並在每張卡片上提供內嵌的 Messaging 切換。
    • Webhooks —— 全新的 Events tab，可與您已註冊的 webhooks 並列檢視 webhook 事件記錄。
  • 8月6日 - TikTok 影片能見度修正。 tikTokOptions.visibility 選項現已對影片貼文生效。此前該設定僅對圖片貼文有效 —— 以 visibility: “private”、“followers” 或 “friends” 送出的影片會以 Public 發布，且不會回傳任何錯誤或警告。影片現在會依照要求的能見度發布，且 visibility 參數文件已更新以反映對影片的支援。
  • 8月6日 - Instagram AI 內容標籤。 Instagram 貼文現在可以透過在 instagramOptions 中將 isAIGenerated 設為 true，帶上 Instagram 的 AI info 標籤。此自我揭露適用於單張圖片、單支影片、Reels、Stories 與輪播 —— 對於輪播，標籤會套用於整個輪播而非個別項目。可接受的值為 true、“true”、false 和 “false”；其他任何值（例如 “yes” 或 1）仍會照常發布貼文但不會帶有標籤，並會回傳一則非致命的 warnings 條目（code: 497、feature: “isAIGenerated”），列出可接受的值。省略此參數的行為維持不變，會以無標籤的方式發布；貼文發布後，標籤無法再變更。該參數與現有的 tikTokOptions.isAIGenerated 一致，同一旗標名稱在兩個平台上皆適用。詳見 Instagram AI Content Label。
  • 8月4日 - X “Made with AI” 標籤。 X 貼文現在可以透過 twitterOptions.isAIGenerated 揭露 AI 生成的媒體，該欄位會套用 X 原生的 “Made with AI” 標籤。詳見 X posting options。
  • 8 月 4 日 - 針對企業主頁自然貼文的 LinkedIn 留言回覆。 使用社交留言 ID 回覆 LinkedIn 留言現已支援企業主頁的自然貼文，此前該操作會以 code: 215 失敗。在此模式下（searchPlatformId: true），請傳入 get-comments 回傳的完整 commentUrn，而非僅使用 commentId —— 例如 urn:li:comment:(urn:li:activity:<postId>,<commentId>)。詳見 Reply to a Comment 上新增的 commentUrn 參數。
  • 8 月 4 日 - 自動化 DM 失敗不再歸咎於你的存取權杖。當 Instagram 自動化無法將 DM 送達特定接收者時，活動列會記錄為 auth_error — 代表該帳號憑證失敗的狀態 — 導致客戶重新連結一個原本完全正常的帳號，而重新連結並不會改變任何事。每個接收者的送達失敗現在會記錄為 failed，並攜帶 Meta 自己的原因於 actionResults[].errorDetails，而 auth_error 則保留給真正的憑證與權限問題。最常見的原因現在有了專屬的終態：當觸發它的留言來自將要傳送 DM 的同一個帳號時 — 也就是你在自己的貼文上測試自動化時會發生的情況 — 該列會記錄為 skipped 並附上說明，且不會嘗試傳送，因為帳號無法傳訊息給自己。活動狀態與活動端點參考文件現在會準確描述每一種狀態。此變更之前記錄的資料列並未回溯修正，因此歷史上的 auth_error 資料列仍可能是上述情況之一。

​
2026 年 7 月

  • 7 月 31 日 - WhatsApp Messages 進入 Private Beta。Messaging API 現已於 private beta 支援 WhatsApp。已核准的帳號可透過 Meta 的 embedded signup 流程連結 WhatsApp Business Account，在 Meta 的 24 小時客服視窗內傳送自由格式訊息、接收進站訊息與媒體，並擷取已儲存的 WhatsApp 對話。若要申請存取權限，請寄信至 lotty@ayrshare.com。
  • 7 月 31 日 - Instagram Comments 與 Mentions Webhooks 不再需要 Messaging。Instagram 的留言（comments）與提及（mentions） webhooks 現在已完全獨立於 Messaging 附加元件。以 action: “comments” 或 action: “mentions” 註冊 webhook 時，會透過你既有的已連結帳號自動訂閱所需的 Meta 欄位 — 不需要 Messaging 附加元件，也不需要重新連結（留言權限已屬於預設授權範圍）。此功能適用於所有 Instagram 帳號類型，包含透過 Facebook Page 連結的帳號，且停用 Messaging 也不會再中斷仍在運作的 comments 或 mentions webhook。此變更僅適用於 Instagram 範圍；Facebook 的留言與提及事件尚未納入。請參閱 Webhooks overview 註冊 webhook。
  • 7 月 31 日 - 批次分析歸屬修正。在多篇貼文的貼文分析請求中，某個失敗項目可能會導致同一批次中後續的結果被記錄到錯誤的貼文 ID。現在即使批次中有部分項目失敗，結果也一律會正確歸屬到對應的貼文。
  • 7 月 31 日 - Instagram 分析 Post-ID 驗證。傳送至貼文分析的無效 Instagram 貼文 ID 現在會於本地端先被拒絕，不會對 Meta 發出任何呼叫，因此格式錯誤的 ID 不再會耗用 Meta Graph API 呼叫 — 與 Facebook、Threads 及 X/Twitter 現有的保護機制一致。純數字的貼文 ID 也會被妥善處理：全數字的 id 會正常通過驗證，而無法構成有效 ID 的值會回傳乾淨的 code: 186 錯誤，而不會是未處理的失敗。有效的字串 ID 行為則與先前完全相同。
  • 7 月 31 日 - n8n 起始工作流程更新。可下載的 n8n MCP 起始工作流程已更新：建議的第一個 prompt 現在只針對 LinkedIn 與 Facebook（先前的 prompt 包含 Instagram，因需要媒體而導致首次執行驗證失敗），且該工作流程的 chat model 現在改為 claude-sonnet-5，並附上與版本無關的設定說明。
  • 7 月 29 日 - Instagram 留言自動化改用 Private Reply。留言觸發的自動化（comment_keyword）現在會透過 Instagram 的 private reply 傳送 DM，並錨定於該留言本身的 7 天視窗。這移除了「需要既有對話」的要求，因此自動化現在可以觸及你從未傳送訊息過的留言者 — 也就是先前會阻擋陌生留言者的拒絕情境。留言自身的 7 天視窗仍然適用：對超過該時間的留言進行回覆會以 491 失敗。請注意，送達與否最終仍取決於接收者的 Instagram Message requests 設定：DM 可能會被 Instagram 接受（活動 status: “sent”）之後又靜默地被捨棄，且任何 API 層面都不會出現訊號。因此，sent 只代表 Instagram 接受了訊息，永遠不代表接收者收到了訊息。新的失敗原因會透過 actionResults[].errorDetails 顯示，並有專屬的錯誤碼 490–495。詳情請見新的 Automation DM Sent but Not Delivered 疑難排解指南。
  • 7 月 23 日 - 後量子就緒加密（PQC）。Ayrshare API 現已於 TLS 層支援後量子密碼學。我們已在全域 SSL 政策上啟用 X25519MLKEM768 混合式金鑰交換，在 TLS 1.3 交握中，於傳統 ECDHE 之外加入一種抗量子（ML-KEM）演算法。這能保護你的 API 流量免受「先蒐集、後解密」（harvest now, decrypt later）攻擊 — 亦即攻擊者今日先錄下加密流量，等量子電腦成熟後再行解密。此變更完全向後相容：由於採用的是混合式協商，只有在用戶端主動要求時，連線才會升級為 PQC；其他所有用戶端仍會以標準 ECDHE 正常連線。而且因為我們有 74% 的 API 流量已在 TLS 1.3 上，多數整合當下就能取得後量子保護，完全不需修改程式碼 — 只要你的 HTTP/TLS 函式庫支援 X25519MLKEM768 群組（OpenSSL 3.5+ 及其他現代 TLS 堆疊皆已支援），即會自動協商完成。
  • 7 月 15 日 - Instagram Reels 長寬比驗證修正。 高而窄的 Instagram Reels 不再於送達 Meta 之前被錯誤拒絕。Ayrshare 的上傳前影片檢查先前將 Instagram 圖片的長寬比規則（4:5 至 1.91:1，另加一個 9:16 直式例外）套用到 Reels，導致合法的直式 Reel（例如 886 x 1920，即 0.46:1 的寬高比）在本地就被以 code: 182 攔截，儘管 Instagram 本身會接受該影片。Reel 影片現在會依照文件記載的 Reel 範圍 0.01:1 至 10:1 進行驗證（仍建議使用 9:16 以避免裁切），符合 Meta 官方規範以及 Instagram 媒體指南。長寬比驗證失敗時的 code: 182 訊息也已修正——先前顯示為 “Video does not meet duration requirement.”（影片不符合時長需求。）無需任何 API 變更。
  • 7 月 14 日 - 多平台留言與分析讀取的部分成功。 多平台的 get-comments 或 post analytics 讀取（一個 Ayrshare Post ID 涵蓋多個平台）在單一平台的請求分支失敗時，整體回應不再被摺疊為錯誤。當至少一個分支成功且至少一個分支失敗時，回應會回傳 HTTP 200 且 status: “partial”，保留正常平台的資料，並在最上層的 errors[] 中逐一列出每個失敗的分支。全部成功的回應維持不變。全部失敗的回應仍保留 status: “error”，並將代表性的最上層錯誤碼對應到其設定的 HTTP 狀態；code 485 對應到 HTTP 404。Code 485 用於識別無法取得留言或洞察資料時，已過期或無法使用的 Instagram/Facebook Story 留言，以及 Instagram Story 分析；Facebook Story 分析仍然無法使用，不包含在內。用戶端應檢查 errors[]，並以數值 code 做比對，而非用完整訊息文字。
  • 7 月 8 日 - 更快的 API 回應時間。 我們發布了一輪後端效能改進，顯著降低了多個熱門端點的延遲。平均與 95 百分位（p95）回應時間都大幅下降，重載時提升最為明顯。最大幅度的改善出現在 profiles 與 analytics。無需修改 API 呼叫；每個請求現在都會自動變得更快。
  • 7 月 7 日 - generateJWT 提供每工作階段的 Instagram 連結方式。 generateJWT 端點現在接受可選的 instagramLinkMethod body 參數，可為單次連結工作階段覆寫你帳號層級的 Instagram Login 設定。傳送 “instagram” 以啟動直接 Instagram Login（無需 Facebook 粉絲專頁），或傳送 “facebook” 讓使用者在社群連結頁面點擊 Instagram 按鈕時透過已連結的 Facebook 粉絲專頁完成連結。此覆寫僅對由回傳的 JWT URL 開啟的連結頁面生效——會在授權跳轉後仍然保留，但永遠不會變更你帳號層級的設定；不提供該參數則維持既有行為。無效值會回傳 400 並列出有效選項。詳情請見新的 Instagram Link Method 一節，包含兩種流程之間的功能差異。

​
2026 年 6 月

  • 6 月 24 日 - n8n 整合。 透過 n8n 內建的 MCP Client Tool 節點連線至 Ayrshare MCP Server，無需自訂程式碼，也無需安裝社群節點。可查看新的 n8n 整合頁面取得概觀，或前往完整 n8n 指南了解設定、三個範例、多租戶 profile、X BYO，並下載入門工作流（Chat Trigger → AI Agent → Ayrshare MCP 節點）。另請參閱 Connect & Setup 與 Tool Catalog。
  • 6 月 17 日 - Facebook Analytics：Meta 停用 Reach 與 3 秒影片指標。 Meta 已在所有 Graph API 版本中移除 unique-impression 與 3 秒影片觀看的 Insights 指標（於 2026 年 6 月 15 日生效）。Facebook post analytics 不再回傳 impressionsUnique、impressionsFanUnique、impressionsOrganicUnique、impressionsPaidUnique 或 videoViewsUnique，而 social analytics 不再回傳 pagePostsImpressions* 系列（包含 pagePostsServedImpressionsOrganicUnique）。仍受支援的欄位（reactionsByType、videoViews、mediaView、pagePostEngagements、pageVideoViews）不受影響。reach 請改用 mediaView / pageMediaView；Total Unique Media Views 的後續替代指標已規劃中。參考：Meta Graph API v25 changelog。
  • 6 月 15 日 - Facebook 帳號限制錯誤碼 476。 因 Meta 對帳號設下限制（Meta subcode 2424009 與 1404078，或錯誤未帶 subcode 時 Meta 的限制措辭）而失敗的 Facebook 貼文，現在會回傳專屬且不可重試的 code: 476（HTTP 400），而非通用且可重試的 code: 108。帳號仍保持連結——請透過 Meta 的 Account Status 頁面（Facebook → 個人檔案照片 → Help → Account Status）處理限制，該頁面會顯示具體原因與 API 無法回傳的申訴流程。詳情請見 Facebook 帳號限制。
  • 6 月 10 日 - LinkedIn 個人檔案分析。 LinkedIn 個人（member）檔案現在會回傳擴充的分析矩陣。Post analytics 包含 impressionCount、uniqueImpressionsCount（觸及的成員數）、likeCount、commentCount、shareCount、engagement、reactions，以及對於影片貼文的 videoViews、videoViewers 與 videoWatchTimeMs。Social analytics 新增 lifetime followersCount、每日 followersDaily 成長與彙總的貼文指標。彙總的 reshare/reaction/comment 計數為盡力提供，可能與 LinkedIn UI 略有不同。既有已連結的帳號需在 Social Accounts 頁面重新連結其 LinkedIn 檔案以授與新的分析 scope——在完成前，分析會回傳 code: 475（「re-link your LinkedIn profile to enable analytics」）。發布不受影響。
  • 6 月 10 日 - TikTok 第一則留言現在改為事件驅動。 TikTok 貼文的第一則留言不再透過固定的定時等待嘗試。由於 TikTok 是非同步處理影片，/post 回應中的 TikTok 第一則留言現在會以 status: “pending” 回傳，並在 TikTok 處理完成、且 tikTokPublished webhook 解析出實際 video id 後自動發布。影片 visibility 必須為 public，否則會回傳明確的留言錯誤。另外，對仍在處理中的 TikTok 貼文執行 get-comments 現在會回傳 code: 288，而非一般性錯誤。
  • 6 月 8 日 - Webhook 簽章密鑰輪替。 你現在可以從 Webhooks 儀表板 以 2 次點擊，或透過新的 POST /hook/webhook/secret 端點搭配 secret body 參數，安全地輪替你的 Webhook 簽章密鑰。輪替之後，傳遞會透過新的 X-Authorization-Content-SHA256-V2 標頭在 24 小時的寬限視窗內同時以你的舊密鑰與新密鑰簽章（v1=<current-sig>,v1=<previous-sig>，current 在前），讓你能在不遺漏或拒絕任何傳遞的情況下更新接收端。既有的 X-Authorization-Content-SHA256 標頭維持不變。簽章密鑰為 profile 層級（每個 User Profile 一組，會為該 profile 上的每一個動作簽章）。安全輪替流程與接收端驗證範例請參閱 輪替簽章密鑰。
  • 6 月 8 日 - YouTube 縮圖失敗現在會回報。 當 YouTube 影片發布成功但自訂縮圖套用失敗時，YouTube 結果會保留 status: “success”（影片仍上線），並新增 warnings 陣列（feature: “thumbnail”、code: 307）描述失敗——先前失敗被埋在 thumbNail 子物件中，為向後相容仍保留該子物件。誤導性的 403 指引已更正，改為優先建議在 https://www.youtube.com/verify 完成頻道電話驗證（未驗證頻道是最主要原因），OAuth 重新連結為次要步驟。新的發布前驗證也會攔截非 PNG/JPG、超過 2MB 或無法存取的縮圖並跳過，影片仍會發布並在 warnings 中回報原因（縮圖問題永遠不會讓貼文失敗）。詳情請見 YouTube Post API 與新的 YouTube Thumbnail Not Applied (Unverified Channel) 疑難排解指南。
  • 6 月 8 日 - X BYOK Analytics 於點數耗盡時改回傳 Code 416。 當 X/Twitter BYOK 帳號註冊的 X Developer 帳號沒有 API 點數時，analytics 與 user-lookup 路徑現在會回傳 code: 416（HTTP 402，X CreditsDepleted），並在 detail 中帶入註冊帳號 id——先前這些被遮蔽為 code: 294（HTTP 400，「Unable to get X User」）。修正方式是到 X Developer Portal 儲值點數。此變更讓 analytics/lookup 表面與發布路徑（原本已回傳 416）一致。若你的整合是以 analytics 的 294 判斷 handle 錯誤，請加上對 416 的處理。
  • 6 月 4 日 - MCP Server 與 Claude Code 外掛。 AI 代理現在可以透過新的 MCP Server（https://api.ayrshare.com/mcp）驅動 Ayrshare API，包含 Claude Code 外掛。請參閱 Connect & Setup 與 Tool Catalog。既有的 docs-search MCP 現在稱為 Documentation MCP。

​
2026 年 5 月

  • 5 月 22 日 - Bulk Post Profile-Key 路由修正。 POST /post/bulk 現在會遵循 Profile-Key 標頭，因此 CSV 列會發布到解析後的 User Profile，而非 Primary Profile。先前帶 Profile-Key 的大量上傳會被靜默轉送到 Primary Profile 的社群帳號。詳情請見 Bulk Post。
  • 5 月 21 日 - TikTok DELETE /comments 範圍已釐清。 已更新 Delete Comments 與 Comments Overview 頁面，說明 TikTok 的 DELETE /comments 只能成功刪除由已驗證的 TikTok 帳號本身留下的留言（你自己的回覆）。嘗試刪除第三方的留言會回傳 Ayrshare code: 328。若需要在自己的 TikTok 影片上審核第三方留言，請聯絡支援。API 行為未變更；僅為文件更新。
  • 5 月 21 日 - 隱藏 TikTok 留言。 DELETE /comments 現在支援搭配 videoId 使用 hide=true 對公開觀眾隱藏 TikTok 留言。成功回應會回傳 action: “hide” 並回顯留言文字；若送出 hide=true 但未帶 videoId，會以 400 拒絕。被隱藏的留言在 TikTok Studio 中對影片擁有者仍可見。
  • 5 月 20 日 - Node SDK v1.3.0——X/Twitter BYO 支援。 官方 Node SDK 現在提供 setTwitterByo(apiKey, apiSecret) 與 clearTwitterByo()，用於 X/Twitter Bring-Your-Own-Keys。設定後，每個 SDK 請求都會包含必要的 X-Twitter-OAuth1-Api-Key 與 X-Twitter-OAuth1-Api-Secret 標頭——這對 X/Twitter 操作是必需的，因為 Ayrshare 的 BYO 要求已強制執行（自 2026 年 3 月 31 日起）。透過 npm install social-media-api@1.3.0 安裝；發行說明請見 npm 與 GitHub。
  • 5 月 20 日 - Messaging 計量計價。 Business Messaging 現在透過 Stripe 計量計價，在 Launch 與 Business 方案為每個活躍對話 0.09</code>（Premium維持每月定額<code>0.09</code>（Premium 維持每月定額 <code>49 加購方案），每個計費週期最多可達 1,000 個活躍對話。詳情請見 Messaging 計價。
  • 5 月 20 日 - Instagram Analytics 不再因權限錯誤取消連結。 當 Instagram analytics 遇到缺少權限的錯誤（Meta errCode 10）時，帳號不會再自動取消連結。先前 scope/權限問題被當成 token 被撤銷處理，即使發布仍可正常運作也會靜默解除帳號連結。Ayrshare 現在會保留帳號連結，改為呈現權限 scope 錯誤。
  • 5 月 19 日 - 每個 profile 的 hideLogo。 Create Profile 與 Update Profile 新增 hideLogo 布林值，用於在個別 User Profile 的社群連結頁面上抑制帳號層級的 logo。適用於為個別合作夥伴 profile 做 white-label。
  • 5 月 19 日 - Facebook Boost Ad Set 預算共享。 Boost 端點 現在接受新的可選 adSetBudgetSharingEnabled 布林值（預設 false）。Meta 現在要求所有未使用 campaign-level 預算建立的 campaign 都必須在有線欄位中提供此值，Ayrshare 會在每個請求中送出——預設 false 可保留先前行為，呼叫端不需修改。將其設為 true 可啟用 Meta 的跨 ad set 最佳化，可將某個 ad set 的預算最多轉移約 20% 到同一 campaign 中的其他 ad set，以獲得更好的整體效能。
  • 5 月 19 日 - Reddit 被禁 subreddit 錯誤。 發文至你被禁止發文的 subreddit 現在會回傳明確的不可重試錯誤，而非一般可重試的 code 121。這可避免排程器對永久被拒絕的貼文陷入重試迴圈。詳情請見 Ayrshare 錯誤碼。
  • 5 月 19 日 - Bluesky 影片大小限制。 Bluesky 影片上傳大小上限現為 100 MB（先前宣稱 1 GB），以符合 Bluesky 的平台上限。超過 100 MB 的檔案現在會在前端就被拒絕，而不會在上傳後期才失敗。請參閱 Bluesky 媒體規範。
  • 5 月 19 日 - 儀表板 X/Twitter Messaging 支援 BYO Keys。 Ayrshare 儀表板 Messaging 頁面現在支援 Bring-Your-Own-Keys（BYO）帳號的 X/Twitter 私訊。你的 X consumer key 與 secret 會在瀏覽器內於工作階段中收集，並隨 send、refresh 與 image-fetch 動作一起傳遞——不會儲存任何金鑰。由於 Ayrshare 上的 X/Twitter 現已為 BYO 專屬，因此為必需項目。
  • 5 月 19 日 - Facebook Ads Cities 定位修正。 Facebook Ads Cities 端點（GET /ads/facebook/cities）現在能正確解析城市及其相關地區資料。每筆結果會包含 region、regionId 與 supportsRegion，可在城市有對應地區時用於定位。可使用 search 查詢參數以部分或完整城市名稱查詢。
  • 5 月 18 日 - YouTube Status 欄位控制。 YouTube Post API 的 youTubeOptions 新增三個可選參數：license（“youtube” 或 “creativeCommon”）、embeddable（布林值）與 publicStatsViewable（布林值——控制觀看頁面上的延伸統計面板；基本觀看與按讚數不受此設定影響仍為公開）。/history/youtube 回應現在也會回傳這些欄位。兩個新的驗證錯誤碼——455（無效的 license）與 456（無效的 embeddable 或 publicStatsViewable）——會在 Ayrshare 邊界拒絕格式錯誤的請求。不包含變現切換（啟用／停用廣告）；這些需要 YouTube CMS 憑證，且無法透過標準 YouTube API 使用。
  • 5 月 18 日 - GMB 第一則留言不再遮蔽貼文成功狀態。 修正一個問題：在 Google Business Profile 貼文中包含 firstComment 時，即使貼文已成功，也會回傳 code: 163 且沒有 postIds。Google Business Profile 不支援貼文留言，因此現在 GMB 會略過 firstComment，並正常回傳成功的貼文結果。
  • 5 月 14 日 - 防止帳號取消連結。 社群網路正悄悄推出更嚴格的反機器人控制，導致異常多的使用者帳號被取消連結。我們推出了多項後端改進以減少取消連結並釐清錯誤訊息，並更新帳號連結頁面讓 UI 更清楚——包含 Meta 網路（Facebook、Instagram、FB Groups、Threads、Messenger）在遭遇身份驗證懸置時新增的「Action required」狀態，附帶「Resolve with Meta」連結與「Check again」偵測，讓使用者無需取消連結再重新連結就能解決問題。
  • 5 月 12 日 - Instagram 互動自動化（Beta）。 新的Automations API讓你的使用者可對 Instagram 互動自動反應——當終端使用者對貼文留言、回覆限時動態、傳送私訊或對私訊做出反應時，觸發 DM、webhook 或 email。四種觸發類型（comment_keyword、story_reply、dm_reaction、dm_keyword）與三種動作類型（send_dm、fire_webhook、send_email）——每條規則各類最多 50 個。包含每個動作 7 天去重（可透過 dedupWindowMinutes 逐個動作設定）、每日 DM 上限（Launch & Business 1,000／Enterprise 5,000），以及游標分頁的活動日誌。適用於 Launch、Business 與 Enterprise 方案。新錯誤碼 462–472 涵蓋驗證、方案分級、活躍自動化上限、缺少已連結帳號，以及功能旗標的加入。Beta——我們正在積極收集回饋；請將錯誤回報與功能需求傳送至支援。
  • 5 月 12 日 - 排程貼文吞吐量改進。 我們新增了更多處理排程貼文的硬體，顯著改善吞吐量與效能。我們也將很快為 YouTube 與 TikTok 增加更多平台專屬硬體。
  • 5 月 12 日 - Instagram 帳號狀態錯誤的重新連結提示。 某些 Instagram 帳號狀態失敗（Meta error_subcode 2207085，先前以無指引的通用 code: 258 呈現）曾回傳 relink: true 與 retryAvailable: true，並附上修復訊息指示使用者取消連結並重新連結 Instagram 帳號並授與所有權限。此行為已被取代：2207085 現在會自動重試，且不再設定 relink: true。詳情請見錯誤碼。
  • 5 月 11 日 - YouTube 暫時性錯誤碼。 因暫時性上游問題而失敗的 YouTube 上傳現在會回傳新的 錯誤碼 453（HTTP 504，Google 匯入逾時）與 454（HTTP 503，服務不可用），並帶有 retryAvailable: true 旗標，你的整合可用於 自動重試。詳情請見錯誤碼。
  • 5 月 11 日 - X/Twitter Analytics 與 Lookups 對所有 BYO 使用者開放。 舊版的 X 加購方案限制已從 /analytics/social 與 /lookups/x 中移除。任何 X/Twitter Bring-Your-Own-Keys 客戶現在都可以查詢任意 handle 的分析並使用 X lookups 端點，而不會遇到 code: 3。呼叫會以你自己的 X Developer App 憑證簽署，並計入你自己的 X 速率限制。
  • 5 月 8 日 - Python SDK v1.3.0——X/Twitter BYO 支援。 官方 Python SDK 現在提供 set_twitter_byo(api_key, api_secret) 與 clear_twitter_byo()，用於 X/Twitter Bring-Your-Own-Keys。設定後，每個 SDK 請求都會包含必要的 X-Twitter-OAuth1-Api-Key 與 X-Twitter-OAuth1-Api-Secret 標頭——這對 X/Twitter 操作是必需的，因為 Ayrshare 的 BYO 要求已強制執行（自 2026 年 3 月 31 日起）。透過 pip install —upgrade social-post-api 安裝；發行說明請見 GitHub 與 PyPI。
  • 5 月 4 日 - 自動圖片格式轉換。 WebP、HEIC 與 AVIF 圖片現在會在發布至不接受這些格式的平台前自動轉換為 JPEG。WebP 轉換適用於 Instagram、LinkedIn、TikTok、Google My Business、Threads 與 Snapchat。HEIC 與 AVIF 會在所有支援的平台上進行轉換。不需修改 API；轉換會在發送時透明執行。三個新錯誤碼——450（轉換失敗）、451（來源下載失敗）與 452（已轉換圖片上傳失敗）——會在轉換無法完成時出現。
  • 5 月 4 日 - Instagram 錯誤現在包含 Meta 的原始訊息。 Instagram 媒體狀態失敗現在會在 details 欄位中隨 Ayrshare 錯誤碼一起呈現 Meta 底層的錯誤文字，讓呼叫端能區分原因（例如 robots.txt/爬蟲問題 vs. token 問題），無需從一般的錯誤碼猜測。詳情請見 Instagram Post API 與錯誤碼。

​
2026 年 4 月

  • 4 月 30 日 - API Explorer 中的 X/Twitter BYOK。 Ayrshare API Explorer 現在包含可折疊的 X/Twitter BYOK (Bring Your Own Keys) 區段，讓你只需貼上 X API Key 與 API Secret 一次，就能在每個外送請求中自動附加 X-Twitter-OAuth1-Api-Key 與 X-Twitter-OAuth1-Api-Secret 標頭——不再需要退出 Explorer 改用 curl 或 Postman 才能測試 BYOK。值透過 sessionStorage 只保留於目前瀏覽器分頁，預設會被遮蔽並可切換顯示，也可一鍵清除。取得憑證的方式請見 X BYO Key 設定指南。
  • 4 月 28 日 - Social Analytics 增強（陸續推出）。 Social Analytics 端點將加入 Instagram shareCount（90 天滾動視窗中的總分享數）與 YouTube lifetimeLikes（透過 youtube: { lifetime: true } 開啟）；新欄位會在部署到達你的帳號時出現在回應中。本次更新包含文件更正：Instagram viewsCount 是 90 天滾動視窗（非 180 天），mediaCount 一律為 lifetime，YouTube likes 的範圍是依 quarters，而 TikTok profile 層級指標上限為 60 天，使用 quarters 時每個貼文則帶有 lifetime 語意。
  • 4 月 28 日 - Instagram Trial Reels。 /post 端點現在支援發布 Instagram Trial Reels——首次發布時僅對非追蹤者可見的 Reels。將 instagramOptions.trialParams.graduationStrategy 設為 “MANUAL”（從 Instagram app 內畢業）或 “SS_PERFORMANCE”（Meta 依早期表現自動畢業）。三個新的驗證錯誤碼——447、448、449——會在 Ayrshare 邊界拒絕無效的 trial-reel 請求。
  • 4 月 24 日 - Instagram 發布可靠性。 擴充了尖峰時段的 Instagram 自動重試處理，並全面改善錯誤訊息。你現在不會收到一般錯誤，而是針對速率限制（code: 435）與媒體處理逾時（code: 436）收到具體的錯誤碼——讓你在整合中更容易診斷問題並建立更聰明的重試邏輯。
  • 4 月 23 日 - Facebook Analytics 速率限制錯誤碼 444。 Facebook 粉絲專頁 per-Page 的分析節流（Meta error 80001）現在會在 post 與 social analytics 回應中回傳 code: 444（HTTP 429）。先前這些節流被誤分類為 code: 161（「relink your account」）。若你的整合是以 161 觸發重新連結流程，請更新為辨識 444 並以退避重試。詳情請見 Facebook Analytics 速率限制。
  • 4 月 23 日 - Meta 媒體爬蟲疑難排解。 新的說明中心指南教你修正錯誤 code: 440（「social network could not download media from this URL」）以及相關的 Instagram code: 138 / Threads code: 379，這些皆為 robots.txt 或 bot 規則阻擋 Meta 發布爬蟲所導致。詳情請見 Meta 媒體爬蟲被封鎖。
  • 4 月 21 日 - 內容審核輸入錯誤現在回傳 400。 POST /validate/moderation 現在對呼叫端輸入問題（例如以不支援的檔案作為 imageUrl，或網址無法存取／格式錯誤）回傳新的 code 438（HTTP 400），而非誤導的 500 與重試指引。真正的處理失敗仍會回傳 code 331（HTTP 500）。詳情請見錯誤碼。
  • 4 月 20 日 - 內文優化錯誤碼 441。 Post 端點在諸如 shortenLinks 的內文優化失敗時現在會回傳 code: 441（HTTP 502）。當失敗僅影響部分平台時，成功的平台仍會發布並出現在 postIds 中，同時最上層 status: “error” 且 errors[] 會包含各平台條目。詳情請見 內文優化錯誤。
  • 4 月 15 日 - Instagram 失效 token 偵測。 因無效／過期 OAuth token 或 page-role/權限錯誤（Meta subcode 492）而失敗的 Instagram 貼文，現在會回傳 Ayrshare code 161（授權錯誤），並自動取消受影響帳號的連結以通知使用者重新連結，取代先前誤導性的 code 138「please try again」回應。詳情請見錯誤碼與 Instagram Post API。
  • 4 月 9 日 - Instagram 與 TikTok Analytics 全時期資料與日期篩選。 social analytics 端點在未指定 daily 或 quarters 時，現在會回傳 Instagram 與 TikTok 的全時期資料。使用 quarters（1–4，其中 1 = 90 天）或 daily=true 按日期範圍篩選——現在也支援 TikTok。啟用時，TikTok 的留言、分享與觀看的期間標籤與總數會反映篩選後的日期範圍。
  • 4 月 9 日 - Analytics 可靠性與復原。 Social Analytics 與 Post Analytics 端點現在會在社群網路暫時回傳 0 時，自動從儲存的資料回補累計指標（followers、likes、views）。兩個新的可選回應欄位 backfilledFrom 與 recoveredFrom 會指出何時使用了儲存資料。此外，當沒有任何平台回傳資料時，請求分析現在會回傳 400 錯誤（code: 187），而非空的成功回應。
  • 4 月 1 日 - generateJWT 標頭式 X 憑證。 Generate JWT 端點現在接受 X-Twitter-OAuth1-Api-Key 與 X-Twitter-OAuth1-Api-Secret 標頭來傳遞你的 X consumer key——與其他所有 X/Twitter 端點一致。為了向後相容，仍支援 body 參數。

​
2026 年 3 月

  • 3 月 30 日 - X 點數耗盡錯誤顯示。 當 BYOK X/Twitter Developer 帳號用完 API 點數時，先前會卡在 processing 而無錯誤的貼文現在會正確失敗並回傳 code: 416（X Credits Depleted，HTTP 402）。對 code: 416 的偵測也已擴充，涵蓋 X 提及點數的 HTTP 429 回應。詳情請見錯誤碼。
  • 3 月 28 日 - Instagram 貼文 null 回應修正。 修正一個邊界情況：Instagram 貼文在平台上發布成功，但 /post 回應卻回傳 null，而非正常帶有 postIds 與 id 的成功內容。Instagram 成功發布現在一律會回傳你的整合可解析的有效回應。
  • 3 月 26 日 - Instagram 每日 reach 修正。 修正 Instagram Social Analytics 在設定 daily=true 時遺漏每日 reach 資料的問題。回應現在在 daily 模式下會回傳巢狀的 reach 物件（包含 period 與 values 時間序列）；純量 reachCount 在非 daily 模式下仍會回傳，並在 daily 資料暫時不可用時作為後備保留。
  • 3 月 26 日 - X/Twitter BYOK 強制執行錯誤碼。 隨著 Bring Your Own Keys 要求開始強制執行，X/Twitter 請求會回傳可供你分支處理的特定錯誤碼：419（HTTP 400，缺少 X-Twitter-OAuth1-Api-Key/Secret 標頭）、416（HTTP 402，X Developer 帳號沒有點數）與 417（HTTP 403，OAuth 1.0a app 權限未設為 Read/Write/DM）。訊息與解決方式請見錯誤碼。
  • 3 月 23 日 - X 上的關鍵字搜尋。 BYOK 客戶適用的新關鍵字搜尋端點。在 X/Twitter 上搜尋符合關鍵字、hashtag 與進階搜尋運算子的推文。支援分頁、依語言與地點篩選，並回傳標準化的推文資料。
  • 3 月 23 日 - 監聽區段。 新增Listening 區段，擴充自 Brand 端點並加入關鍵字搜尋等新功能。
  • 3 月 19 日 - 留言中的 @Mentions。 在 Post a Comment 與 Reply to a Comment 端點的 comment 文字字串中新增 @mention 支援文件。包含 LinkedIn 伺服器端解析細節與各平台 mention 語法的連結。
  • X/Twitter 分頁訊息。 Get Messages 端點現在支援 X/Twitter 的 limit 查詢參數，允許你只取得最近 N 則訊息（1–100），無需完整歷史同步。與透過 next 參數的游標分頁結合使用，可以有效率地輪詢——先取一小批、檢查是否已擁有這些訊息，只在需要時再翻頁。
  • 影片大小上限提升。 由於社群發布現在大量聚焦於影片內容，我們提高了多個平台的影片上傳上限：LinkedIn（200 MB → 500 MB）、TikTok（1 GB → 10 GB）、X Premium long video（1 GB → 16 GB），並為 Facebook（Reels 2 GB、Stories 4 GB、Feed 10 GB）與 Pinterest（2 GB）新增更大且依內容類型區分的上限。完整資訊請見 Media Guidelines。
  • X/Twitter Messages 支援 BYO Key。 Get Messages 與 Send Message 端點現在支援 BYO（Bring Your Own）X/Twitter API 憑證。透過 webhook 的即時 DM 通知對 BYO 使用者不可用；請改用 GET Messages 端點輪詢。
  • X 上的 Bring Your Own Keys。 X/Twitter 帳號連線方式的重大變更。新的 Bring Your Own Keys 方式讓你對帳號有更多控制、更好的資料可攜性以及全新的 OAuth 流程。所有使用者需於 2026 年 3 月 31 日之前完成轉換。
  • 可編輯的短連結。 你現在可以在短連結發布後更新短連結。
  • 排程貼文處理的可靠性。 修正排程貼文處理工作可能耗盡記憶體並回傳 503 錯誤的問題。已增加資源配置、新增分頁查詢處理，並引入分散式應用鎖以避免重複執行——確保所有排程貼文處理都有單次且可靠的執行。
  • Facebook 與 Instagram 歷史改進。 已改進 /history/facebook 與 /history/instagram 端點：對於 Facebook，過期／已封存的 Stories 現在會預設被過濾掉，只有啟用中的 Stories 會與一般貼文一起出現；新的 since 與 until 查詢參數允許以 ISO UTC 日期字串進行時間篩選。對於 Facebook 與 Instagram，新的 dataType 參數讓你可以只要求 posts、只要求 stories，或兩者皆要（預設）。
  • X 速率限制移除。 作為 X/Twitter BYO Keys 遷移的一部分，Ayrshare 不再對 X 分析強制執行每月或每日的速率限制。你的使用量現在受你自己 X Developer 帳號的限制管理。

​
2026 年 2 月

  • 2 月 25 日 - X/Twitter 影片標題與描述。 發布至 X/Twitter 的影片現在支援設定 videoTitle 與 videoDescription（於 X Post API 的 twitterOptions 物件送出），適用於上傳至 X Media Studio 的媒體。此支援搭配現有的 thumbNail，提供更豐富的影片中繼資料。
  • 批次 Analytics。 新增社群貼文 ID 的批次分析支援，可透過新的 postIds 參數在一次 analytics 呼叫中處理最多 100 則貼文。詳情請見我們的 Analytics on a Post by Social ID 端點。
  • 歷史分頁。 為 Threads 與 X/Twitter 的平台貼文歷史 API 加入分頁支援。不再有 500 則貼文的上限——你現在可以使用分頁抓取更長的歷史，並將呼叫拆成較小批次以獲得更快、更有效率的回應。
  • 免費試用增強。 免費試用使用者現在可以測試 Messaging API 與 Max Pack——在免費試用期結束前不會收費。
  • 更好的錯誤訊息。 為 X/Twitter 與 LinkedIn 錯誤訊息新增額外細節，讓你更容易診斷 API 呼叫的問題。
  • Instagram 留言修正。 修正 Get Comments 端點無法正確回傳有巢狀回覆的最上層 Instagram 留言的問題。
  • Python SDK。 已更新我們的 Python SDK，包含最新功能與改進。
  • X/Twitter Webhook URL。 Direct Message Event webhook payload 中現在會包含新的 ayrshareUrl 欄位，提供未經驗證的網址供方便使用。
  • 狀態頁面 Slack 整合。 你可以自動將我們狀態頁面的更新連結到 Slack。只需點擊右上方的「Get Updates」並選擇 Slack 選項。

​
2026 年 1 月

  • 1 月 21 日 - Link Analytics 自訂網域修正。 Link Analytics 端點（GET /links/:id）現在會使用你設定的自訂網域回傳短連結，而非預設的 Ayrshare 網域。若你使用自訂短連結網域（Business/Enterprise），analytics 網址現在會與你的實際連結一致。
  • 1 月 15 日 - Instagram 外送訊息刪除同步。 當 Instagram 外送（已傳送）訊息在原生 Instagram app 中被刪除時，現在會正確標示為在 Ayrshare 的 Messages 資料中已刪除——與內送訊息原有行為一致。對話歷史現在雙向都能保持準確。
  • MCP Server。 應廣大要求——我們重新推出了 MCP Server！將你的 AI 工具直接連上 Ayrshare API。
  • 自助註冊。 新增 Business Plan 與 Launch Plan 的自助註冊。新客戶現在可以取得 Launch Plan 的 14 天免費試用來測試 Ayrshare 平台。
  • X/Twitter 影片縮圖。 X/Twitter 影片貼文 現在支援包含縮圖預覽圖（以網址形式）。這會在上傳影片時作為中繼資料的一部分送出。
  • Instagram Hashtag 上限。 已將 Instagram 貼文 的 hashtag 上限變更為 5，以符合 Instagram 發布的新規範。
  • Bluesky 影片時長。 Bluesky 影片媒體時長上限已調整為三分鐘，以符合 Bluesky API 需求。

​
2025 年 12 月

我們以透明與可靠性作為今年的收尾，並規劃了 2026 年第一季推出大量新功能。
  • 12 月 23 日 - X/Twitter 回應中的 URL Entities。 X/Twitter 貼文與歷史 回應現在包含推文本文中連結的 URL entity 資料：最上層 urls 陣列會帶入 X 的原始欄位（display_url、expanded_url），加上一個 camelCase 的 entities 物件，其中相同連結會以 entities.urls[].displayUrl / expandedUrl 出現——讓你在整合中更容易呈現連結預覽與偵測外連。
  • X/Twitter Entities。 X/Twitter 的貼文分析 與平台歷史 端點現在會從推文文字中回傳解析後的 entities，包含 URL、mention、hashtag 與 cashtag 及其位置與顯示網址。
  • Facebook 貼文分析。 Facebook 貼文分析 新增 mediaView、mediaViewIsFromAds 與 mediaViewIsFromFollowers 等指標，以取代停用的曝光指標。
  • Bluesky 留言。 改進了對 Bluesky 留言取得 的支援，能正確處理 AT Protocol 風格的貼文與留言 ID。
  • Threads 連結。 強化了 Threads 帳號連結，可處理帳號上沒有 name 或 username 欄位的情況。
  • 24/7 監控。 引進專屬 DevOps 團隊全天候監控平台以提升可靠性。
  • 每月收據。 現在會自動將每月收據以 email 寄給主要帳號持有人，讓計費與付款更透明。

​
2025 年 11 月

  • Instagram Token 更新。 為使用直接 IG 登入（不透過 Facebook 粉絲專頁）連結 Instagram 的使用者新增了長效 Instagram token 的自動更新。
  • Facebook Analytics 更新。 Facebook 貼文分析 現在回傳強化的曝光指標，包含 post_impressions_paid_unique、post_impressions_fan_unique、post_impressions_organic_unique 與 post_impressions_unique。
  • Facebook Page Insights。 新增 Facebook social analytics 欄位：pageFollows、pageMediaView、pageMediaViewIsFromAds 與 pageMediaViewIsFromFollowers，同時支援彙總與每日細分。
  • Instagram Analytics。 Instagram social analytics 的 viewsCount 與 reachCount 指標現在同時支援直接 Instagram Login 與 Facebook 連結的帳號。
  • LinkedIn Mentions。 修正了 LinkedIn mentions 的處理，以正確區分 mention 組織與個人。
  • 儀表板改進。 Ayrshare 網頁儀表板 的 API 頁面經過重構，效能改進並將 messaging 用量卡片組織得更好。
  • 團隊擴編。 擴增開發團隊以加速支援與功能開發。

​
2025 年 10 月

  • Ayrshare 被 Saas.group 收購。 Ayrshare 已被 Saas.group 收購。團隊正在擴大，以提供更快的功能開發與更好的客戶支援。
  • Webhook 歷史。 新的端點可依動作取得過去 6 個月的 webhook 歷史。
  • Facebook Ads 地點定位。 除了國家定位外，你現在可以在推廣 Facebook 貼文時指定地區或城市。
  • LinkedIn 影片縮圖。 LinkedIn history 端點 現在會為影片貼文回傳 thumbnailUrl，讓你更容易在應用程式中顯示影片預覽。
  • Reddit 貼文分析。 Reddit 貼文分析 的可靠性已改進，強化驗證處理以避免速率限制問題。
  • Instagram 歷史。 已改進 Instagram 貼文歷史 對貼文數量眾多的帳號中大型結果集的處理。
  • Facebook Ads。 Facebook ads 歷史端點 現在包含依 campaign 結構回傳哪些廣告的說明。
  • Instagram 協作。 新增文件說明由於 Instagram API 的限制，已接受的協作貼文 可能不會從平台 history 端點回傳。

​
2025 年 9 月

  • TikTok 草稿。 將貼文送到 TikTok 草稿 現在同時支援圖片與影片。
  • Facebook Ads。 作為歐盟數位服務法（DSA）要求的一部分，Facebook 要求以歐盟任何區域為目標的廣告必須提供定義建立廣告的受益人與付款人的值。你現在可以查詢 DSA 建議並將其加入廣告。
  • 媒體管理。 GET media 端點 已強化以包含已上傳的大型媒體檔案，並現在顯示 expireAt 欄位。
  • Threads 發布。 輕鬆在 Threads 上建立 thread（也就是 threadstorm），這是在 Meta Threads 上一系列相連的貼文。
  • 私訊。 Facebook 與 Instagram Messaging 現在支援傳送音訊檔（AAC 或 WAV）。

​
2025 年 8 月

​
2025 年 7 月

​
2025 年 6 月

  • Instagram Login（即將推出）。 在社群連結頁面上啟用或停用 Instagram Login。Instagram Login 將在接下來幾週內預設啟用。若你需要包含 hashtag 搜尋、協作、地點標記或品牌資料等進階功能，必須手動停用此選項改用 Facebook 粉絲專頁驗證。我們建議大多數客戶使用新的直接 Instagram Login，因為工作流程更簡單且不需要 Facebook 粉絲專頁。
  • 推出 Snapchat。 Ayrshare 現在支援 Snapchat。Snapchat API 支援將內容直接發布至 Stories 與 Spotlight，並取得分析與歷史。Stories 是 24 小時後會消失的臨時貼文，而 Spotlight 貼文為永久性，可幫助創作者與企業觸及更廣泛的受眾。
  • MCP Server。 將 Ayrshare API Docs MCP server 連上你的 AI 代理。將 Ayrshare API 文件 MCP server 連上 Cursor 或 Claude Desktop 等 AI 開發工具，就能讓你的 AI 代理直接存取 Ayrshare 的文件。
  • 複製貼文。 將既有的貼文複製到另一個平台。新的端點讓你可以將成功的貼文重複用在不同平台或使用不同設定。
  • 開發者儀表板。 開發者儀表板 的發文流程有兩項新改進。除了上傳媒體檔案外，你現在也可以使用網址發布媒體。你還可以檢視用於發布貼文的 JSON，這有助於驗證你的 JSON 是否正確。
  • 使用者管理。 User 端點 現在會回傳所連結社群網路的即時狀態，並在使用者連結或斷開其社群媒體帳號時自動更新。
  • YouTube。 於 YouTube 發布影片現在允許透過設定 containsSyntheticMedia 參數揭露具真實感的 Altered 或 Synthetic（A/S）內容。查看文件。
  • Facebook。 取得 Facebook 留言 現在會回傳特定留言的直接網址。

​
2025 年 5 月

​
2025 年 4 月

​
2025 年 3 月

​
2025 年 2 月

​
2025 年 1 月

​
2024 年 12 月

  • 儀表板。網頁儀表板中的 User Profiles 頁面效能已優化。無論帳號中有多少 User Profile，你都能獲得順暢的滾動與載入體驗。
  • 儀表板。網頁儀表板的 Posts 頁面現在允許你將已刪除貼文納入歷史時間軸。這讓你能以與成功貼文相同的方式存取、篩選與搜尋已刪除貼文。
  • 已刪除貼文。若你或你的使用者已在社群網路上手動刪除貼文，你可以在 Ayrshare 中將其標示為手動刪除。這會避免 Ayrshare 未來嘗試刪除該貼文，並讓你取得更準確的貼文歷史。
  • Webhook。你現在可以在一次呼叫中取得所有 User Profile 已註冊的所有 webhook。
  • Analytics。Instagram 貼文分析 現在包含 share、followers gained、profile visits 與 profile activity 計數。
  • 留言。TikTok 留言 現在會回傳留言者的姓名。
  • 留言。X 留言 現在會回傳被留言回覆的 Tweet ID。

​
2024 年 11 月

​
2024 年 10 月

Ayrshare Dashboard API Calls

​
2024 年 9 月

  • Facebook Analytics。History Get All Posts 與Analytics 端點現在會回傳為 Facebook 貼文按讚的使用者。你可以取得每位使用者的姓名與 user ID。
  • 內容審核。新的 Moderation 端點會檢查內容是否有害或不當。此端點同時支援文字與圖片。
  • LinkedIn 連結。連結 LinkedIn 公司頁面先前需要使用者是該頁面的 Super Admin。現在管理 LinkedIn 公司頁面的 Content Admin 也能連結，可發文、取得分析與管理留言。
  • 使用者管理。User 端點 現在會為 Facebook 與 Instagram 同時回傳 Page ID 與 User ID。
  • 儀表板。網頁儀表板 Post 頁面現在會顯示圖示，指出貼文是否由 RSS feed 發布。
  • Facebook 評論。Facebook 評論 現在會回傳留下評論者的個人檔案照片。
  • Google 評論。Google Business Profile 評論 現在會回傳你所有的評論，即使有數千則。

​
2024 年 8 月

  • LinkedIn 歷史。現在你可以取得 LinkedIn 個人頁面的貼文歷史。先前只有 LinkedIn 公司頁面會回傳歷史。需要重新連結 LinkedIn 至 Ayrshare。
  • LinkedIn Analytics。LinkedIn 個人與公司頁面 有新的資料點可用，包含 likedBy 與 comment 細節。
  • LinkedIn 查詢。brand 端點 現在允許你查詢個人或公司。可用於查看誰對你的貼文按讚的細節。
  • Facebook 歷史。你可以將 Facebook 粉絲專頁歷史 的結果限制為只顯示由該專頁本身發布的貼文。這會過濾掉所有非由該專頁發布的內容。
  • User Profile。user 端點 現在會回傳一個新欄位，帶有該 User Profile 最後一次呼叫 API 的時間戳記。
  • X 長貼文。你可以將長貼文發布至 Premium X 帳號。長貼文最多可達 25,000 個字元。你現在也可以在呼叫分析或歷史時取得完整長貼文資料，包含長貼文主體中的完整內文與網址。
  • 網頁儀表板。已改進 post 頁面設計，並新增多種內容類型。你現在可以從儀表板直接發布 Facebook 與 Instagram Reels 或 Stories，或 YouTube Shorts。
Updated API Dashboard
  • 團隊管理。當你邀請團隊成員 時，你現在可以在儀表板 User Profiles 頁面中看到他們是否已接受邀請，或重新寄送邀請。
  • AI 影片標題。影片轉錄 現在包含建議標題。這對於需要為每部上傳影片提供標題的 YouTube 發布很有用。（需要 Max Pack）
  • 暫停貼文。你可以透過 post 端點暫停與恢復排程貼文。
  • 情緒分析。generate 端點 現在可以對貼文或留言產生情緒分析，判斷是負面、正面還是中性。結果也包含如何改善的建議。
  • Instagram Analytics。Instagram analytics 已強化以回傳關於已互動受眾的額外人口統計資料。
  • TikTok 照片。你現在可以以照片發布至 TikTok。先前僅接受影片。

​
2024 年 7 月

​
2024 年 6 月

  • Ayrshare Messaging API。Ayrshare Messaging Add-On 是一個可選付費加購方案，讓你的平台可為使用者管理私訊，包含 Facebook Messenger、Instagram Messaging 與 X/Twitter Messaging。
  • YouTube 留言。你現在可以透過 YouTube comment ID 刪除 YouTube 留言。
  • 自動 Hashtag。推出全新重建的自動 hashtag 系統，具備更相關的 hashtag 且無貼文長度限制。單一貼文可帶的 hashtag 數量也已提升為最多 10 個。
  • 網頁儀表板。儀表板 UI 已更新，能透過單一點擊移除 post 頁面上所有目標社群網路，且 API Key 頁面新增了程式範例區段。
  • User Profile 管理。Profiles 端點已強化 以允許你將結果篩選為擁有有效社群帳號或包含特定平台的 profile。

​
2024 年 5 月

  • Google Business。你現在可以更新你 Google Business Profile 地點資料，包含電話號碼、網站網址、地圖位置等。
  • 歷史搜尋。透過 History 端點，你現在可以跨所有 User Profile 搜尋貼文 ID。若你有一個 post ID 但不知道是哪個 User Profile 發布的，這會非常實用。
  • User Profile 標籤。為 User Profile 加上你自己的標籤，以更有條理地組織與管理 profile。網頁儀表板也允許你查看已指派的標籤並在 User Profiles 頁面搜尋標籤。
  • YouTube 字幕。使用 SRT 或 SVB 檔為 YouTube 影片加上自訂字幕。
  • NPM 套件。已發布更新後的 Node.js NPM 套件，包含新的端點與更詳細的文件。套件也已改名為 social-media-api。
  • Facebook 留言。你現在可以將圖片作為留言的一部分 在 Facebook 上發表。
  • LinkedIn 留言。LinkedIn 留言現在會回傳該特定留言的按讚數。
  • LinkedIn Brands。LinkedIn 資料的 Brands 端點 已強化，包含帳號的本地化名稱、公司專長與公司描述。
  • 停用留言。你可以停用貼文的留言，適用於 Instagram、LinkedIn 與 TikTok。這對新貼文或已發布的貼文都有效。
  • 歷史貼文。從 TikTok 取得歷史貼文資料，即使該貼文並非透過 Ayrshare 發布。
  • Instagram Analytics。Instagram Stories 新增可用的資料點，包含回覆、分享與退出次數。
  • AI Generate。以 AI 依一張或多張圖片產生社群媒體貼文 文字。也可以用來撰寫圖片說明。
  • 網頁儀表板。在儀表板列出的每個 User Profile 中，你都能看到已連結的社群網路。可將滑鼠移到每個社群網路圖示上以查看該社群網路上的名稱。
  • 社群連結。網頁儀表板與社群連結頁面上，現在會在頁面或公司名稱旁顯示個人檔案圖片。

​
2024 年 4 月

​
2024 年 3 月

​
2024 年 2 月

  • 評論。使用新的 /reviews 端點取得、回覆與刪除 Google Business Profile 與 Facebook 專頁上的評論。
  • LinkedIn 留言。依 comment ID 取得 LinkedIn 留言，可用於在 Ayrshare 外進行的留言。
  • LinkedIn Mentions。LinkedIn mentions 在留言與留言回覆中現在會解析為被 mention 的組織帳號。
  • 公開個人檔案資料。你現在可以在 brand 端點 中搜尋 Facebook 專頁與 LinkedIn 名稱。查詢使用者或公司的社群媒體公開資訊，例如粉絲、個人檔案圖片與網站。這些使用者與公司不必是已連結的 Ayrshare 使用者。
  • Facebook 留言。Facebook 留言 的留言端點 API 現在會直接在回應主體中回傳回覆。
  • Instagram 禁用 hashtag。使用新的 API 端點 或新的網頁工具 檢查被禁用的 hashtag。有助於避免你的帳號被停用或影子封鎖。
  • Facebook Groups。Facebook 已宣布將移除 Facebook Groups 的 API 存取權。了解更多。

​
2024 年 1 月

  • 更長的 Instagram 影片。Instagram 影片貼文 現在支援最長 15 分鐘與 1 GB。較先前的 60 秒與 100 MB 提升。
  • 翻譯貼文文字。可從超過 100 種不同語言中選擇翻譯你的貼文文字。例如將英文翻譯為法文或西班牙文翻譯為德文。來源語言會自動偵測。
  • 錯誤翻譯。錯誤訊息可以自動翻譯 為你選擇的語言。若你想直接以使用者偏好的語言顯示錯誤，這會非常實用。
  • Pinterest Analytics。Pinterest 額外資料點 現在可用於 get all history，包含貼文標題、備註與 board id。
  • Check Post Length。Check Post Length 端點 現在包含 Facebook、Google Business Profile、LinkedIn、Pinterest 與 YouTube 的驗證。
  • 新的 User Batch 端點。當你需要大量資料集時，batch 端點是個很好的選項。你可以使用 batch 端點取得所有 User Profile 的 json 檔案，並使用 webhook 在檔案準備就緒時通知你。
  • LinkedIn 歷史貼文。取得在 Ayrshare 外發布的 LinkedIn 貼文歷史資料。
  • LinkedIn 貼文 Reactions。Get All Post 端點 對 LinkedIn 現在會回傳貼文的 reactions，例如 Likes、Praise、Maybe 與 Appreciation。
  • 最後一次 API 呼叫時間。在網頁儀表板的 API Key 區段存取你最後一次使用 API 金鑰的時間。
  • Ayrshare 儀表板歷史。網頁儀表板現在允許你透過新的「Load more」按鈕載入所有歷史貼文或 webhook 日誌。
  • Webhook 錯誤。查看你 webhook 的錯誤率 以查看成功與錯誤回應的百分比。

​
較舊的更新

請前往更新封存 查看較舊的更新。