如果您取得如「很抱歉，發生錯誤」這樣的錯誤訊息，而無法判斷錯誤原因，您可以選擇啟用更詳細的錯誤訊息，以便獲得更多有助執行除錯的資訊。 若要進一步瞭解 SDK init() 方法的除錯旗幟，請參閱下列文件：https://developers.facebook.com/docs/accountkit/webjs/reference
如果 Android 消費者輸入的電話號碼符合他們在 Facebook 中提供的號碼，Account Kit 即時驗證就會跳過透過短訊要求驗證碼的步驟。
這只可能是因為該用戶使用的是 Android 版 Facebook。如果我們無法確認配對，該用戶就必須通過一般的流程，並透過短訊接收驗證代碼。
Account Kit 可顯示清單中所列語言的本地語言用戶介面： https://developers.facebook.com/docs/accountkit/languages。
請參考我們支援的國家與撥號代碼更新清單：https://developers.facebook.com/docs/accountkit/countrycodes。
抱歉，我們只能透過 https://sdk.accountkit.com/en_US/sdk.js 支援連結 JS SDK。此腳本會擷取 SDK 載入器，該載入器會從 accountkit.com 或您的瀏覽器快取載入最新的 SDK。
若您想從自己的伺服器代管 SDK，寬限總期間為 24 小時。過了這個寬限期間後，SDK 就會開始發出警告，並於 7 天後停止運作。
將 enableSendToFacebook 參數 (iOS) 或 setFacebookNotificationsEnabled (Android) 設為 true。
如果短訊無法傳送，且用戶使用的電話號碼是與其 Facebook 帳戶連結的主要電話號碼，登入應用程式的用戶就會透過 Facebook 通知收到確認訊息。
We’ve moved all Messenger permissions to the Permissions and Features page.
We've consolidated this into one Permissions and Features page for Business apps, where you can see what access levels you have for each permission and feature.
Yes, developers may opt out of the Business app type and return to the previous App Review process for their app by selecting “Change App Type” on the App Dashboard. However, developers may not opt back into the Business app type and will need to create a new app to do so.
Additionally, apps previously in Development Mode that opt out to the legacy experience that have been approved for Advanced Access via App Review in the new model will lose access to data beyond what their business or anyone with a role on their app owns until they turn their app to Live Mode.
No.
We have replaced Development and Live Mode with Standard and Advanced Access. Standard Access is always active and allows you to access data that a developer’s business or anyone with a role on their app owns. You may submit for App Review for permissions and features to access data owned by other businesses or people. Refer to our Access Levels document to learn more.
To access one of these fields, you will need to submit for Advanced Access for the Business Asset User Profile Access feature through App Review.
- 應用程式遷移至其他未通過驗證的企業。所有先前獲准使用的權限便會被封鎖。
- 如果應用程式重新遷回已通過驗證的企業，這些權限便可解除封鎖。
- 應用程式已標記為為其他企業提供服務，但之後遷移至未通過驗證的其他企業。
Yes, ALL apps that leverage permissions that require review (Pages API, Groups API, Events API, Business Manager API, Instagram Graph API, Messenger Platform, extended Facebook Login permissions, Marketing API and Lead Ads API) must submit for app review in adherence with the communicated deadlines.
Active apps that leverage permissions with an August 1st deadline (Pages API, Groups API, Events API, Business Manager API, Instagram Graph API, Messenger Platform, extended Facebook Login permissions) and have not yet proactively submitted for review will be auto-enrolled in the review process. You can accelerate the App Review process by submitting your app for review prior to auto-enrollment. This will give you more control over when your app is reviewed and what information is used for the review.
應用程式是否需要應用程式審查，需視乎應用程式編號的級別面定。每個使用有關權限或功能的應用程式都必須提交以供審查。
Yes, if your apps have made calls to the Graph API in the last 28 days as of July 31, 2018 and require access to the reviewable permissions with an August 1st deadline, your app will be auto-enrolled in the app review process. We will notify you when we have a process available to send us the additional information needed to complete the review process.
As we announced earlier this year, all apps accessing the Pages API, Groups API, Events API, Business Manager API, Instagram Graph API, Messenger Platform, and Facebook Login were expected to submit for app review by August 1.
To help protect the integrity of our platform, we have removed API access for apps that require these permissions, have not gone through app review, and have not been active within the last 28 days as of July 31, 2018. If you still need access to our APIs, we encourage you to submit for review through your app's App Dashboard.
All active apps that require these permissions will be auto-enrolled in app review in the coming weeks. Developers will be notified if we require additional information to complete the app review submission. If responses are not received in the allocated timeframe, reviewable API access will be disabled.
如果我們需要就您當前的提交內容獲取額外資訊，則您將需要在收到要求後 30 天內解決相關問題，並重新提交內容以供審查。在這 30 天內，應用程式審查團隊可能會要求您提供更多資訊。請注意，這個 30 天的期限不會因您在此時段內重新提交應用程式而重新計算。
應用程式通過審查並公開發佈後，如要測試新功能或權限，請使用應用程式管理中心的建立測試版應用程式功能，建立正式版應用程式的複製版本。在正式版應用程式的管理中心中，點擊左上方導覽面板中應用程式名稱旁邊的向下箭咀，然後點擊建立測試版應用程式。透過使用調整中狀態建立的複製應用程式，您可以使用任何應用程式角色存取所有功能和權限。
如果客戶同時也是應用程式的「擁有者」，本身就必須以直接開發人員的身分通過審查程序。如果客戶以第三方開發人員作為應用程式的「擁有者」，有關開發人員就必須通過審查。
您需要要求 leads_retrieval 和 pages_manage_ads 權限。
應用程式審查程序適用於需要某些 API 權限的應用程式。您可在此了解哪些權限需要審查。設定 SDK 本身不需要應用程式審查。但是，SDK 確實容許應用程式對 Facebook API 執行調用，而如果此類 API 需要審查，則需要提交應用程式以供應用程式審查。
如果您已擁有企業管理平台帳戶，我們建議您將應用程式連繫至現有的企業管理平台。
如果您有多個隸屬同一間公司的企業管理平台帳戶，我們建議您弄清楚這些帳戶的用途，並將應用程式連繫至最合適的企業管理平台。如果您的公司使用企業管理平台設定了信用額度，我們建議將應用程式連繫至擁有信用額度的企業管理平台。
我們讓開發人員能夠在他們有額外的配置、允許清單或測試用戶個人檔案資訊希望我們使用時，提供特定測試用戶。如果他們沒有提供測試用戶，我們會使用其中一位自有測試用戶。這個欄位應標示為選填，即使沒有填寫也必須能使用。
每個應用程式都必須通過應用程式審查。建議您查看應用程式管理中心，了解需要審查的權限具體清單。
每個企業管理平台都需要完成一次商家驗證。如果您選擇將所有應用程式連結至同一個企業管理平台，則只需完成一次商家驗證。
應用程式應連結至企業管理平台，而此企業管理平台應為最終將擁有該應用程式，而且可存取其產生資料的企業所持有。此企業應負責完成商家驗證程序。
您隨時可以前往應用程式管理中心的應用程式審查標籤頁，以便在企業驗證面版中查看企業驗證的狀態、合約內容及需要採取的步驟。我們將在整個過程中向您傳送相關通知，以告知您需要採取的動作。
You need to initiate app review before August 1, 2018 for these APIs: Pages API, Groups API, Events API, Instagram Platform API, Messenger Platform, Business Manager API, and Facebook Login.
You need to initiate App Review before February 1, 2019 for these APIs and features: the Marketing API and the Lead Ads Retrieval feature.
在審查過程中，我們可能會要求您提供企業資訊，例如企業的法定名稱、地址和電話號碼。此外，您可能還需要提供企業文件，例如，水電費帳單、牌照、公司註冊證明或公司章程等。
Same as other permissions, you will lose access.
自 2018 年 8 月 1 日起，您只需驗證與應用程式連結的企業管理平台。
隨著新 API 的發佈，您需要透過應用程式審查才能要求這些 API。不過，每個企業管理平台實體僅需要完成一次商家驗證，因此應用程式在要求新的權限或 API 時，就無需再完成商家驗證。
凡是可調用 Facebook 登入延伸權限和 6 項 API（專頁、Messenger、企業管理平台、Instagram、群組和活動）的現有應用程式，都必須送交完成全新的應用程式審查流程，包括企業驗證和合約簽署。您在這天以前不需要完成應用程式審查，只要申請這項審查即可。如果沒有在 2018 年 8 月 1 日前提出申請，2018 年 8 月 2 日起就無法再使用這些 API。
凡是可調用推廣 API 和名單型廣告擷取 API 的現有應用程式，都必須在 2019 年 2 月前提交完成最新的應用程式審查流程，包括企業驗證和合約簽署。
一間企業只需驗證一次。合約只需在企業級別簽署一次。後續提交的應用程式將需接受應用程式審查，但不需要通過驗證。
是否需要接受應用程式審查，取決於應用程式編號級別。每個使用這些權限或功能的應用程式都必須送審。
Graph API 3.0 版中的企業管理平台 API 沒有任何變更。應用程式如需存取 Business_Management 權限，則需通過 Facebook 審查。
Facebook 的應用程式審查政策沒有任何變更，不會影響使用 Facebook 推廣 API 的應用程式。有關對於實際 API 的變更，請參閱 Graph API 變更記錄。
會。如果不通過應用程式審查，應用程式就只能存取用戶的名稱、電郵地址，以及個人資料相片。其他所有權限均需經由 Facebook 審查。
Instagram API 不受 Graph API 3.0 版的影響。但是，所有使用 Instagram API 的應用程式都需要通過 Facebook 審查。
在 Graph API 3.0 版中，存取活動的應用程式需要使用 user_events 權限。使用此權限的應用程式需經由 Facebook 審查。
在 Graph API 3.0 版中，user_managed_groups 權限已停用。應用程式可使用新的群組 API，以及 publish_groups 和 read_groups_user_data 權限代替原有權限。新 API 和權限需要應用程式通過 Facebook 的審查。
在 Graph API 3.0 版中，publish_actions 權限已停用。應用程式仍可以透過網頁上的 Facebook「分享」對話框，或者 iOS 和 Android 分享頁等中介體驗發佈動態。應用程式可以透過 publish_groups 權限將相關內容發佈到群組，而這需要應用程式通過審查。
會。在 3.0 版本中，所有 Messenger 平台 API 都包含在 Pages_messaging 權限下，需要通過審查。
會。應用程式如果會存取公開專頁內容，則需要要求專頁公開內容存取權限功能，並要經由 Facebook 審查。
審查程序期間，我們的審查團隊會遵循您的指引，以重現權限在您的應用程式內的使用方式。如果我們無法重現此體驗，例如，因為我們無法遵循您的指引或者無法登入您的應用程式，那麼我們也無法批准提交資料。
若要避免此情況，請：
- 提供使用該權限的可運作應用程式版本
- 確定您在「新增備註」部分提供明確的指引
- 確定所要求的登入權限可提供個人化用戶體驗，而且遵循我們的政策
特別是對於 publish_actions 權限，請確認您的應用程式發佈功能設定正確。在審查程序期間，我們需要能夠將您的應用程式內容發佈回 Facebook。
應用程式審查程序涉及在每個支援的平台上載入您的應用程式、使用 Facebook 登入，以及在審查中使用您要求的每個 Facebook 整合。這經常會導致我們所說的「一般問題」。這些錯誤和載入您的應用程式、登入您的應用程式，或者您應用程式的一般功能相關。這表示我們無法測試您在提交資料中要求的權限。
由於這些問題會導致我們無法審查您的 Facebook 功能，我們無法詳細評論您的應用程式如何使用您提交審查的 Facebook 功能。因此，我們以「一般問題」拒絕，並就每個平台對此提供意見。
如果您收到「一般問題」拒絕，請仔細閱讀所有意見。每個平台都會收到個別意見，說明審查時遇到的問題。
您的審查回應將明確說明您的應用程式未獲得批准之原因，以及您接下來應採取的步驟。我們希望您盡快通過此程序，因此，請仔細閱讀此意見。當您完成必要變更後，即可以重新提交審查。
如果您的應用程式以不獲批准的方式使用權限，您收到的意見當中會包含相關說明，而您亦不應重新提交審查。
若要獲應用程式中心批准，您的應用程式必須符合我們的資格要求。符合 Facebook 應用程式中心資格的應用程式必須使用 Facebook 登入，或者具有 Facebook 畫布應用程式。
符合資格可在應用程式中心中列出的應用程式如下：
- Facebook 畫布上的應用程式
- 使用 iOS 專用 Facebook 登入或 Android 專用 Facebook 登入建置的 iOS 或 Android 流動應用程式
- 使用 Facebook 登入的網頁或流動應用程式
您的文字素材和宣傳圖像也必須符合我們的守則。
這個要求違反平台政策第 4.5 條鼓勵用戶使用社交附加程式或者在專頁讚好的規定。其中包括根據用戶有否讚好專頁來提供獎勵或對應用程式或應用程式內容設限。User_likes 不會獲批准用於這種目的。
為了確保優質關係以及協助企業發掘重要用戶，我們希望用戶是因為想進一步聯繫或者取得企業資訊才讚好專頁，而不是為了人為的獎勵。我們相信這個政策能夠讓用戶以及廣告客戶等獲益。
我們的審查團隊可能需要其他登入憑證才能夠登入您的應用程式，以完成審查。
如果您的應用程式在 Facebook 登入之前或之後需要輔助登入，請確定提供該登入所需的用戶名稱和密碼。這可能包括測試或示範伺服器所需的登入憑證，以及您的應用程式或電郵註冊流程所需的輔助登入。
位於預備或開發伺服器上的應用程式可能需要進一步登入，才能夠存取您的伺服器。請同時就此項作業提供所有必要的登入憑證。
如果您仍然不確定遺漏哪些憑證，您可以在下一次提交資料時提供影片，展示您提供的 Facebook 登入選項和所有相關的 Facebook 整合。
我們的審查團隊需要登入您的應用程式並檢查所有 Facebook 整合，才能夠批准您提交的應用程式。
如果審查人員無法載入或使用您的應用程式，請確定：
- 應用程式網址可被公開存取而且未設定為本機代管
- 您已經提供存取您的開發或預備網站所需的用戶名稱和密碼
- 您的網站具有最新的安全憑證，而且對新用戶不會造成錯誤
- 您能夠以新建立的測試用戶身分登入和使用您的應用程式
- 您提交審查的項目屬於附加項目而且正在您的應用程式中運作
如果您因相同原因再度被拒絕，請更新審查指引或新增備註部分，要求審查人員提供更明確的說明以及其他資訊。
我們的審查團隊將使用您提供的指示來測試您應用程式的 Facebook 整合。
如果您認為審查人員拒絕您應用程式的結果並不正確，請更新審查指示，並為審查人員提供更多資訊，然後重新提交審查。
與審查人員溝通的最佳辦法，就是透過審查程序，根據您收到的意見更新備註內容。
否。權限一旦獲得批准，您即可在任何平台的任何應用程式版本上使用該權限。
如果您是在新平台上拓展和開發應用程式，將不需要提交審查。您只有在要求新權限時才需要重新提交審查，例如在應用程式加入新功能時。變更和提交應用程式詳細資料或開放式圖表動作不會影響您已獲得批准的權限。
如果您的應用程式是遊戲並放到 Facebook 畫布平台上
您可以使用下列功能邀請新玩家加入您的遊戲：
- 要求對話框。使用要求對話框時，您可以設定「filters=app_non_users」來篩選對話框，使其僅顯示未使用您應用程式的用戶。如果您的應用程式有放到畫布平台上，您還可以在 iOS 和 Android 上使用要求對話框。
- 可邀請的朋友 API。如果您的應用程式是一款遊戲而您想要自行建立朋友複選工具，您可以使用可邀請的朋友 API，這會傳回用戶朋友中未使用應用程式的排名清單。當用戶選擇要邀請的朋友時，您可以將可邀請的朋友 API 傳回的憑證傳送至要求對話框的欄位，供用戶從中傳送邀請給朋友。
如果您的應用程式沒有放到 Facebook 畫布平台上
您可以使用 iOS 訊息對話框和 Android 訊息對話框，或使用網頁版傳送對話框。這些產品可讓用戶將內含您應用程式連結的訊息直接傳送給朋友。
這種類型的訊息可直接和少數用戶溝通，是絕佳的溝通渠道。訊息對話框和傳送對話框都包含輸入提示，可讓用戶方便選擇多位要接收邀請的朋友。
在核准您的 user_likes 要求之前，審查人員需要確認您的應用程式根據從用戶處收到的讚好資訊為用戶提供獨特的體驗。要確定這一點，我們的審查團隊將使用各種測試用戶來測試您的應用程式，每個測試用戶都個別配搭一組不同的讚好與興趣。
在提交 user_likes 要求時，您應該撰寫詳細的指引，其中包括：
- 明確說明您要求 user_likes 的原因，以及該要求如何在您的應用程式中提升用戶的體驗。
- 專頁範例清單，從而供審查人員讚好以驗證您如何使用 user_likes 。在審查人員測試您的應用程式之前，請先提供他們應予以讚好的專頁之直接連結。
如果您使用 user_likes 作為演算法的一部分，有一點非常重要，就是審查人員可以看到此演算法的結果，以及該演算法如何影響向用戶呈現的內容。
否，您不需要提交以供審查便能夠執行流動應用程式安裝廣告。您只要在 iTunes App Store 或 Google Play 商店上提供應用程式即可。您可以遵循我們的指引來建立流動應用程式安裝廣告。
您需要明確說明如何測試您應用程式的每個權限或功能，以便我們確定其如何運作以及是否遵循我們的政策。如果我們無法完整測試您的應用程式與 Facebook 的整合狀況，我們將無法批准您的應用程式。您提供的指引越詳細，被要求重新提交審查的機率會越低。
為您要求的每一個權限，以逐步格式列出重現指引。所有指引必須以英文書寫。
您的指引不應該：
- 參照其他提交資料的指引或文件
- 提供您的應用程式功能摘要而不是指引
- 提供有關您的 API 如何運作的技術詳細資訊
以下是逐步指引的良好範例：
- 按下左側選單上的「設定」按鈕。
- 選擇使用 Facebook 帳戶登入
- 完成第三個步驟
- 完成第四個步驟
如果您仍然不確定要包括哪些資訊，請參閱我們的應用程式審查範例部分，查看更多範例。
由於近期審查程序有所變化，加上提交量甚高，您所提交的應用程式可能需要幾週才能完成審查程序。
請盡量提供有助審查人員的資料，包括清晰的螢幕截圖、詳細的逐步指引、應用程式及其 Facebook 整合的螢幕錄影。
應用程式如果使用社交附加程式、「分享」對話框和分享頁等中介分享產品或部分 Facebook 登入，則不必通過 Facebook 審查。如需詳細了解哪些內容需要審查，請參閱我們的應用程式審查文件。
我們會審查您的應用程式，以確保所有的應用程式都能提供高品質的 Facebook 體驗。一般來說，用戶必須清楚知道自己正在登入和發佈內容到 Facebook。用戶應該要能控制想分享給您的應用程式或 Facebook 的資料。
請注意：在您應用程式「角色」標籤頁中列出的用戶將具有擴大權限的存取權，而且不需要經過審查（例如 user_posts）。但是，應用程式公開發佈後，則必須通過應用程式審查才能存取資訊（包括在應用程式中有特定角色的用戶）。
當應用程式處於開發模式時，所有應用程式功能都應為可用，但您只能存取自己的資料、測試用戶的資料或您的專頁資料。如果想公開發佈應用程式，即使您是唯一用戶，您的應用程式也必須通過應用程式審查。
如果是透過 /BUSINESS_ID/pages 要求某個企業的專頁清單，您無法要求專頁的所有欄位，API 可能會回應錯誤：(#100) Unknown fields: <FIELD_NAME>。
舉例來說，這是因為此端點並不像其他類似端點會回傳專頁物件，而且內含尚未通過審核的待處理要求。因此，您無法使用欄位擴充功能來回傳專頁的欄位。
您可以使用 <BUSINESS_ID>/owned_pages 或 <BUSINESS_ID>/client_pages，這兩個端點應能回傳專頁物件，並支援欄位擴充功能。
若要傳送要求至已驗證的專頁，Facebook 合作夥伴經理必須先配置企業，以便針對與專頁相關的機構執行該要求。沒有 Facebook 合作夥伴經理的企業將無法發出上述要求。
進行資料使用情形檢查時，應用程式管理員必須：
1.查看應用程式獲批准的權限和功能
2.確認應用程式遵守允許的使用方式
3.確認遵守 Facebook《開放平台使用條款》和《開發商政策》以及其他所有適用的條款和政策
「資料使用情形檢查」和「應用程式審查」是各自獨立但又互相關聯的兩種平台誠信措施。「應用程式審查」是著重於日後用途的審查程序，對存取某些 Facebook 開放平台的權限有所限制，開發商必須提交申請充分說明存取平台的理由，再由開發人員作業團隊以人工方式進行審查。獲得平台存取權限後，「資料使用情形檢查」則是一年一度的認證程序，要求開發商確認繼續使用 Facebook 資料的方式遵守我們的《開放平台使用條款》和《開發商政策》。
您必須代表您商家管理的每個應用程式進行認證。
管理許多應用程式的開發商可選擇一次完成多個應用程式的資料使用情形檢查。您可前往應用程式管理中心的「我的應用程式」頁面來使用此流程。您可以在此查看您擔任管理員的所有應用程式、篩選出部分應用程式（例如僅查看須進行資料使用情形檢查的應用程式），並且完成資料使用情形檢查。
您必須對您管理的每個應用程式完成檢查（一個應用程式可能擁有多項權限）。您可依自身需求先後認證個別應用程式，只要在各應用程式的截止日期前完成這項程序即可。
系統會提示您認證您可存取的所有權限。不過如果您發現不再需要存取某些權限，您可以將這些權限移除，便不需要再為其進行認證。
「上線模式」和「開發模式」是對應用程式功能和資料使用情形檢查有所影響的兩種模式。「開發模式」一般用於測試、探索 API 產品／權限，以及完成應用程式審查；處於開發模式的應用程式不能調用用戶級別資料。「上線模式」用於生產情境，而且不會限制應用程式存取在應用程式審查中獲准存取的資料／權限。只有「上線模式」的應用程式才需要進行「資料使用情形檢查」。
一般來說，我們會為擁有相同應用程式管理員的應用程式訂定相同的截止日期，因此您的應用程式應該都有相同的期限。不過也可能有例外情況，使得部分應用程式管理員需要在不同的截止期限前完成此程序。舉例來說，如果您在其他應用程式已通過資料使用情形檢查後建立應用程式，則該應用程式就會有不同的年度截止日期。
您可前往應用程式管理中心的「我的應用程式」頁面，查看需要進行「資料使用情形檢查」的所有應用程式。您可以在此查看所有您管理的應用程式，並篩選出需要進行「資料使用情形檢查」的應用程式。
所有應用程式管理員都可進行應用程式認證。如果應用程式有多位管理員，只須其中一位進行認證。
從程序開始（您收到第一封開發人員通知）到截止日期為止，您有 60 天的時間可以完成認證程序。
在截止日期過後的一個月內，我們會限制 API 調用速度，開始撤銷平台存取權限。在這段期間，您可前往應用程式管理中心完成「資料使用情形檢查」，使應用程式重新符合規範，即可完全恢復平台的存取權限。但是過了這一個月之後，平台存取權限就會完全撤銷。
您仍然可回到應用程式管理中心完成「資料使用情形檢查」，以恢復存取權限。不過我們會針對不活躍的應用程式定期進行未使用的「權限整理」，也就是說，權限在一段時間未使用後有可能會遭到永久移除，您必須提交「應用程式審查」才能重新取得權限。建議您在截止期限之前完成「資料使用情形檢查」以避免上述情形。
資料使用情形檢查會顯示您應用程式可存取的所有權限，不論您目前是否正在使用。建議您利用這次機會審視您的整合方式、深入瞭解應用程式功能，以及移除任何您不需要的權限存取權。
因為這些自動授予的「基本」權限用途廣泛且提供用戶資料的存取權，因此我們要求開發商須認證這些權限。不過即使您未使用這些資料，您仍然可安心完成這項程序，因為認證程序代表該權限的任何使用方式皆遵守相關規定，其中也包括「不使用」的使用方式。
不需要。在應用程式管理中心移除權限後，只要重新整理「資料使用情形檢查」頁面，您移除的權限應該就會消失。
您必須對您應用程式可存取的所有權限完成資料使用情形檢查。
我們將分階段實施資料使用情形檢查，因此雖然此程序預計應在接下來的幾個月內完成，但確切的截止日期將各有不同。請確認您應用程式管理中心的是最新聯絡資料，並請參閱開發人員通知以瞭解確切截止日期。
In order to comply with certain legal obligations, Meta’s developer services may not be available in all locations, including countries and regions currently subject to U.S. sanctions prohibitions.
Meta’s services are not available in all regions.
Registration reviews may take longer and you may be unable to access our service during that time. Please try again in a few days. For more information, please refer to Meta’s Terms of Service.
We are currently reviewing your registration details. This takes 24 to 48 hours. Once completed and approved, you may be able to login and complete your registration.
您無法刪除已通過應用程式中心審核的螢幕截圖或橫額圖像。若要以新的圖像取代這些圖像，請點擊螢幕截圖或橫額上的「編輯」，然後選擇取代圖像。
檢查您是否可在未要求用戶相片的情況下看到這個錯誤訊息，並驗證是否可看見初始錯誤訊息。 接著繼續執行下列 API 要求「me/photos」，並返回查看是否還會看到錯誤訊息，並確認已經不會出現錯誤訊息了。 確保您在測試 me/photos 調用時，您是使用特定應用程式，並取得合適的存取憑證，該憑證必須擁有 user_photos 權限，這樣您就萬事俱備了！
此檢查的目的是為了確保開發人員在要求我們相同的權限之前，已經完整測試應用程式中的功能。即使已經在測試版應用程式中執行測試，也無法保證可以在主要應用程式中維持穩定的行為模式。您必須從主要應用程式發出測試要求，以確保在開放給外部實際用戶使用前，應用程式功能操作能達到預期效果。 請按照我們提供的步驟操作，以手動發出要求並確認您的管理中心應該不會再出現此警告。
「串流帖子網址安全性」轉移這個選項將停止您的 Facebook 應用程式發佈不會指回自己所擁有網域的任何網址。如果您的應用程式會發佈通往其他網站的連結，請勿使用這個選項。
這是可以控制的行為，請參考這裡的文件：https://developers.facebook.com/docs/apps/test-users#rules。測試用戶無法成為公開 Facebook 專頁的粉絲，或在其中建立內容，例如在專頁的 wall 上撰寫內容。然而，測試用戶可以在應用程式建立的相關聯專頁上，檢視以及與任何應用程式標籤互動。
這是刻意設計的。基於安全理由，我們不允許使用多個任意網域。
這是可以控制的行為。登入對話框為固定寬度，所以不會調整大小去填滿較大的螢幕。
這是可以控制的行為。開發人員必須自行在用戶的裝置上設定合適的「redirect_uri」，因此如果用戶是使用流動裝置，「redirect_uri」就應該是流動網站網址。
這是可以控制的行為，因為這個做法可預防發生潛在的安全漏洞。部分瀏覽器會將原始網址的井號片段附加到新導向網址的尾端（如果新網址本身沒有井號片段）。
舉例來說，如果 example1.com 回傳重新導向網址至 example2.com，原本前往 example1.com#abc 的瀏覽器就會前往 example2.com#abc，原本 example1.com 中的井號片段內容就可以在 example2.com 中的腳本內存取。
因為可以將驗證流程重新導向至另一個流程，所以也可以利用其他的應用程式存取某個應用程式的敏感性驗證資料。透過在重新導向網址中附加新的井號片段的方式，就可以防止發生這種瀏覽器行為模式。如果因為美觀理由或用戶端行為而不喜歡這樣的網址，也可以使用 window.location.hash（或甚至您自己的伺服器端重新導向網址）來移除不雅的字元。
Test apps created from Business apps will have Standard Access for all permissions and features.
No. The access level model only applies to permissions and features.
No. For a given permission, Business apps have either None, Standard, or Advanced Access.
Yes. A Business app will be auto-granted Standard Access and may request Advanced Access for a given permission.
Yes. For Business apps, the Advanced Access level includes access to all data within the Standard Access level.
若要分享網址，相關圖像必須至少為 200x200 像素。如果像素不足，您就會收到類似的錯誤訊息：「你提供的 og:image 不夠大。請改用至少為 200x200 像素的圖像。(Provided og:image is not big enough. Please use an image that's at least 200x200 px.)」
為網址挑選圖像時，我們首先會查看您的「og:image」標籤，看看是否存在，且是否大於 200x200 像素的門檻。如果「og:image」標籤不存在，我們就會選擇網頁中遇到的第一張圖像。
如果您遇到這個錯誤，但您認為網站圖像大於 200x200 像素，您應該檢查是否有正確設置「og:image」標籤，因為很可能是因為我們從您的網站中擷取到錯誤的圖像。
我們已變更分享附加程式的行為模式，以便與其他附加程式及平台功能保持一致。
分享附加程式不再接受自訂參數，且 facebook 會提取預覽中顯示的資訊，其提取方式與透過網址 OG 中繼標籤以帖子方式顯示於 facebook 的內容相同。
不能，您無法在分享網址上覆寫「文字說明」，只能覆寫「標題」和「描述」。
應用程式無法上載相片至另一個應用程式建立的相簿。
在部分情況下，有些相簿與所有的應用程式都沒有關聯（Wall 相片相簿）。建議您查看 can_upload 欄位。如果 can_upload 欄位回傳 false，就表示用戶無法直接在其個人檔案的相簿畫面中上載相片。
呼籲字句會在影片結束播放後，顯示於「重播」圖示下方。
若要在 Facebook 上播放，GIF 檔案大小不得超過 8MB。
我們目前不支援透過 API 在未發佈的帖子中建立回應。
以內嵌方式建立的影片帖子無法顯示於 promotable_posts 端點，因為已經處於推廣狀態。以內嵌方式建立的影片帖子亦即在廣告建立過程中建立的帖子，因此無法單獨加強推廣。
所以透過內嵌方式建立的帖子不會顯示於 /promotable_posts 端點也是可以預期的。
這可能是因為您使用的專頁存取憑證所連結的用戶，在專頁設定的「專頁角色」是擔任分析師的角色。
若是使用 Graph API 提出數據要求，系統會套用不同的私隱規則，這就會導致即使特定數據就算可以在網站上看到也無法回傳的情況。這取決於數種因素，例如用戶的私隱設定、應用程式層級權限等等。這亦表示 API 回傳的數據並不一定會包含所有在網站上能看到的數據。
只有當帖子被分享超過 10 次時，「shares」欄位才會回傳。如果帖子被分享的次數未滿 10 次，我們可能或跳過這個欄位或嘗試回傳某個數值。
您可以在此深入瞭解這個端點： https://developers.facebook.com/docs/graph-api/reference/v2.4/post。
這是我們舊有基礎建設中使用的舊有數值，我們保留作為新架構的反向相容性。
這個情況只會發生在舊有的帖子，新發佈的帖子就不會有這個問題。
這是可以控制的操作。帖子本身與帖子內的相片並無關聯。我們只會回傳第一張上載到帖子的圖像。
如果帖子來自 Facebook 網站或流動應用程式，「application」欄位就無法回傳。這與網站相同，亦即不會顯示這些帖子類型的出處。
帖子的「privacy」欄位中包含帖子在 Facebook 上的能見度資訊，但是當專頁帖子透過鎖定或限制條件設定，只有特定受眾能夠查看時，「privacy」欄位中的資訊就不會顯示所有您選擇的目標設定選項。
若要查看如何設定帖子鎖定與限制條件的完整詳情，請查看「targeting」欄位（針對限制條件）與「feed_targeting」欄位（針對動態消息目標設定）。請參閱帖子文件進一步瞭解您可以查看的欄位。
帖子回傳的 comment_count 值包含被隱藏或刪除的回應。帖子上可看見的回應數量永遠不會超過 comment_count。
無法覆寫分享網址的「文字說明」。您只能覆寫網址的「標題」與「描述」。
若要深入瞭解以及您可以透過 Graph API 發佈的欄位，請參閱 /feed 文件：https://developers.facebook.com/docs/graph-api/reference/v2.3/page/feed#publish
這是經過刻意設計的。這與 Facebook 應用程式（流動版或網頁版）產生內容的顯示方式一樣（不會歸因到 Facebook 本身）。
我們已經在我們這一端更新了串流與帖子數據透過 API 擷取與呈現的方式。
如果您在使用 API 擷取帖子時遇到問題，並認為操作與文件上的描述不同，請驗證下列項目：
- 您使用的存取憑證擁有合適的權限，可以存取您感興趣的帖子。
- 請確保您執行的所有用於擷取帖子的 API 調用，都是使用上一個調用回傳給您的「編號」，而不是您根據專頁、用戶或其他編號所手動捏造的編號。
這是刻意設計的。針對已經被刪除的物件，或是私隱/權限檢查時看不到的物件，我們的系統會回傳上述錯誤訊息。
此行為模式為預期模式，且回應不支援此分頁型態。
端點 /{user-id}/accounts 的摘要參數的 total_count 欄位可能會回傳比預期更高的數字。這是因為 total_count 亦包含所有被刪除的專頁，而用戶曾擔任這些專頁的管理員。
數據是端點本身所回傳，但其中只包含未被刪除的專頁。
/user/likes 端點已經從時間型分頁（使用「since」和「until」作為參數）改變成游標型分頁（使用「before」和「after」參數）。
您可以參閱下列內容進一步瞭解這兩者的差異：https://developers.facebook.com/docs/graph-api/using-graph-api/v2.3#paging
推出應用程式專屬編號後，我們針對端點回傳數據的方式做了改變。
因為 1.0 版已經停用，我們將重心擺在 2.x 版。/v2.0/{id} 可能會回傳 https://www.facebook.com/{id}，或回傳 https://www.facebook.com/app_scoped_user_id/{id}。
這是刻意設計的。這個錯誤表示您要展延的存取憑證無法存取您要用來展延憑證的應用程式編號。
最有可能的原因是因為如果您的應用程式有套用人口統計資料限制，且我們偵測到您要展延憑證的用戶並不符合這些限制條件（或不再符合這些限制條件，他們可能已經移動到其他地點，或是我們偵測到更精準的所在位置）。
另一個可能原因是我們無法確認用戶達到這些條件（例如我們無法判斷他們的位置），而您的應用程式不允許這些用戶存取應用程式。
所有建於 2014 年 4 月 30 日之後的應用程式，且使用 2.x 版的 API，就只會透過 /me/friends 端點回傳應用程式的好友（如您所述）。此外，所有的用戶編號現在都是應用程式專屬編號，對您特定的應用程式而言是獨一無二且固定的編號。
您可以進一步瞭解所有在 2.0 版推出的新功能與變更項目。
User 物件的 email 欄位的文件中清楚說明了這裡的預期行為：「如果沒有有效的電郵地址，此欄位就不會回傳」。
在很多種情況下，您可能認為會回傳用戶的電郵地址，但他們卻沒有電郵。因為私隱與安全性因素，我們很難明確地判斷特定用戶的電郵地址沒有回傳的原因。
可能的原因包含：
- 帳戶中沒有電郵地址
- 帳戶中沒有確認的電郵地址
- 帳戶中沒有通過驗證的電郵地址
- 用戶到達安全檢查步驟，系統要求他們重新確認其電郵地址，但他們卻尚未完成這個步驟
- 無法取得用戶的電郵地址
這些帖子無法透過 API 擷取，因為這類帖子中包含由專頁重新分享的用戶內容，而該用戶未授權應用程式查看其內容。
如果用戶關閉帖子內容類型的基本權限，用戶分享到專頁生活時報上的帖子就無法透過 API 取得。
如果要看到無法顯示的粉絲相片帖子，您可以使用專頁存取憑證擷取專頁的相簿，那些相片應該出現在生活時報相片相簿中。
在許多情況下，某個特定的應用程式（或任何應用程式）會因為用戶的私隱設定，而無法取得 Facebook 用戶的任何資訊，包含在您的應用程式預期可以看見用戶發佈的帖子時，卻無法存取該帖子。
舉例來說，如果用戶封鎖了應用程式，或禁止所有平台應用程式透過 API 存取其資訊。
推出 Graph API 2.1 版後，這個功能就移除了。針對 2014 年 8 月 7 日前建立的應用程式，此欄位將不再出現於簽署要求中。
在這個日期起，liked 屬性將一律傳回true，無論用戶是否讚好這個專頁。
請直接使用回應中回傳的 paging.next 與 paging.previous 連結，以取得其他結果頁面。使用我們提供的連結可確保未來變更分頁連結的格式時，您的應用程式不會死機。
如同 API 上多數的項目，本來就無法一對一配對主要 Facebook 網站上的特色與功能。專頁洞察報告用戶介面中的「自然散佈接觸人數」有很大的差別，且計算方式也不同於透過 API 取得的「自然散佈接觸人數」。
舉例來說，專頁洞察報告用戶介面中的「organic」值是對應透過 Graph API 取得的「page_impressions_by_paid_non_paid_unique」數據的「unpaid」值。
我們未來將努力讓這個數值更加一致，但可能需要一點時間。
這個錯誤表示與該存取憑證相關聯的用戶因為私隱設定的關係而無法查看該專頁。舉例來說，專頁可能尚未發佈，且用戶也不是專業的有效管理員。
這個錯誤的發生原因通常是因為您嘗試擷取每個活躍專頁的分析報告。如果您減少使用「since」和「until」欄位來要求分析報告的間隔時間，就可以解決這個問題。
只有管理員、編輯或版主才能讀取與傳送專頁訊息。其他角色的用戶（例如廣告客戶與分析師）無法讀取專頁對話。
請前往此頁面進一步瞭解不同的專頁角色： https://www.facebook.com/help/289207354498410。
「page_fans」和「page_fans_country」的總數不一定會相當。有許多因素會影響「page_fans_country」值。舉例來說，部分專頁粉絲並未在其帳戶中設定家鄉國籍，或部分專頁粉絲用私隱設定隱藏其家鄉國籍。
若要深入瞭解 Facebook 私隱設定，請前往參閱幫助中心的網頁： https://www.facebook.com/help/445588775451827。
部分公開專頁帖子是從用戶內容重新分享而來。如果當初建立這個帖子的用戶並未提供必要權限給應用程式，應用程式就無法透過 Graph API 存取其帖子，因此也無法回應這些帖子。
在廣告創意建立流程中以內嵌方式建立的帖子無法單獨加強推廣。因此，這些帖子也無法在傳送至專頁 /promotable_posts 端點的調用中顯示。
如果您是使用還處於開發模式的應用程式來排定這個帖子的發佈時間，就會發生這個問題。請使用已經正式發行的應用程式，應該就能解決這個問題。
很抱歉，我們目前不支援透過 API 建立、更新或刪除封面相片的功能。
若要進一步瞭解封面相片 API，請前往 https://developers.facebook.com/docs/graph-api/reference/cover-photo/#Creating
不能，無法透過 API 編輯寬度。
這是目前設定的行為。專頁管理員無法透過 Graph API 以自己的身分發佈內容至專頁，該功能僅限 http://www.facebook.com/ 與我們的流動應用程式使用。
無法，我們無法提供讚好專頁用戶的完整清單。這是經過刻意設計的。
代替專頁執行動作時，請務必使用專頁存取憑證。該錯誤訊息表示您使用的是用戶存取憑證，而非專頁存取憑證。
您可以在此瞭解不同的存取憑證： https://developers.facebook.com/docs/facebook-login/access-tokens
無法這樣操作。將帖子置頂以及讀取置頂帖子只能透過原生的 Facebook 產品進行操作。
若您曾經針對外部網址啟用回應鏡像，開啟回應鏡像的帖子的心情就會針對網址本身進行記錄，並且於調用 {URL-id}/reactions> 時回傳
目前我們不支援提取 /app_insights/app_event 端點超過 1000 筆的資料細節值。如果您想細分資料以查看特定類別，建議您使用 Facebook 分析工具用戶介面來縮窄特定的資料點，例如特定的國家/地區。
您可以是太快調用端點，因為數據尚未發佈至我們的伺服器。
API 調用應於等待 1-2 秒後才能執行，以便讓資訊發佈至我們的伺服器。
「page_fans_country」數據通常都是「page_fans」計數的子集。此數據包含依據專頁粉絲所在國家/地區細分的資料細節，但前提是我們必須能夠精準判斷該用戶的國籍。
這個數據只包含前端國家（依據粉絲數量排名）的專頁粉絲，並不是有粉絲的國家就會列出；針對在多國擁有粉絲的專頁，粉絲人數最低的國家/地區將不會列在這個數據內。
API 不支援位移型分頁。
請改用 Graph API 每次回應結束後的「分頁」連結，或改用相容性較高的「游標」型分頁。
若要深入瞭解如何透過 Graph API 正確分頁，請參閱： https://developers.facebook.com/docs/graph-api/using-graph-api/v2.3#paging
這是可以控制的行為：搜尋 API 會尊重 Facebook 的私隱設定，而且是為存取憑證的用戶度身訂做的，並不支援主題標籤搜尋，其設計目的與 Facebook.com 上的搜尋自動提示也不同位。
我們刻意不支援或讓搜尋 API 回傳與 Facebook.com 上搜尋同樣的結束數量或特定結果，一般而言，比起 Facebook 上同樣的帖子，透過 API 回傳的帖子必須遵守更嚴格的私隱設定與安全性檢查。
我們的系統針對應用程式傳送的 API 調用設有傳輸率限制。若要進一步瞭解不同的限制，並防止您的應用程式遭到限速，請參閱 https://developers.facebook.com/docs/marketing-api/api-rate-limiting
您可以在不同的專頁上重複使用同一個動態網址，但請注意，文章必須擁有對應專頁認領網域的標準網址才能夠正常擷取。
建議您採用針對每個專頁設定的不同 RSS 動態，每個動態中只包含特定專頁應擷取的文章。
如果文章處於「草稿」模式，那麼只有專頁管理員才看得到這篇文章。一旦文章發佈並轉為「正式」模式，所有的 Facebook 用戶都可以加以分享，並以即時文章的格式瀏覽文章。
如果您有使用「dir="rtl”」屬性在文章中顯示從右至左的語言，可能是因為您用以瀏覽文章的應用程式沒有支援即時文章中從右至左的語言。
請檢查您使用的是最新版本的應用程式。每個支援從右至左語言的最早應用程式版本分別是：
- iOS 版 Facebook：52.0
- Android 版 Facebook：69.0
- iOS 版專頁小助手：44.0
請查看「dir="rtl”」屬性是否出現在文章的 <body> 標籤中。如果您的文章並非使用從右至左的語言，請勿余文章中設立此屬性。
如果文章連結是在即時文章發佈之前被分享，那麼用戶就會被重新導向至文章的流動版網站版本。一旦即時文章發佈之後，只要用戶使用流動裝置瀏覽，所有分享的連結（包含那些在文章發佈前分享的連結）都會自動以即時文章的格式顯示。
我們尚未推出支援 Android 版專頁小助手的開發動態功能。目前要在 Android 裝置上查看文章的替代辦法，就是嘗試新增文章至您的生產動態中，以草稿模式瀏覽。
若要編輯即時文章，您可以使用專頁介面。請利用瀏覽器前往您的專頁，接著前往發佈工具 > 即時文章，然後您就會看到您的文章，並可在此直接編輯。您可在此瞭解更多有關資訊：https://developers.facebook.com/docs/instant-articles/publishing。
目前動態下載時間限制為 30 秒。
不可以，分享連結必須是文章的標準網址。如果網址有所改變（例如加入參數），那麼就會被視為不同的網址。
所有在擷取 RSS 動態時出現的錯誤或警告，都會顯示在「設定」頁面的「即時文章」標籤中。您也可以點擊「發佈工具」頁面的「即時文章」標籤中的文章，以便查看個別文章的警告及錯誤。
我們會嘗試在 10 內完全載入並剖析您的 RSS 動態，該錯誤表示我們無法成功完成這個任務。
解決辦法之一就是減少您 RSS 動態中的項目，例如只包含在過去最多 10 分鐘內新增／變更的文章。因為動態每 3 分鐘就會擷取一次，所以您無須加入沒有變更的文章。
很可惜，我們目前沒有供爬蟲參考的靜態 IP 位址清單。但您可以改用我們爬蟲的用戶代理：facebookexternalhit/1.1
請檢查重複文章是否使用不同的標準網址。我們會使用文章的標準網址作為不重複的識別碼，所以擁有不同標準網址的文章就會被視為是不同的文章。
其中一個常見的原因是如果您的 CMS 以不同的網址更新文章，就會導致更新文章被擷取為新的文章。
是的，每一個專頁都有不重複的對應網域名稱，而且都是一對一的對應方式。 我們要求屬於特定專頁的即時文章必須擁有該專頁指定網域或子網域的標準網址。
但 RSS 動態網址本身的網域則無須對應專頁的網域。這個限制只適用於動態中文章的標準網址。
如果您要根據不同的語言在多個專頁中發佈文章，請針對個別語言設立不同的 RSS 動態，然後配置各個專頁以使用合適的 RSS 動態。
不會，一旦文章從 RSS 動態中擷取，就會一直以即時文章的格式保存著，直到您使用專頁的發佈工具刪除文章為止。所以您可以放心地將文章從 RSS 動態中移除，以便加快下次擷取的速度。
目前我們不支援透過 API 發佈或刪除文章，但我們正在建立這項功能。
「讚好」按鈕會使用您樣式設定中的輔色色彩配置。請檢查您是否已配置了一個與標頭對比的顏色。
此外，「讚好」按鈕只會在瀏覽文章的用戶尚未讚好專頁時出現，所以已經讚好專頁的管理員就不會看到這個按鈕。
請檢查您在同一列中沒有使用多個 <br> 標籤。如果要將文章中的文字分段，建議您使用段落 (<p>) 標籤，而不是分行符號。
請確保您已新增「op-tracker」類別至包夾追蹤像素的 <figure> 標籤中。若沒有這個標籤，這個影片就會被視為內嵌圖像。
這個警告常見的顯示原因是因為您在段落（<p> 標籤）中包夾不含文字的內容，例如圖像或互動式嵌入內容。段落只能含有內文，任何其他內容應新增到 <figure> 標籤中或其他合適的容器元素中。
不可以，Caption (<figcaption>) 元素只支援 <h1>、<h2> 及 <cite> 標籤。無法支援段落 (<p>) 標籤。
若要定義文章中的廣告，請使用包夾廣告標記之 <iframe> 元素中的標準 HTML5 <figure> 元素。您可以將 op-ad 類別套用至 <figure> 元素，以指定文章中的廣告。有兩種方式可以指定廣告：直接使用 iframe 中的「src」屬性指定廣告的網址，或在 iframe 中嵌入完整未轉義的 HTML 和指令碼組合。
您可在此進一步瞭解廣告的相關資訊：https://developers.facebook.com/docs/instant-articles/reference/ad。
標準的圖像元素不支援 SVG 圖像。您可以改用互動式嵌入內容（「op-interactive」），並在 iframe 中新增 <img> 元素，然後將「src」屬性設為 SVG 圖像的網址即可。
您可以參考 Map 元素文件：https://developers.facebook.com/docs/instant-articles/reference/map。建議您使用這個方式將地圖新增到即時文章中。
如果您要將 Google Maps 內嵌到文章作為互動式嵌入內容，目前我們已經知道該內嵌的運作方式可能會影響地圖正常顯示。若要解決這個問題，您必須將載入地圖內容的 iframe ("https://www.google.com/maps/embed?...") 加入另一個 iframe 中。
您可以使用 op-interactive figure 來內嵌互動式模組。您可以在此進一步瞭解更多詳情與範例：https://developers.facebook.com/docs/instant-articles/reference/interactive。
若要定義高度，請在包夾嵌入內容的 <iframe> 元素中加入「height」屬性。屬性的質應為整數，以表示像素中的高度值。可設定的高度上限是 960 像素。
若要在圖像之間加入間隔，您可以在兩個圖像之間加入空白的段落，例如：<p> </p>。
若要新增出處，請使用 <figcaption> 元素中的 <cite> 元素。
若是封面圖像，您可以明確指定 <cite> 元素的其中一個垂直對齊屬性，以指定讓出處固定為顯示狀態。否則，除非展開圖像，否則引述就不會顯示在圖像上。
您需要使用影片檔案的直接連結（例如 mp4 檔案）才能新增封面。鑒於由 Facebook 託管的影片無法提供直接連結，您必須在其他地方託管影片，才能使用該影片作為封面。
您可以在清單項目中使用部分的 HTML 標籤，例如粗體文字或新增連結。若要自訂顏色或字型樣式，您可以使用 Facebook 專頁介面（設定＞即時文章）的樣式編輯器來處理。
如果您是使用 <video> HTML 元素內嵌影片，因為我們不支援連續播放多個影片，所以這樣的方式無法操作。
如果您是內嵌影片播放器作為 iframe 中的社交嵌入內容，只要內嵌播放器是我們支援的格式，應該就能夠正常操作。
我們不支援段落式引文，所以該引文必須放置在段落標籤以外的地方。
如果文章的標題過長導致必須以兩行顯示，那麼只有標題會出現在動態消息中。如果標題長度只需一行顯示，那麼動態消息的預覽也會顯示文章內文的開頭。
您必須在每一篇文章的 HTML 標記中使用 op-published 類別加入 <time> 元素，以便指定文章原始的發佈日期／時間。
op-modified 不是必要元素。只有在您更新文章內容且希望我們更新儲存文章的版本時，您才需要使用這個類別加入 <time> 元素。
請檢查您的 <figure> 沒有包夾在段落（<p> 標籤）中。圖像應包含在直接位於 article 標籤下方的 figure 標籤內。
您可以在包含圖像的 <figure> 標籤中指定「data-feedback」屬性，以便在圖像新增「讚好」與「回應」。舉例來說，若新增「data-feedback="fb:likes,fb:comments”」，那麼圖像就會同時顯示「讚好」與「回應」。
如需更多資訊，請參閱 feedback 屬性的相關文件。
當您在指定如互動式嵌入內容等項目的寬度時，請使用整數值來指定像素寬度。根據預設，項目都是以最大寬度顯示。
若要刪除互動式嵌入內容的間距，您可以在含有內容的 iframe 中加入「no-margin」類別。
如果我們已經批准您專頁的 RSS 動態，即使您變更了動態的網址，也無須再次提交以供審核。
我們每一個專頁都會對應一個不重複的網域名稱，RSS 動態本身的網址無須對應此網域名稱。但動態中個別文章的標準網址則必須屬於相同的網域或其子網域。如果您只需要更改 RSS 動態的網址，就不會造成任何問題；
但如果您同時要更新文章的標準網址以指向新的網域，那麼您就需要透過您的合作夥伴經理提出網域更新的要求，他們就會引導您完成更新流程。
請檢查您的 Facebook 應用程式擁有真正的 iPhone Store 編號、iPad Store 編號（用於測試，不一定要用您實際的編號，可使用 Apple App Store 任何一個應用程式）組合，並於您的應用程式中心平台清單中啟用 iOS - iPad。
這是經過刻意設計的。動態對話框本來就是用來發佈含有附件的內容，所以無法自訂額外的附件。
這是可以控制的變更項目。我們縮短了朋友名單，以便讓您將遊戲邀請傳送給更為合適的玩家。請注意，玩家依然可以使用「搜尋」欄位，選取所有他們要邀請的朋友。
好消息是，透過這個變更項目，我們發現點擊次數開始提升，且整體 CTR 也明顯上升許多。我們很期待繼續優化這個渠道，並找出新的方式讓合適的遊戲能接觸到合適的玩家。
變更 og:title, og:image, etc. 只會影響該連結往後的分享。
用戶或專頁分享連結，且與帖子的互動（回應、讚好、分享等）超過 50 次後，標題就無法變更。這是為了防止網站在您互動後變更連結詳情，導致您看起來像與其他網站互動。所有其他屬性目前都可修改。
如果您分享了連結並更新了圖像，原始分享次數會繼續顯示在舊圖像上，直到您在帖子中重新整理該圖像為止。
若要在帖子中重新整理連結圖像：- 瀏覽至您動態消息中的帖子。
- 點擊帖子右上角的省略符號。
- 選擇重新整理分享的附件。
圖像的裁剪方式會受多種因素影響。例如，我們嘗試以可以偵測到的人臉為圖像中心。
如果您使用大圖像，請儘量保持圖像的長闊比例接近 1.91:1，以便在動態消息中顯示完整圖像，避免圖像被裁剪任何部分。
專頁帖子在連結分享中一律使用大型的橫向圖像。桌面版和流動版動態消息也是如此。請儘量保持您的圖像接近 1.91:1 的長闊比例，以便在動態消息中顯示未經任何裁剪的完整圖像。
圖像是以非同步的方式快取，因此用戶第一次分享您的內容時可能不會顯示圖像。您可以執行下列其中一項來避免這種情況：
- 使用 分享除錯工具 來觸發抓取，以預先快取圖像
- 使用 「og:image:height」與「og:image:width」標籤 以明確指定圖像
大小介於 200 x 200 至 600 x 315 像素之間的圖像只會以小型的正方形格式顯示。
所有的網址都必須使用絕對網址，因為該網址代表了某個資源（網頁／圖像）的標準位置，這樣我們才能夠將分享次數與讚好次數轉移到正確的網址，並正常快取圖像。
原始圖像已無法使用、太大或因為暫時性的問題而無法擷取。請確保我們的網絡爬蟲可正常存取圖像網址、圖像不可大於 8mb，且顯示延遲時間不得超過數秒。
如果您變更網頁的 og:image，請務必保留網站的舊圖像，因為現有分享內容會顯示此白色區域。
這是因為我們資料中心發生複製延遲所導致的現象。這個流程需要幾秒鐘的處理時間，在處理完成前，物件編號無法透過 API 取得。
如果您在廣告完成儲存錢嘗試讀取廣告詳情，可能會收到 GraphMethodException 以及如同 Unsupported get request. Object with ID 'XXXXXXXXXXXXXXXXXX' does not exist, cannot be loaded due to missing permissions, or does not support this operation. 的訊息。
在嘗試擷取廣告詳情前先稍等片刻，應可以解決這個問題。
有時候您在特定宣傳活動中嘗試使用特定廣告創意時，會遇到驗證錯誤。 這是因為宣傳活動的目標與您使用的廣告創意不相容。 例如，您的廣告創意指向畫布遊戲，但宣傳活動目標卻是「MOBILE_APP_INSTALLS」。
若要解決您看到的驗證錯誤，可參考推廣 API 驗證最佳操作實例。
請檢查上載作業階段（未包含問題項目）中沒有任何錯誤。
只有當 deletion_enabled 設為 true 時，項目才能刪除，且不再出現於成功的上載作業階段的動態內。
如果您遇到這個錯誤，請檢查該特定廣告帳戶的狀態。這個錯誤經常是因為廣告帳戶有未結清的餘額所導致。
這是可預期的行為，因為存放在後台的專頁洞察報告數據只能存放 2 年。因此調用才會回傳 0 值。唯一不是 0 值的項目是帖子上的內嵌讚好次數/回應次數/分享次數，這些是帖子自身保留的數據。
請檢查目標設定規格的語法，請務必確保目標設定規格使用有效的 geo_locations 參數與值。
當您以特定目標建立廣告時，系統會套用預設的轉換規格。如果您變更轉換規格，現有的規格就會被覆寫。
請注意，部分廣告目標並沒有預設的轉換規格，所以一定要明確指定。
這可能是因為您鎖定的國家/地區的 work_positions 受眾太少，因此沒有影響接觸人數估計值。我們將持續收集資料，希望可以改善新增至 work_positions 排除條件的人數，進而影響接觸人數估計值。
用戶很可能是透過企業管理平台與該帳戶建立連結，這種方式就不會出現明顯的 Graph API 連結。
請確認您是否已在合適目標欄位指定合作夥伴類別。從「/partnercategories」端點擷取的合作夥伴類別含有一個名為「targeting_type」的欄位，其中指定的目標欄位是您在指定目標類型時所要使用的。
舉例來說，如果您的合作夥伴類別回傳「behaviors」的「targeting_type」，那麼在目標規格中，您就應該在目標規格的「behavior」欄位中使用該合作夥伴類別。
更多有關目標類型與合作夥伴類別的資訊，請參閱： https://developers.facebook.com/docs/marketing-api/partnercategories/v2.3#targeting_types
這個錯誤原因可能是因為自訂廣告受眾沒有設定包含或排除條件。這個問題的最佳解決方法是建立新的自訂廣告受眾，並設定一些包含或排除條件。
更多自訂廣告受眾的相關資訊請見： https://developers.facebook.com/docs/marketing-api/custom-audience-targeting/v2.3。
廣告組合可同時擁有 daily_budget 和 lifetime_budget。帳戶貨幣中定義的 daily_budget 值必須至少為 100 美分，期間必須超過 24 小時。如果您查詢任何一個欄位，兩者都會回傳。如某個欄位未使用，回傳數值就會是 0。
若要深入瞭解，請前往：https://developers.facebook.com/docs/reference/ads-api/adset。
adcampaign_groups 端點使用的是游標型分頁，所以不會回傳次數、限制與位移欄位。建議所有的端點都使用游標型分頁，以便取得一致性的結果。
如需更多使用游標型分頁的相關資訊，請參考： https://developers.facebook.com/docs/graph-api/using-graph-api/v2.0#paging。
有可能是因為部分帖子是以內嵌方式建立的。若要擷取這些內嵌帖子，請參閱此文件底部有關 /promotable_posts「is_inline"」欄位的備註： https://developers.facebook.com/docs/reference/ads-api/adcreative/v2.2#object_story_spec
只要用戶回覆了第一條問題，通訊期間就會開始。如果用戶提供的回答使其失去資格，或者用戶未有回覆，則廣告體驗便會結束，並且廣告會將對話串控制權交給目標應用程式，並提供中繼資料「messenger_lead_gen_incomplete」，以便企業按照後備方案展開將非潛在顧客轉換為顧客的體驗。請參閱 名單型廣告之後的 HOP Webhook ，以獲取更多資訊。
在廣告的「建立範本」對話框中，除非選擇了應用程式，否則系統不會預設啟用傳送摘要。請注意，在選擇了已連結的應用程式後，可在廣告上停用摘要。即使未有選擇應用程式，名單型廣告也會將對話串控制權交給交接的主要接收者（如有設定），或者直接釋出對話串控制權。在提交潛在顧客資料後產生的任何後續追蹤訊息都會傳送至已訂閱的應用程式。應用程式可以查詢對話 API，以擷取訊息記錄，並取得開發潛在顧客流程期間分享的資料。
在名單型廣告刊登期間，系統預設會封鎖 Send API 和 Webhooks。Messenger 開發潛在顧客應用程式（應用程式編號：413038776280800）會掌握對話串控制權。您可使用廣告內的「建立範本」對話框上的「封鎖 Send API」按鈕禁止此行為。
潛在顧客提交資料後，應用程式會獲取用戶訊息的 Webhooks 並可作出回覆。如果某個應用程式被選為相關應用程式之一，則只有這個被選中的應用程式才可作出回覆，並獲取通訊渠道的 Webhooks。通訊期間已開始，相關應用程式可使用 Send API 作出回覆。
您可以前往應用程式網站，使用 Facebook 登入 並將 pages_messaging 權限授予特定專頁，以安裝應用程式。獲授權的應用程式會出現在「進階訊息」的「專頁設定」區塊中。
您只會看到專頁的獲授權應用程式。您可以在「進階訊息」的「專頁設定」區塊中查看獲授權的應用程式。您可以前往應用程式網站，使用 Facebook 登入 並將 pages_messaging 權限授予特定專頁，以安裝應用程式。
可以，單一 Facebook 應用程式可以訂閱多個專頁。與 pages_messaging 權限一樣，接受應用程式審查後，應用程式即可訂閱並接收多個專頁的 Webhook。您可以根據承載情況獲取每個 Webhook 的情境。
您可以改用這個方式在 Messenger Platform 整合作業中使用平台測試用戶：
- 在應用程式中的角色頁面中，點擊「新增」 按鈕以建立新的測試用戶。
- 切換為此應用程式授權測試用戶？選項，並提供「manage_pages」與 「page_messaging」 權限。
- 使用「編輯」按鈕並為此用戶取得存取憑證（使用 2.6 版）。請儲存此憑證備用。
- 使用編輯按鈕以測試用戶身分登入。
- 登入後，以測試用戶身分建立專頁。
- 讓測試用戶使用用戶存取憑證，以取得此用戶的專頁存取憑證。使用以下調用執行此步驟：
https://graph.facebook.com/v2.6/me/accounts?access_token=[TEST_USER_ACCESS_TOKEN]
（文件） - 使用此專頁存取憑證來連結您的 Facebook 應用程式與專頁：
https://graph.facebook.com/v2.6/me/subscribed_apps?method=POST&access_token=[TEST_USER_PAGE_ACCESS_TOKEN]（文件） - 完成這些步驟之後，您會在測試專頁中收到 RTU 更新，並可透過測試專頁傳送訊息給您的測試用戶。
此外，如果憑證的效期太短，您還可以使用長效憑證取代您的存取憑證。請參考這裡的文件：
GET /oauth/access_token? grant_type=fb_exchange_token& client_id={app-id}& client_secret={app-secret}& fb_exchange_token={short-lived-token}
發生這種情況可能是因為下列原因：
- 您是使用來自「Facebook 登入」 的編號。 來自「Facebook 登入」 的編號並不適用於傳送／接收 API。只有透過 Messenger Platform 驗證所取得用戶編號才適用於 Messenger Platform。
- 您是以不正確的專頁存取憑證使用編號。 Messenger Platform 專用的用戶編號有專頁範圍限制，因此是專頁限定的編號。如果您使用一個無效的用戶編號，但配搭一個與其他專頁相關的專頁存取憑證，調用就無法正常運作。請務必使用與同一個專頁相關的用戶編號與專頁存取憑證。
- 您傳送的目標手機號碼近期內並未獲得驗證。 使用傳送 API 配搭手機號碼時，該手機號碼必須於近期內獲得驗證，我們才會傳送訊息。即使手機號碼顯示已驗證，但驗證時間不在近期內，傳送也可能會失敗。重新驗證您的手機號碼，並等待 24 小時後再試一次。
使用「傳送到 Messenger」附加程式時，您可以使用 data-ref 參數作為傳送參數，用來傳送任何與點擊內容有關的資訊。
用戶也可以透過在 Messenger 中搜索以發現您的專頁。在這些情況下，您就不會有傳送參數。您可以使用帳戶連結功能，將對話串連結您網站的用戶帳戶。
Messenger 設定內的應用程式管理中心設有名為「顯示近期錯誤」的按鈕，此按鈕顯示了 Webhooks 是否出現回應 200 或錯誤。
有工具能顯示近期的 Webhooks 錯誤。如果系統無法傳送 Webhooks，則 Facebook 伺服器將取消訂閱您的網址。如需尋找此工具，請前往應用程式管理中心 > Messenger > 設定。在 Webhooks 資訊卡內，您會找到名為顯示近期錯誤的按鈕
請確保您的 webhook 有回應狀態代碼「200」。這能讓我們知道 webhook 已成功接收。如果您沒有回傳「200」，我們將持續重試調用，直到成功為止。此外，若 webhook 長時間沒有回傳「200」，我們就會發出開發人員警示。
此外，請注意成功狀態代碼都會及時回傳。webhook 調用在 20 秒後就算逾時。請務必建構您的代碼讓 webhook 可經過匿名處理，這樣成功狀態代碼才能立即回傳，並分開處理。
傳送到 webhook 的調用中，在標頭有個名為 X-Hub-Signature 的欄位，可用來驗證該調用是來自 Facebook。
收到回調要經過 2 個步驟。首先，請確認您的 webhook 設定是否正確 (https://developers.facebook.com/docs/messenger-platform/webhook-reference#setup)。您可以查看標示以確認 webhook 設定是否正確。
然後您必須訂閱每個專頁。所有已訂閱的專頁都會條列出來。
如果您的 webhook 經過很長的時間都收不到調用，系統就會取消訂閱您的應用程式，屆時您就必須重新加入 webhook 並重新訂閱專頁。
除了提供 OG 標籤給專頁，在分享開放式圖表動態時無法控制帖子在動態消息或生活時報的顯示方式。Facebook 會自動優化帖子，以確保您的內容可以達到最高的互動程度。
是的，動作連結功能已經停用。我們已經移除 Facebook 網站的動作連結支援功能，所以平台也不再支援此功能。未來可能重新開放此功能，但不在目前的計劃當中。
如果您的網頁是使用我們的 OpenGraph 中繼標籤，且包含 og:image 入口點，我們就會擷取該圖像並展示於預覽。此外，如果您的網站提供 og:image、og:image:width 和 og:image:height，甚至連第一次建立的分享內容也將使用該圖像。
如果您無法提供這些參數，就表示您必須等待我們的爬蟲先擷取並分析圖像。請參閱 http://ogp.me/#structured 以查看操作範例。
這是經過刻意設計的。REST API 已經停用很久了，所以也不會產生作用。專頁存取憑證無法與 REST API 併用。
您可以使用 JS SDK 中的「locale」參數來設定「讚好」按鈕的本地語言。這適用於未登入的用戶。如果用戶已經登入，系統也會參考他們的語言偏好設定。如果用戶設定了特定語言，「讚好」按鈕就會以該語言顯示。
您可以在尚未登入 Facebook 的情況下查看自己的按鈕，藉機測試此行為模式（或利用瀏覽器的私隱作業階段）。
分享內容至 Facebook 時，預先填入文字區塊有違 Facebook 政策。您的應用程式用戶必須自行填入他們要分享的文字。
在分享內容時，預先填入文字區塊違反了平台政策 2.3 的規定 ( https://developers.facebook.com/policy/#control )。我們制定這個政策的目的是為了確保用戶在 Facebook 上分享的內容完全是他們自己的想法，避免不小心出現未經用戶同意的文字內容。
如果您有變更或修改網頁的網址，這是可預期的行為。每個代管回應附加程式的網址都會被視為是獨立的開放式圖表物件，且回應與該物件之間有所關聯。因此，如果您修改網址，就會建立新的物件，現有的回應可能就不會出現在該頁面中。
不能，我們不允許透過 API 發佈回應至回應附加程式。
分享附加程式不會允許您傳送自訂參數，只會直接從專頁的開放式圖表中繼標籤提取中繼資料。
若要進一步瞭解內容分享的最佳操作實例，請參考這個文件： https://developers.facebook.com/docs/sharing/best-practices
No this is not possible. Numbers that are registered under WABAs (WhatsApp Business Accounts) can only message regular WhatsApp accounts.
We will provide a seven day grace period post sending the warning. This will allow time for businesses to adjust their behavior. If businesses continue to exceed our internally set threshold of calls to the Contacts API vs. number of messages sent, we will permanently disable the phone number.
Interactive messages can be reopened by the user in order to resend an option. This is in case of mistyping the desired option or wanting to choose a new option.
Through user testing we’ve identified 10 as the optimal number of rows to provide a good user experience. If you have a list of more than 10 options, and cannot condense into one list message, we recommend creating an additional step in the flow and using two list messages. During testing businesses had higher response rates and conversions with this approach than using text-based lists.
Through user testing we’ve identified 3 as the optimal number of buttons to provide a good user experience. If you have a list of more than 3 options, and cannot condense it into one button message, we recommend using list messages. During testing, businesses had higher response rates and conversions with list messages than using text-based lists.
There may be a very small number of users for whom their app version does not support this feature, the business will receive a webhook notification throwing an error that describes why the message was unable to be received. It is up to the business to determine how to handle this error elegantly. Best practice would convert the interactive message to a text-based list to allow the user to complete the workflow.
If there is a delay in a subset of numbers, then it is likely not an issue affecting the customers integration but rather an issue on the recipients end, these delays in delivery can happen for a number of reasons. See Send Message Performance, Delays for more information.
不可以，目前我們不支援更改影音素材儲存空間的預設路徑 (/usr/local/wamedia/)。所有影音素材儲存空間均需要在預設位置下才能正常運作。
沒有辦法，目前我們必須使用 AWS EFS 才能在核心應用程式和網頁應用程式之間分享媒體影音素材磁碟區。
沒有，我們不支援 KOPS。我們支援基於 ECS 的 AWS 解決方案。我們也提供一般 Kubernetes minikube 設定。
核心應用程式將在核心應用程式容器內檢查 /usr/local/waent/data 和 /usr/local/waent/log 目錄，以確保系統至少還有 10 MB 儲存空間可用，否則核心應用程式會將此錯誤視為嚴重錯誤。
請檢查您的記錄和資料目錄，以確保儲存空間充足。
不可以，目前無法在同一個 WhatsApp Business API 用戶端設定中運行多個號碼。我們正在開發妥善的解決方案，以便在未來支援運行多個號碼。
使用資料庫垃圾回收 services API 端點，清除 messageStore.messages 和 messageStore.messages_receipt_log 表格中的訊息和相應的訊息接收資料。
再次檢查 pass_through 應用程式設定。如果您已在 WhatsApp Business API 用戶端 v2.29.1 或更高版本中啟用 pass_through，將無法接收任何讀取狀態回調。
如果您想接收讀取狀態回調，請停用 pass_through 應用程式設定。請注意，停用 pass_through 後，資料庫儲存空間會快速增加。如需有關管理資料庫的詳細資訊，請參閱資料庫管理文件。
資料庫垃圾回收會定期清理 messages 和 messages_reciept_log 表格，以協助管理資料庫。
垃圾回收工具會保留某些訊息，以成功傳送/處理訊息。例如保留特定時間段內已接收的訊息，以便企業整合工具將訊息標記為已讀。
核心應用程式會按照隨機的時間間隔執行垃圾回收（例如每隔幾個小時）。這樣做是為了防止在高可用性堆疊中可能因爭用資料庫而出現效能降低。
垃圾回收與回調佇列無關。例如，如果 4 天無法使用 Webhook 伺服器，系統則會儲存回調，再於 Webhook 伺服器連接恢復時傳送回調。
連結只會在以下情況中顯示為可點擊連結：接收者已將您的企業號碼儲存為聯絡人，或者您擁有官方商業帳戶。
在 v2.29.x 版本之前，可能會因為系統錯誤而導致傳出訊息隊列數量持續增加。請升級至 v2.29.3 版本以解決這個問題。
您有責任根據預期的用戶位置和語言來使用適合的 QR 碼。
現時，系統可以在 WhatsApp Business 管理 API 內直接產生和管理 QR 碼，而用戶可以使用 WhatsApp、iOS 或 Android 相機掃描 QR 碼。
另外，透過 WhatsApp QR 碼
- 預先填妥的訊息可以完全自訂，而且能隨時變更或刪除，
- 用戶之後一律會直接前往應用程式而不會開啟任何插入式頁面，
- 已過期代碼的應用程式內體驗會向用戶傳送清除訊息。
如果用戶嘗試存取已遭刪除的 QR 碼或短連結，他們將會看到 QR 碼／短連結已過期的錯誤訊息。
如果用戶已安裝 WhatsApp 桌面版用戶端，點擊連結後將開啟與您商家之間的對話。否則，系統會提示用戶安裝 WhatsApp 桌面版用戶端。
在新的短連結當中，您可以隨時編輯或刪除與連結相關的預先填妥訊息。短連結還會將網址的語法簡化為隨機代碼，無需在網址中嵌入訊息和遮蓋電話號碼。
為呈現最佳印刷品質，我們建議您使用 .svg 檔案格式。
您可以在 WhatsApp Business 管理 API 或企業管理平台用戶介面中查看、建立、編輯及刪除 QR 碼和短連結。
We are announcing the deprecation of Groups through the WhatsApp Business API. Starting July 8, 2020, only API phone numbers in a group created prior to July 8th can continue to use/manage Groups through the WhatsApp Business API. All other API phone numbers won’t be able to create/manage Groups through the Whatsapp Business API. On October 8, 2020, we will deprecate this feature for all API phone numbers (i.e., API phone numbers will be removed from their groups and no longer be able to send messages to their group).
如果您或您的最終客戶想申請成為 WhatsApp 官方企業帳戶，請查看申請官方企業帳戶文件的相關內容。
不適用。收發訊息限制目前僅適用於企業發起的訊息（通知）。
使用 WhatsApp Business API 以相簿形式傳送圖像時，您需要最少連續傳送 4 張圖像。如果用戶收到圖像時，其對話視圖處於活躍狀態，則需要等待至下次存取時才能使用相簿視圖。
如果出現以下任何情況，則將無法建立相簿：
- 含有說明文字的圖像
- 出現未讀分隔符號 - 用戶只查看了部分圖像
- 日期標題不一致 - 圖像跨日傳達
不可以。WhatsApp Business API 用戶端目前無法在 Docker for Windows 中運行。如有開發需要，我們建議您使用 Linux 虛擬機器，並在此虛擬機器中運行 Docker。如需處理正式版負載，我們建議您使用 Linux 伺服器，以避免出現相容性和性能問題。
471 錯誤代碼與根據品質而定的傳輸率限制有關。請參閱根據品質而定的傳輸率限制文件，以進一步了解更多資訊。
所有企業均會從最低等級開始；當他們傳送更多高品質的訊息時，系統便會自動將之升級至更高的等級。
是的。傳送訊息範本後，如果它無法在接收端顯示，您將會收到「失敗」狀態回調，而且錯誤物件為「無法使用此結構」，代表訊息未能顯示。視乎接收人的情況，您亦可能會收到「已送達」狀態回調，這代表訊息已成功傳達至接收人，但接收人未能顯示訊息。
以下是訊息範本傳送端驗證錯誤訊息，以及出現此類錯誤的原因：
- 「語言 your-language 沒有任何訊息範本」或「語言 your-language 和本地語言 your-locale 沒有任何訊息範本」— 您所選的語言套件不存在。請檢查您的企業管理平台帳戶。
- 「語言 your-language 沒有範本 your-template-name」或「語言 your-language 和本地語言 your-locale 沒有範本 your-template-name」— 您正在嘗試使用不存在的範本（尚未建立或獲批）。如果您在嘗試使用已刪除的範本傳送訊息，則亦會出現此錯誤。
- 「localizable_params 的數量 num1 與預期參數數量 num2 不符」— 您正在嘗試傳送參數不符合預期參數數量的訊息範本。請檢查您的 API 調用是否準確無誤。
- 「your-template-name 屬於多樣式範本，需要範本訊息 API 才能使用」— 您正在嘗試將媒體訊息範本作為一般訊息範本傳送。請確保訊息類型是
template。詳情請參閱媒體訊息範本文件。 - 在企業管理平台中批准（或刪除）範本後，WhatsApp Business API 用戶端將會在最多 20 分鐘後接收已更新的範本。如果您想使用剛獲批的範本來傳送訊息，而且收到表示範本不存在的錯誤，您可等待 20 分鐘，然後再嘗試傳送訊息。
為了確保用戶最少收到訊息一次（而非只收到一次），系統或會向 WhatsApp Webhook 傳送重複的訊息。如果這個做法影響了您的訊息處理方式，我們建議您按訊息編號為 Webhook 訊息刪除重複資料。
如果您在設定 AWS 部署時遇到類似以下內容的錯誤，請嘗試將堆疊名稱改為不超過 8 個字元。
國家/地區名稱（雙字母代碼）[AU]：州或省份（全名）[Some-State]：地點名稱（如城市）[]：機構名稱（如公司）[Internet Widgits Pty Ltd]：機構單位名稱（如部門）[]：常用名稱（如伺服器完整網域名稱或您的姓名）[]：字串過長，長度不得超過 64 位元 常用名稱（如伺服器完整網域名稱或您的姓名） []：電郵地址：錯誤，製作用於 internal-wa-inc-name-LB-123456789.ap-southeast-1.elb.amazonaws.com 的證書要求建立裝置金鑰時，出現配置檔案中沒有指定物件的問題
訊息範本可用的參數數量沒有任何限制。
每個 WhatsApp Business 帳戶最多可有 250 個訊息範本。
如果 Webhook 事件由於任何原因而無法送達（例如用戶已離線），或 Webhook 要求傳回 200 以外的 HTTP 狀態碼，則我們將嘗試再次傳送 Webhook。我們將繼續嘗試傳送，並將延遲時間增加到特定逾時期限（一般為 24 小時，但亦可能會有所不同），或直至傳送成功。
在某些情況下，您可能需要更多時間來處理顧客的查詢，或者您只能在 24 小時後回覆其訊息。我們建議您建立訊息範本，以用於下列兩個用途：
- 將結果傳送給用戶，或者
- 提醒用戶作出回覆，以啟動客戶服務期限。
在這兩種情況中，請務必盡可能為訊息範本提供最多的背景資訊。例如：
- 「{{1}}，您好！關於您先前回報的問題，我們很遺憾地通知您 {{2}}。如有任何不便之處，敬請原諒。」
- 您的問題單已有所更新。如果您想繼續使用支援服務，請回覆。」
WhatsApp 會展開一系列的試驗，以衡量和了解 WhatsApp Business API 通知對用戶體驗和整體產品的影響。如果您想向其傳送訊息的用戶正在參與此類試驗，則即使他們已選擇接收您的通知，他們也有可能收不到它們。
是，網頁應用程式容器和核心應用程式容器的記錄輪替將略有不同：
- 網頁應用程式：系統會保留最近 30 天的記錄檔案。只有記錄檔案大小超過 20MB 時，系統才會執行記錄輪替。
- 核心應用程式：系統會保留最近 30 天的記錄檔案。只有記錄檔案大小超過 15MB 時，系統才會執行記錄輪替。系統將會壓縮已輪替的檔案。
WhatsApp Business API 用戶端的所有組件均會在發佈之日起 6 個月後過期。如果您看到此錯誤訊息，請儘快升級至最新版本。
請注意：由 v2.27.8 開始，fallback 語言政策已停用，現時的預設政策為 deterministic 語言政策。
建立新語言的翻譯時，您必須將您使用的所有元素翻譯成該語言。否則，您可能會因為接收人的手機無法找到其支援語言的某個元素，而收到「無法使用此結構」錯誤。此類「無法使用此結構」錯誤會在使用 Fallback 政策傳送範本訊息時顯示。
如果您暫時不想建立語言翻譯，則可以使用 Deterministic 政策，以避免出現此類錯誤。
用戶可透過文字或影音素材檔案的形式傳送訊息負載。
如果是文字，我們相信這不會造成任何危險。
如果是影音素材檔案：
- 在一般情況下，企業應已安裝一些防護軟件（即防毒及防惡意軟件等），以便分析任何潛在風險。
- 由於我們會為傳輸的檔案使用端到端的加密方式，因此 WhatsApp 將無法識別或檢查其中的內容（這亦適用於純文字內容）。
- WhatsApp Business API 用戶端亦設有停止自動下載影音素材檔案的選項。如果企業不想接收用戶的任何檔案，則可將
auto_download欄位設定為空白陣列。
不可以，WhatsApp Business API 不支援偵測是否有多部裝置正在使用相同電話號碼的功能。
如果手機無法讀取範本訊息，「structure unavailable」錯誤便會出現。
範本儲存在伺服器上。當用戶使用 messages 節點傳送範本訊息時，系統僅會將命名空間、語言、元素名稱和本地化參數傳送至手機，不會傳送整則訊息。手機收到這些值後，就會嘗試顯示這則訊息。
如果顯示期間出現任何錯誤，系統會向回呼網址傳送 structure unavailable 錯誤，其中包含傳送對象和訊息編號。命名空間錯誤、本地化參數不符、元素名稱錯誤等都是導致此類錯誤的原因。
請前往 Facebook 企業管理平台中的「WhatsApp 管理工具」查看正確的參數數量。請仔細檢查命名空間是否正確，以及元素名稱是否存在。
一個常見的錯誤原因就是沒有為所有使用的範本建立翻譯。例如，如果您有兩個經常傳送的範本，而您為其中一個範本加入了新語言翻譯，則請務必也為另一個範本加入該語言的翻譯。如果您計劃支援多種語言，則需要為所有範本提供所有支援語言的翻譯版本。
不過， structure unavailable 錯誤通常源自 messages API 呼叫中的錯誤，可透過變更傳送裝載來解決。
您可以前往 Facebook 企業管理平台的 WhatsApp 帳戶，以註冊新手機號碼，以及刪除舊手機號碼。
- 在 WhatsApp 帳戶中，前往設定。
- 點擊 WhatsApp 管理工具。
- 選擇手機號碼標籤頁。您可以在此處管理此帳戶的所有手機號碼。
如果是圖片，系統會將說明加入為描述。在 Android 和 iPhone 中，系統均會顯示圖片說明的完整文字。
如果是文件，則說明內容會取代檔案名稱。系統並不會在用戶裝置中將之顯示為描述文字，而是會將之顯示為檔案名稱。iPhone 會顯示全部文字，而 Android 則會截斷檔案名稱，這是由於 WhatsApp 在這兩種裝置中當前安裝方面的技術限制所致。
如果您在使用「短訊」註冊時，因嘗試次數過多而導致失敗，並且看到「存取遭拒」訊息，則請使用「語音通話」方式來註冊
目前的快取週期為 7 天。如果 7 天後快取仍未有更新，則不論套件內是否有相應的元素，系統均會從伺服器擷取最新的語言套件。
裝置將先從快取中載入內容；如果某個元素已存在，就會使用該訊息範本開啟訊息。因此，最安全的做法是直接加入包含不同元素名稱的新訊息範本，而非修改訊息範本。這樣可以確保當語言套件找不到該元素時可以重新下載。訊息範本的儲存成本低得可以忽略不計，因此完全沒有必要刪除訊息範本。
請參閱傳送訊息範本 — 語言，以了解更多相關資訊。
為了確保企業和用戶能夠享用優質的體驗，WhatsApp Business API 目前僅開放予公眾預覽部分內容。如果您有意與我們合作，歡迎提交更多有關您企業的資訊供我們審查，以便我們日後擴大使用範圍時邀請您加入；或者，如果您已有 Faceook 代表，您亦可聯絡該代表。
只需透過 users 端點將用戶登出，即可令分配至該帳戶的所有身份驗證憑證無效。此外，刪除用戶也有相同的作用，雖然這種做法比較極端。請注意，如要透過 users 端點讓用戶登入，系統將會傳回新的身份驗證憑證，但不會使該用戶已在使用的身份驗證憑證無效。任何擁有先前預先分配的憑證之用戶均可繼續使用該憑證，直至憑證過期，或您透過上述其中一種方法使之變為無效為止。
如果您看到此錯誤，但您 json 正文已設定錯誤訊息所列的缺失必要參數，則有可能是 json 解析錯誤。當整個 json 的負載因 json 格式錯誤而無法解析時，便會出現此錯誤。查看那些參數值是否有無效的 json 字元，如末尾的歸位字元。有時您也可能會在複製參數時複製了多餘的空格，而這些空格可能會包含破壞 json 的字元。
當中的原因有許多種。這可能是因為您的核心應用程式發生故障，或您的資料庫沒有正確地設定。如果不是這兩種情況，請查看核心應用程式記錄（如果您正在運行多點連線，則請查看主要核心應用程式記錄）。如果您看到資料庫連接出現錯誤，則可能是因為您的資料庫連接已用完。請參閱 MySQL 文件或 PostgreSQL 文件，以了解更多關於此錯誤的資訊。
我們建議您增加資料庫連接的數量。一般而言，1000 個資料庫連接算是比較安全的數量，但請您根據實際情況作出相應的決定。如果錯誤仍然存取，請建立支援問題單。
訊息範本遭拒的原因可能有以下幾種：
- 包含可能有侮辱性的內容，例如侮辱性語言或垃圾內容
- 包含推廣內容
- 與所選標籤類型不符
- 格式不正確
如果您收到「連接已被拒」錯誤，這有可能是因為核心應用程式沒有運行。請使用 docker ps 查看核心應用程式是否正在運行。如果它未有運行，請查看 Docker 記錄。核心應用程式可能無法連接至資料庫。請確保您已正確地設定資料庫。
當 Docker 網橋損壞時，便會發生此錯誤。解決此問題的最佳方法就是關閉並重新啟動 Docker 服務。您亦可以在容器執行 docker restart。
WhatsApp 必須驗證某個電話號碼是否屬於某部手機。如果用戶擁有 WhatsApp 帳戶，則證明他們已確認此電話號碼，而且之後也沒有其他用戶使用此號碼來註冊 WhatsApp。然而，這並不能保證 SIM 卡的實際位置。
另一方面，如果用戶的手機丟失或遭竊，他們也可停用他們的 WhatsApp 帳戶。如要進一步了解用戶如何停用帳戶的資訊，請參閱有關手機丟失與遭竊的常見問題。
如果顧客已停用其手機號碼，但仍在使用 WhatsApp，則顧客可以繼續使用 WhatsApp，直至該手機號碼獲重新分配或重新註冊為止。
WhatsApp strongly verifies whether number provided actually belongs phone. The fact that a user has a WhatsApp account is proof that they confirmed the number and no one else has used that number to register on WhatsApp subsequently. However, It is not a guarantee of the physical location of the sim.
On the other hand, if users phone is lost or stolen, they can deactivate their WhatsApp account. You may read to know more about how users can deactivate their account here.
這是一個已知的問題。有時候，當使用 CloudFormation 指令碼升級 WhatsApp Business API 用戶端時，您亦需要升級 RDS DB 堆疊。新的 RDS 堆疊與原來的堆疊主機名稱有所不同，因此 Docker 容器無法連接至資料庫。若要解決此問題，請為由 CloudFormation 建立的 EC2 實例使用 SSH，並使用新的主機名稱更新 whatsapp.conf 檔案，然後重新啟動 Docker 容器，以便容器獲取新的設定。
Use the mcdockerreset script and tear down the webapps then use the mcdockersetup script to bring up a new webapp.
Reason: When the webapp first connects to the DB, it creates the database.yml file. it will never try to create it again. The coreapps will just not start up on a bad DB config; however, the webapp will, so you see the master and slave nodes in your DB because they were setup correctly once you got around all the DB and script issues but the webapps were started by the script in a bad state to begin with.
如果 Webhook 無法傳送回調，系統便會將該回調置於重試佇列中。系統無法接收在初始回調失敗後發出的任何回調。失敗的初始回調必須傳送成功，系統才可接收其餘的回調。
WhatsApp Business API 用戶端會透過核心應用程式容器向您傳送 Webhook 回調。因此，您需要配置您的 Webhook 端，以便它接收來自核心應用程式的已接收要求。
請註冊第二個手機號碼，並建立第二個 CloudFormation 堆疊或 Docker 實例以供測試。如果您有兩個使用相同手機號碼的 WhatsApp Business API 用戶端，則伺服器會因加密金鑰有所衝突而將您登出帳戶。我們建議您先設定第二個可用於測試非正式版實例的環境，然後再在正式版用戶端執行任何遷移動作。
您必須使用 MySQL 5.7.x、PostgreSQL 9.5.x、9.6.x、10.x。使用較舊的版本會導致出現 Unable to initialize config store 錯誤。
當您傳送訊息時，只要您獲得訊息編號，便代表系統已將該訊息要求儲存在資料庫中。WhatsApp Business API 用戶端會不斷嘗試傳送該訊息，直至收到 WhatsApp 伺服器的確認為止。這個過程不設任何結束期限。然後，WhatsApp 伺服器會嘗試將該訊息傳送至用戶的手機。如果用戶的手機不在線，則系統會將訊息存儲在 WhatsApp 伺服器 30 天，然後將之捨棄。
資料庫表格會儲存與應用程式設定、聊天室對話串、訊息和影音素材等相關的資訊，而且應用程式必須使用這些資訊才能運作。
當顧客更改其 WhatsApp 手機號碼時，您的企業不會獲取相應的通知。當您使用 contacts 節點時，該號碼的狀態將會顯示為 invalid。
不可以，您只能為每個實例運行一個帳戶。如果您需要第二個測試帳戶，請務必為第二個實例使用不同的電話號碼。
隨著儲存空間逐漸變滿，您的系統運行速度或會開始變慢。這可能是因為您的影音素材檔案、訊息和大型記錄檔案過多。系統會自動輪替記錄檔案，但如果記錄檔案開始變大，您也可以安心將之刪除。
系統會將訊息儲存至資料庫中。如有需要，您也可以刪除訊息。此外，如果您在應用程式設定中將pass_through 設定為 false，則除非您明確地將之刪除，否則系統會將所有訊息儲存在資料庫。
系統會將用戶傳送給您的影音素材檔案下載至影音素材磁碟區。企業可自行決定刪除哪些影音素材，但一般情況下，您都可安心刪除任何影音素材檔案。您可以使用 docker inspect your-container-id 來查看影音素材磁碟區資料夾的所在位置。
請遵循 Docker MySQL 指南的指示，使用 Docker 在本機設定 MySQL。
請遵循 Docker PostgreSQL 指南的指示，使用 Docker 在本機設定 PostgreSQL。
在大多數情況下，您應該使用與核心應用程式和網頁應用程式容器分開的實體伺服器來運行數據庫。數據庫伺服器與電腦之間只可有幾毫秒的延遲時間。
您可以自行決定何時刪除影音素材。
上載影音素材後，您將收到一個影音素材編號；您可以使用此編號傳送一則包含已上載影音素材的訊息。傳送影音素材訊息後，WhatsApp Business API 便會將影音素材解碼並上載至 WhatsApp 伺服器，且伺服器會將之保留 14 天。之後，您便可以自行決定刪除此影音素材（方法為提供影音素材編號），還是保留它供日後使用。我們建議將影音素材保留 30 天；您可以根據貴公司的政策或使用案例，自行決定具體保留時間。
可以。您可以將資料庫用於其他用途，只要不影響與 WhatsApp 相關的表格即可。
可以！WhatsApp 允許您為訊息的所選文字使用粗體、斜體、刪除線或等寬字體。
支援，訊息範本支援所有 WhatsApp 訊息字元和格式，包括表情符號、粗體、斜體等。如要使用表情符號，請使用表情符號字元（複製/貼上），而不要使用其相應 Unicode。
不可以！不管在任何時候，一個手機號碼都只能運行一個 WhatsApp Business API 用戶端實例。一旦您註冊了第二個實例，第一個實例就會被關閉並失效。我們正在研發有效解決方案，以助您做到這個動作。如有任何最新消息，我們會立即通知您。
企業 API 用戶如果在其所控制的伺服器上管理 API 端點，WhatsApp 便視其通訊為端對端加密通訊，因為第三方無權存取端點之間的內容。
部分機構可能會選擇委派第三方企業解決方案供應商來管理其 WhatsApp Business API 端點。在此類情況下，通訊仍使用相同的訊號協定加密。但是，由於 WhatsApp Business API 用戶已選擇交由第三方來管理其端點，因此 WhatsApp 將不會視此類訊息為端對端加密。在未來於 2021 年，此做法也將適用於選擇使用由 Facebook 託管的雲端版本 API 之企業。
此外，如果您在向 WhatsApp Business API 用戶端發出調用時使用 HTTPS，系統便會 SSL 加密相關資料 （從後端用戶端至 WhatsApp Business API 用戶端）。
更多詳情請參閱我們的 WhatsApp 加密概覽技術白皮書。
這是由舊版 iOS 用戶端的一個錯誤引起的失敗訊息。隨著一般用戶升級其用戶端，此錯誤的出現頻率應會逐漸減少。
不能，我們無法保證訊息的送達順序會與它們的傳送順序相同。如果訊息排序對您的使用案例十分重要，則我們建議您先偵聽第一則訊息的送達回調，然後再觸發第二則訊息。
下列指令碼可在外部觸發，以便清除容器的舊記錄：
docker exec CONTAINER_NAME /opt/whatsapp/bin/cleanup.sh
此指令碼同時適用於網頁應用程式容器及核心應用程式容器。運行指令碼後，系統便會移除舊的記錄檔案，並僅保留容器中最近 30 天的記錄檔案。
備註：請勿使用 WhatsApp Business API 向同一位傳送對象重複傳送相同訊息。
訊息送達率不是 100% 的原因有很多種。其中一些常見情況包括：用戶的網絡斷斷續續、用戶在一段時間內沒有任何活動，或建立 優質用戶體驗。
可以透過 WhatsApp 送達的訊息會有非常高的送達率。可是，也有很多原因會導致訊息傳送失敗。您可以監察回呼，以了解訊息的具體狀態。由於您無法存取最後送達狀態，而再次傳送訊息可能反而會產生不同成效，因此這方式有別於短訊等其他訊息傳送方式。
訊息可能會因為用戶手機停機、沒電，或用戶在遺失手機後更換新手機並停用 SIM 卡，而無法送達至用戶。另此，企業的用戶端網絡連線功能也有可能出錯，系統也有可能無法送達回呼（Webhooks）。您可使用此 health 節點監察這些狀況。只需開啟伺服器接收回呼，即可知道訊息有否成功進入 WhatsApp 伺服器雲端。
當用戶重新連接至網絡時，您之前所傳送的所有訊息都將會送達至他們。對用戶而言，重複收到內容相同的訊息會令體驗欠佳。他們較有可能會封鎖或投訴您，而您亦較有可能會被停權。
如果您在傳送訊息後收到了來自 API 的訊息編號，則代表您已經完成可做的操作來傳送此訊息。請勿向同一位傳送對象重複傳送相同內容。
如果您發現送達率長期偏低，請提交支援工作單至 直接支援服務。
WhatsApp Business 企業內部 API 用戶端需要使用資料庫來儲存密鑰，以解密商家與顧客之間傳送的訊息。WhatsApp 上的所有訊息均以傳送者和接收者密鑰以作加密處理。顧客密鑰儲存在其流動裝置上，商家密鑰則儲存在其資料庫中。詳情請參閱 WhatsApp 安全。
WhatsApp Business 雲端 API 是 Meta 託管商家資料庫的替代方案。透過使用雲端 API，您可以直接執行 WhatsApp Business API，無需花費成本託管自己的伺服器。了解詳情。
不需要。WhatsApp Business API 用戶端會建立一個連接至 WhatsApp 伺服器端口 5222 或 443 的已發出 TCP 連接。TCP 流量會在此長期連接中產生。通常，防火牆將之分類為允許「已接收流量和已有流量」。當然，一旦建立了連接，套件將會來回傳輸，但由於此連接將由 WhatsApp Business API 用戶端開始建立，因此不需要訂立允許已接收連接的規則。
我們的系統支援 MySQL 和 PostgreSQL。如果您自行運行 Docker，則必須為要連接的容器提供一個 MySQL/PostgreSQL 資料庫。如果使用 AWS 範本，則系統會預設設定 MySQL 資料庫。
相關的必要條件取決於您的具體負載和情況。解決方案可在任何運行 Docker 且連接至互聯網的裝置中運作。例如，您可以使用手提電腦來進行簡單的測試。
若是單一實例的正式版伺服器設定，我們建議最少配備 250 GB SSD、16GB RAM 和 4 核 CPU。我們不建議您使用 HDD，因為 I/O 速度會在承受負載時變成阻礙。
若是多點連線的正式版伺服器設定，我們建議每個核心應用程式/主節點/網頁應用程式容器最少配備 50 GB SSD、4 GB RAM 和 2 核 CPU。
在大多數情況下，您應該使用與核心應用程式和網頁應用程式容器分開的實體伺服器來運行數據庫。數據庫伺服器與電腦之間只可有幾毫秒的延遲時間。
此設定支援每秒傳送大約 20 則訊息。
當然可以！請聯絡您的 WhatsApp 代表，以提出此要求。
我們暫時尚未提供這種做法。如果您無法處理用戶透過 WhatsApp 傳送的已接收回應，則我們建議您傳送自動回覆訊息，以將戶重新導向至合適的支援渠道。
可以，我們可以在您準備好正式使用功能時設定新手機號碼或更改已驗證名稱。
上載檔案大小不能超過 64 MB，而此限制亦適用於與訊息一同傳送的任何圖像、文件或影片。
不可以。WhatsApp Business API 解決方案要求使用從未註冊過的電話號碼。
如要尋找影音素材磁碟區的掛載點，請運行 Docker 指令。
要求
docker volume inspect whatsappMedia
回應
[
{
"Driver": "local",
"Labels": {},
"Mountpoint": "/var/lib/docker/volumes/whatsappMedia/_data",
"Name": "whatsappMedia",
"Options": {},
"Scope": "local"
}
]然後，如要查看全部已接收影音素材檔案，請使用已收到的 Mountpoint 檔案路徑運行 ls 指令：
ls /var/lib/docker/volumes/whatsappMedia/_data/
若是 AWS 設定，您可將影音素材磁碟區掛載至主機的 /mnt/wa/media 路徑。
您可以運行以下程式碼，以重新啟動 Docker 容器：
核心應用程式 Docker 容器
docker restart wacore<Current_WABA_Version>
網頁應用程式 Docker 容器
docker restart webapp<Current_WABA_Version>
您可以檢查自己正在運行哪個版本
docker ps
- The Page must be categorized as "App Page"
- You should have access to the page via a role
- The App Page should not already be linked to an existing app
- The Page must have the same name (or a subset of the name) of the app
- An admin of the campaigns
- A full admin of the page
2. There won't necessarily be a read receipt for each message. The read receipt means that ALL messages before this watermark timestamp have been read by the user.
- 應用程式傳送給用戶的遊戲要求是透過 /apprequests API 端點傳送的。他們會在遊戲活動動態中產生要求，但不會在網站中產生通知。https://developers.facebook.com/docs/graph-api/reference/app-request#Creating
- 用戶傳送給用戶的遊戲要求是透過要求對話框傳送的。他們會在遊戲活動動態中產生要求，並且會在網站中產生通知。https://developers.facebook.com/docs/games/services/gamerequests
- 另外還有應用程式傳送給用戶的通知，這是透過 /notifications API 端點傳送的。他們會產生通知，但不會在遊戲活動動態中產生要求。https://developers.facebook.com/docs/games/services/appnotifications