錯誤的 HTTP 狀態碼為 400、401、402、403、404、429、500、502、503 或 504;成功時狀態碼為 200。詳情請見此處。
errors欄位包含錯誤陣列,每個發生錯誤的社群網路各對應一筆。action代表所回傳錯誤的類型。- 最上層的
status欄位在 API 呼叫失敗時為「error」。例如,對於 /post 呼叫,若所有社群網路的貼文皆成功,status欄位會是「success」;否則為「error」。 code欄位為 Ayrshare 的參考錯誤碼。message欄位為錯誤的具體細節。
處理錯誤
你應該處理任何錯誤回應並採取相對應的動作。發生錯誤的情況為:- 回應的狀態碼不是
200 - JSON 回應的 status 為
error
400 Bad Request 回應:
400 Bad Request:
Instagram 專屬錯誤碼
以下錯誤碼提供 Instagram 發布失敗的具體細節,並在可行時取代較為籠統的 error 138。 Code 435 — Instagram 速率限制 (HTTP 429) Instagram 專業帳號(Business / Creator)在 Meta 的 Content Publishing API 上有 24 小時內滾動 50 篇貼文的限制(個人帳號完全無法透過 API 發布,因此永遠不會觸發此限制)。當達到上限時,Meta 會回傳速率限制錯誤。當 Meta 的發布端點直接回傳 HTTP 429,或底層的 error subcode(1390008)指出貼文/留言遭到節流時,Ayrshare 也會以 code: 435 呈現。
Retry-After 標頭時,其值(單位為秒)會透傳到 details 欄位——至少等待該秒數後再重新提交。
Code 436 — Instagram 媒體處理逾時 (HTTP 400)
Instagram 處理上傳媒體的時間過長。可能發生於大型影片檔或 Meta 伺服器高負載時期。
/post 請求提供了 instagramOptions.trialParams,但 graduationStrategy 為缺失、null 或空字串時回傳。Trial reels 需要明確的 graduation strategy——請參閱 Trial Reels。
instagramOptions.trialParams.graduationStrategy 設為 "MANUAL" 或 "SS_PERFORMANCE" 後重試,或者如果你並非要發布 trial reel,請移除 trialParams。
Code 448 — Instagram Trial Reels:無效的 graduationStrategy (HTTP 400)
當 graduationStrategy 存在但不完全等於 "MANUAL" 或 "SS_PERFORMANCE" 時回傳。此檢查區分大小寫——"manual" 或 "ss_performance" 等值都會被拒絕。details 欄位會回顯被拒絕的輸入(截斷至 64 個字元)以便偵錯。
graduationStrategy 精確地送出為 "MANUAL" 或 "SS_PERFORMANCE"(大寫、字串型別)。
Code 449 — Instagram Trial Reels:不相容的媒體 (HTTP 400)
當媒體或貼文型式不符合 trial reel 的要求時回傳。Trial reels 必須是單一 .mp4 或 .mov 影片——輪播(多個 URL)、限時動態(instagramOptions.stories: true)以及非影片副檔名都會被拒絕。details 欄位會指出實際觸發的子情況。
.mp4 或 .mov 影片網址,且不要帶 stories: true 旗標。移除多餘的 mediaUrls 條目;或者如果你原本要發一般輪播/限時動態,請移除 trialParams。
Code 258 — Instagram 帳號狀態錯誤 (HTTP 400)
一般性的 Instagram 帳號狀態失敗,基礎訊息為「Error with Instagram.」。此錯誤在 Meta 因所連結的 Instagram 帳號狀態(而非貼文內容)拒絕請求時出現。
error_subcode 為 2207085 時,回應會額外設定 relink: true 與 retryAvailable: true,訊息也會指示使用者取消連結並重新連結 Instagram 帳號,並授與所有權限:
2207085 子情況,請提示使用者到 Social Accounts 中取消連結並重新連結 Instagram 帳號,授與所有要求的權限,然後重試貼文。對於其他帳號狀態錯誤,請確認 Instagram 帳號在 Meta 上處於良好狀態後再重試。
可重試 (Retry Available)
有時社群網路會發生無法回復的錯誤,例如伺服器問題,即使經過多次重試呼叫最終仍失敗。 在這些情況下,我們的系統會判斷該錯誤是否可重試;如可重試,retryAvailable 欄位會為 true。
X/Twitter BYO Key 錯誤
以下錯誤碼專屬於 X/Twitter BYO(Bring Your Own)金鑰的操作: Code 272 - 無法驗證 BYO Twitter 身份 (HTTP 400) Ayrshare 無法使用你的 BYO consumer key 與連結時儲存的 OAuth token 確認你的 X/Twitter 身份。回應格式會因觸發的呼叫而異,兩種格式都對應到以下三個子情況。請以擁有該 BYO Developer App 的帳號登入 x.com 以確認實際情況。 貼文路徑會回傳精簡的回應:details 欄位:
details 若存在,會反映 X 端的提示,是判斷屬於下列哪個子情況最可靠的單一線索。
帳號遭停權。 登入 x.com 會顯示停權通知。動作: 聯絡 X 支援。在 X 恢復帳號之前,重新連結無法恢復存取權限。
帳號被鎖定。 登入 x.com 會出現解鎖挑戰(CAPTCHA、電話驗證等)。動作: 於 x.com 完成解鎖挑戰後再重試請求。不需要重新連結。
身份或金鑰不符。 你的 X 帳號在 x.com 狀態正常,但你的 BYO consumer key 屬於的 X Developer App 與連結時儲存的 OAuth token 不同。動作: 於 Social Accounts 重新連結 X,並使用擁有該 BYO Developer App 的相同 X 帳號授權。
Code 416 — X 點數耗盡 (HTTP 402)
你的 X Developer 帳號未載入 API 點數。所有 X API 呼叫都需要點數。
x-access-level: read,確認你的 Access Token 是以唯讀權限產生。
動作: 在 X Developer Console 中,將 app 權限更新為 Read and write and Direct message,然後在 Keys and tokens 重新產生 Access Token。新 token 會繼承更新後的權限。詳情請參閱 X BYO Key 設定指南。
Code 419 - 缺少 BYO 憑證 (HTTP 400)
X/Twitter 操作需在請求標頭中提供 BYO API 憑證。當兩個標頭皆缺失,或成對中僅提供其中之一時,Ayrshare 皆會回傳 code 419。message 字串會因缺少的標頭而不同。
當 X-Twitter-OAuth1-Api-Key 與 X-Twitter-OAuth1-Api-Secret 皆缺失時:
X-Twitter-OAuth1-Api-Key 與 X-Twitter-OAuth1-Api-Secret。若你只提供其中一個而未提供另一個,請求會以相同錯誤碼被拒絕。完整的標頭清單請見 X BYO Keys Header Reference。
Code 423 — 舊版 X/Twitter OAuth 已不再支援 (HTTP 403)
當 X/Twitter 請求仍依賴舊版(非 BYO)OAuth 流程時回傳,該流程已不再支援。X API 存取現在需要透過請求標頭提供你自己的 X Developer App 憑證。
X-Twitter-OAuth1-Api-Key 與 X-Twitter-OAuth1-Api-Secret 標頭。完整設定步驟請見 X BYO Key 設定指南。
內文優化錯誤
Code 441 — 內文優化失敗 (HTTP 502) 當在準備貼文時,某個或多個平台的內文優化(例如shortenLinks)失敗時回傳。每個受影響的平台會以 source: "handlePostAdditions" 與 code: 441 出現在 errors 陣列中。
當只有部分平台失敗時,其他平台仍會成功發布,其結果會出現在 postIds 中。此時最上層的 status 為 "error",但 postIds 不為空——客戶端應將 status 與 errors[] 視為互補而非互斥。
code: 441 與 HTTP 502,且不會建立任何貼文:
- 若
postIds不為空(部分平台已發布成功),請勿重新提交完整平台集合——這會在成功的平台上重複發文。應檢視errors[]找出失敗的平台,僅針對這些平台重試請求,或依賴你自己的冪等重試流程。 - 若
postIds為空或不存在(在排程/發布時全部失敗),可安全地重試整個請求。 - 若失敗持續發生,請去除優化旗標後再發布(例如移除
shortenLinks)或聯絡支援。
媒體抓取/爬蟲存取錯誤
Code 440 — 社群網路無法下載媒體 (HTTP 400) 當平台的發布爬蟲無法下載你提供的mediaUrl 時回傳——最常見原因是 robots.txt 或 WAF/防機器人規則阻擋爬蟲(例如 Meta 的 facebookexternalhit)。details 字串來自上游平台,通常是 Meta/Instagram 的 error 2207052 文字。
details 字串通常包含 "Restricted by robots.txt" 或 "HTTP error code 403"。Code 138 也用於長寬比/格式問題以及其他一般性 Instagram 錯誤,因此媒體抓取變體可透過 details 字串辨識。
mediaUrl 同時發布至兩個平台時,Threads 遇到與 code 440/138 相同的媒體抓取問題。Threads API 不會回傳 detail 字串,因此通常需要透過同一次發布中同時出現的 Instagram 440 或 138 來診斷。
robots.txt 範例與驗證指令。
Facebook Analytics 速率限制
Code 444 — Facebook 粉絲專頁分析速率限制 (HTTP 429) 當 Facebook 粉絲專頁在分析端點上超過 Meta 的每專頁速率限制時回傳。底層的 Meta 錯誤為80001(「There have been too many calls to this Page account.」)。粉絲專頁仍為已連結狀態且可繼續發布——只有該專頁的分析請求被節流。
當在 /history/facebook 或分析回應中偵測到單一貼文的節流時,每個受影響的貼文會在 facebook.code 帶有 code: 444 與 errCode: 80001:
Meta 身份驗證
Code 326 — 需要 Meta 身份驗證 (HTTP 403) 當 Meta 要求所連結帳號進行額外身份驗證後才會接受請求時回傳。此錯誤適用於各 Meta 平台——Facebook、Instagram、Facebook Groups、Threads 與 Messenger。重新連結帳號無法解決此問題;驗證必須在 Meta 端完成。Facebook 帳號限制
Code 476 — Facebook 帳號限制 (HTTP 400) 當發布至 Facebook 因 Meta 已對帳號設下限制而失敗時回傳(Meta error subcode2424009 與 1404078,或當錯誤未帶 subcode 時 Meta 的限制措辭)。這是帳號層級的限制,不是暫時性發布故障——此錯誤不可重試,也不會帶 retryAvailable 旗標。以相同貼文再次提交在該限制與 Meta 之間未解決前不會成功。帳號仍為連結至 Ayrshare 的狀態,無需重新連結。
Meta 不會透過 API 回傳具體限制原因,客戶必須直接前往 Meta 的 Account Status 頁面查看原因並申訴。當 Meta 提供其原文時,Ayrshare 會於 details 欄位呈現。當偵測到限制時,Ayrshare 也會傳送通知 email 給帳號擁有者。
圖片格式轉換錯誤
Ayrshare 會在發布至不接受 WebP、HEIC 與 AVIF 的平台前自動將這些圖片轉換為 JPEG(Instagram、LinkedIn、TikTok、Google My Business、Threads 與 Snapchat 針對 WebP;所有平台針對 HEIC 與 AVIF)。轉換會在發送時透明執行。以下三個錯誤只有在轉換流程本身無法完成時才會觸發;若原始圖片已為支援的格式,則不會嘗試轉換,這些錯誤碼也不會出現。 Code 450 — 圖片格式轉換失敗 (HTTP 400) 圖片已下載,但無法重新編碼為 JPEG。最常見原因是原始檔案損毀、容器內部含有非預期的格式,或圖片超過轉換的大小上限。mediaUrl 以確認可顯示。如果可以,請重新匯出為乾淨的 JPEG 或 PNG 檔案後重試貼文。
Code 451 — 為了轉換而下載圖片失敗 (HTTP 400)
轉換流程無法抓取原始圖片。常見原因包括來源回傳 4xx/5xx、網路逾時、重新導向鏈超過跳轉限制,或網址解析為非公開位址(被 SSRF 防護阻擋)。details 欄位若存在,會帶有底層原因字串。
mediaUrl 可公開存取(不需驗證、沒有 robots.txt 封鎖、透過 HTTPS 可解析)。若網址有重新導向,請確保最終目的地也為公開,且不在私有網路內。
Code 452 — 已轉換的圖片上傳失敗 (HTTP 500)
轉換成功,但 Ayrshare 無法將轉換後的 JPEG 暫存至暫存儲存桶。這是 Ayrshare 端的內部失敗,可以重試。
mediaUrl 與大致時間戳記。
YouTube 暫時性上傳錯誤
以下錯誤碼專門用於 YouTube 上傳失敗中通常屬於暫時性且可安全重試的情況。兩種回應都會包含retryAvailable: true,因此整合應依此布林值而非 HTTP 狀態碼進行分支判斷。
大多數以前針對 YouTube 上傳的 code: 176 回應,現在會改為導向 453(暫時性逾時)或 454(暫時性服務不可用),兩者皆帶有 retryAvailable: true。若你的整合是依 HTTP 500 過濾以重試 YouTube 上傳,請改為根據回應主體中的 retryAvailable 欄位過濾。
Code 453 — YouTube 上傳逾時 (HTTP 504)
當 Google 的 YouTube 匯入流程在接收上傳時逾時的情況下回傳。通常是暫時性的,會在一至兩分鐘內自行恢復。
retryAvailable 欄位(而非 HTTP 狀態)判斷是否可重試。你也可以使用 retry post 端點以相同 payload 重新提交。
Code 454 — YouTube 上傳服務暫時無法使用 (HTTP 503)
當 YouTube 上傳端點回傳 5xx 狀態,或至 YouTube 的連線在 socket 層被重設或逾時(ECONNRESET、ETIMEDOUT、ESOCKETTIMEDOUT)時回傳。這些皆為暫時性狀況。
retryAvailable 欄位(而非 HTTP 狀態)判斷是否可重試。你也可以使用 retry post 端點以相同 payload 重新提交。
YouTube 縮圖錯誤 Code 307
當自訂 YouTubethumbNail 無法套用時,會回傳 code 307。當影片本身發布成功時,此錯誤不會讓貼文失敗——YouTube 結果仍為 status: "success",並在 warnings 陣列中以附加方式呈現失敗(feature: "thumbnail"、code: 307)。為了向後相容,仍會保留舊版的 thumbnail 子物件。
最常見原因是未驗證的 YouTube 頻道。當頻道未完成電話驗證時,YouTube 會回傳上游 403 與一般訊息 "The authenticated user doesn't have permissions to upload and set custom video thumbnails"。該措辭看起來像 OAuth 問題,但實際上幾乎總是驗證問題,因此請先確認頻道驗證。重新連結 YouTube 帳號則為次要原因。
warnings 條目呈現(最上層 status 仍為 "success")。無論在什麼時機偵測到問題都適用:
- 上傳前被攔截。 當發布前驗證能確定縮圖無效時(檔案類型錯誤、確認超過 2MB,或網址無法存取),Ayrshare 會略過縮圖,仍然發布影片,並在
warnings中回報精確原因——你可避免注定失敗的上傳嘗試,並得到比服務商更清楚的訊息。 - 上傳後被偵測到。 當失敗只有在 YouTube 處理請求時才偵測到(例如未驗證頻道的
403,或圖片過大時的413),影片已上線,失敗會在同一個warnings陣列中呈現。
status: "success" + warnings。
動作: 前往 https://www.youtube.com/verify 驗證你的 YouTube 頻道(電話驗證)。若頻道已驗證但縮圖仍失敗,請到 Social Accounts 取消連結並重新連結 YouTube 帳號並授與所有權限。完整疑難排解請見 YouTube Thumbnail Not Applied (Unverified Channel)。
Reddit 發布錯誤
Code 442 — Reddit 遭到 subreddit 封鎖 (HTTP 400) 當帳號已被目標 subreddit 禁止發文時回傳。此錯誤不可重試——原樣重新提交貼文不會成功。訊息會包含受影響的 subreddit 名稱(例如r/news)。
r/news)。
內容審核錯誤
Code 438 — 內容審核輸入被拒 (HTTP 400) 當 AI 服務商拒絕所提供的輸入時,由POST /validate/moderation 回傳——例如不支援的檔案類型。這是請求輸入層面的問題,並非暫時性處理失敗。
請對照 code 438 與 code 331。Code 331 涵蓋相同的內容審核情境,但代表服務商端的實際處理失敗(HTTP 500,訊息「There was an issue with the AI processing. Please try again.」)。Code 331 為可重試的暫時性伺服器端失敗,而 code 438 表示輸入本身被拒絕,必須先更正才能重試。
LinkedIn Analytics 錯誤
Code 475 — 重新連結 LinkedIn 個人檔案以取得分析 (HTTP 403) 當個人(member)LinkedIn 檔案是在 member analytics 上線之前完成連結時,由POST /analytics/post 與 POST /analytics/social 回傳。這些檔案缺少 LinkedIn member analytics 的 scope(r_member_postAnalytics、r_member_profileAnalytics),因此 LinkedIn 會拒絕分析請求。發布本身不受影響。
475 約 5–10 分鐘後才能成功取得分析。
TikTok 留言錯誤
Code 288 — TikTok 留言延後/貼文仍在處理中 (HTTP 400) TikTok 是非同步處理影片,因此剛發布的貼文id 在 TikTok 的 post.publish.publicly_available webhook 解析出實際 video id 之前會是 "pending"。針對仍在處理中的貼文(或 id 為 "failed" 的貼文)發送 get-comments、留言或回覆請求時,會在呼叫 TikTok 之前被拒絕,並回傳 code 288 而非一般性錯誤。
tikTokPublished Scheduled Action webhook,或輪詢 /history 直到貼文 id 是解析後的數字 video id。第一則留言在貼文解析後會自動發布,因此無需重試。若貼文為 "failed",訊息則會標示影片發布失敗且該動作不會執行。
錯誤訊息翻譯
API 錯誤訊息回應可以自動翻譯成你選擇的語言。 若你想直接以使用者偏好的語言顯示錯誤,這將非常實用。 若你想選擇社群連結頁面的語言,請參閱該連結。 於標頭中加入:Language_Code 為可用的語言代碼之一。
例如,下列會將錯誤翻譯為法文。
