如果發生類似「抱歉，有些地方出錯了」的錯誤，並且難以確定原因，您可以選擇啟用更詳細的錯誤訊息，或許可以顯示更實用的資訊。 如需深入瞭解該 SDK init() 方法的偵錯旗標，請參閱 https://developers.facebook.com/docs/accountkit/webjs/reference
當 Android 用戶輸入的電話號碼符合其在 Facebook 列出的電話號碼時，Account Kit 即時驗證會略過以簡訊取得驗證碼的步驟。
只有在用戶使用 Android 版 Facebook 應用程式時，這才可行。如果我們無法確認電話號碼是否相符，會將用戶導入一般流程，並透過簡訊收到驗證碼。
對於以下名單中的語言，Account Kit 會顯示本地化 UI：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 天的期間，每次重新提交不會重設這 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 時，不需再進行一次商家驗證。
所有呼叫「Facebook 登入」延伸權限的現有應用程式和 6 個 API（粉絲專頁、Messenger、企業管理平台、Instagram、社團和事件）都需要提交到新的應用程式審查程序，程序包括企業管理平台驗證和合約簽署。不需在此日期之前完成應用程式審查，只要提交即可。如果未在 2018 年 8 月 1 日之前提交，2018 年 8 月 2 日將失去對這些 API 的存取權限。
所有呼叫行銷 API 和名單型廣告擷取 API 的現有應用程式都必須提交到新的應用程式審查程序，程序包括 2019 年 2 月 1 日之前必須完成的企業管理平台驗證和合約簽署。
每家企業僅需驗證一次，合約也僅需由指定人員代表企業簽署一次。後續提交的應用程式須完成應用程式審查，但不必驗證。
應用程式是否需要審查，應視應用程式的編號層級決定。使用特定權限或功能的每個應用程式都必須接受審查。
圖形 API 3.0 版中的企業管理平台 API 沒有任何變更。如果應用程式需要 Business_Management 存取權限，就必須經過 Facebook 審查。
Facebook 的應用程式審查政策變更並不會影響使用 Facebook 行銷 API 的應用程式。如需瞭解實際 API 的變化，請參閱圖形 API 變更紀錄。
會。未經應用程式審查的應用程式只能存取用戶的名稱、電子郵件地址以及大頭貼照。所有其他權限皆須經 Facebook 審查。
圖形 API 3.0 版不會影響 Instagram API。不過，凡使用 Instagram API 的應用程式，一律需經 Facebook 審查。
在圖形 API 3.0 版中，存取事件的應用程式需使用 user_events 權限。使用該權限的應用程式需經 Facebook 審查。
圖形 API 3.0 版已停用 user_managed_groups 權限。應用程式可以使用新的圖形 API，以及取代這項權限的 publish_groups 和 read_groups_user_data 權限。應用程式必須通過 Facebook 審查，才能使用新的 API 和權限。
圖形 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 整合，才能夠批准您的應用程式提交資料。
如果審查人員無法載入或使用您的應用程式，請檢查以下事項：
- 應用程式網址可公開存取而且未設定為 localhost
- 您已經提供存取您的開發或預備網站所需的用戶名稱和密碼
- 您的網站具有最新的安全憑證，而且對新用戶不會造成錯誤
- 您能夠以新建的測試用戶身分登入和使用您的應用程式
- 您提交審查的項目已開發完成而且已在您的應用程式中運作
如果您因相同原因再度遭到拒絕，請更新審查指示或新增備註區塊，要求審查人員提供更明確的說明以及其他資訊。
我們的審查團隊將使用您提供的指示來測試您應用程式的 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 應用程式發佈的網址未指回應用程式擁有的網域，「串流貼文網址安全性」轉移就會禁止您的 Facebook 應用程式發佈這些網址。如果您的應用程式會發佈前往其他網站的連結，請勿使用此選項。
這是預期的行為，並且在這裡提供說明 - https://developers.facebook.com/docs/apps/test-users#rules：測試用戶無法成為公開 Facebook 粉絲專頁的粉絲，也無法在其中建立內容，例如在粉絲專頁的塗鴉牆上留言。然而，測試用戶可以在應用程式建立的相關聯粉絲專頁上，檢視以及與任何應用程式頁籤互動。
這個情況有其目的。為了安全起見，我們不允許使用多個任意網域。
這是預期的行為。「登入」對話方塊會使用固定寬度，不會縮放以符合較大的螢幕。
這是預期的行為。開發人員必須負責依據用戶的裝置設定適當的「redirect_uri」。因此，如果用戶使用的是行動裝置，「redirect_uri」就必須是行動網站網址。
這是預期的行為，因為這樣能夠防止可能的安全性漏洞。有些瀏覽器會在重新導向的新網址末端附加網址的雜湊片段（如果新網址本身沒有雜湊片段）。
例如，如果 example1.com 傳回往 example2.com 的重新導向，那麼前往 example1.com#abc 的瀏覽器就會前往 example2.com#abc，而 example2.com 的程式碼就可以存取 example1.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 像素的圖像。」
為網址挑選圖像時，我們會先查看您的「og:image」標籤，看看標籤是否存在，以及是否符合 200x200 像素的要求。如果沒有「og:image」標籤，我們就會選擇在網頁上找到的第一個圖像。
如果您收到錯誤，但是認為您的網站圖像大於 200x200 像素，就應該確認您是否已正確設定「og:image」標籤，因為最可能的原因是我們從您的網站擷取了錯誤的圖像。
我們已變更分享外掛程式的行為，以便與開放平台中其他外掛程式和功能的行為一致。
分享外掛程式不會再接受自訂參數，Facebook 也會從網址 OG 中繼標籤載入預覽中顯示的資訊，如同以貼文方式顯示在 Facebook 上一樣。
否，分享網址上的「caption」無法覆寫，只能覆寫「title」和「description」。
應用程式無法上傳內容到其他應用程式建立的相簿。
在某些情況下，有些相簿不會與任何應用程式建立關聯（塗鴉牆相簿）。建議您檢查 can_upload 欄位。如果 can_upload 欄位傳回 false，就表示用戶無法透過個人檔案的相簿檢視，直接將相片直接放入此相簿中。
影片播放完後，行動呼籲將顯示在「重播」圖示下方。
GIF 的大小必須小於 8MB，才能夠在 Facebook 播放。
目前並不支援透過 API 對未發佈的貼文建立留言。
內嵌建立的影片貼文不會顯示在 promotable_posts 端點中，因為這類貼文已經獲得推廣。內嵌建立的影片貼文是在廣告建立流程的一部分中建立的貼文，因此無法單獨加強推廣。
因此，內嵌建立的貼文也不會顯示在 /promotable_posts 端點中。
如果您使用粉絲專頁存取權杖，而且與該權杖關聯的用戶在粉絲專頁「設定」下的「粉絲專頁角色」中列為分析師，就可能會發生這種情況。
使用圖形 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。
分享網址的「caption」是無法覆寫的。您只能覆寫該網址的「title」和「description」。
如需瞭解詳細資訊以及您可以透過圖形 API 發佈哪些欄位，請到以下網址查看 /feed 文件：https://developers.facebook.com/docs/graph-api/reference/v2.3/page/feed#publish
系統的設計就是如此。這與 Facebook 應用程式（行動版或網頁版）所產生內容的顯示方式一致，不會歸因至 Facebook 本身。
關於透過 API 擷取與顯示串流和貼文資料的方式，我們已做出更新。
如果您在從 API 擷取貼文時遇到問題，而且認為其運作方式和文件說明不符，請確認以下事項：
- 您使用的存取權杖是否有適當的權限可存取您感興趣的貼文。
- 請確定用來擷取貼文的所有 API 呼叫是否皆使用先前呼叫中傳回的「id」，而且您並未依據粉絲專頁、用戶或其他編號來手動製作編號。
這個情況有其目的。對於已刪除或因隱私／權限檢查而未顯示的物件，我們的系統就會傳回以上的錯誤訊息。
這是預期的行為，而且留言不支援這種分頁形式。
/{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}。
這個情況有其目的。此錯誤代表您嘗試延展效期的存取權杖，並無法存取嘗試延展該權杖效期的應用程式編號。
之所以會出現此錯誤，最可能的原因是您的應用程式套用了人口統計資料限制，而且我們偵測到您嘗試延展效期的權杖所屬用戶不符合這些限制（或不再符合限制，因為他們的所在地點已變更，或是我們現在會偵測更精確的地點）。
其次的可能原因是我們無法確認用戶是否符合要求（例如我們無法得知他們的所在地點），而且您的應用程式限制不允許這些用戶存取應用程式。
User 物件的 email 欄位相關文件清楚說明了這裡的預期行為：「如果未提供有效的電子郵件地址，就不會傳回此欄位」。
在一些情形下，您可能會認為用戶應該傳回電子郵件地址，但是並沒有。為了隱私和安全起見，我們無法詳細說明不會傳回任何特定用戶電子郵件地址的確切原因。
部分可能的原因為：
- 帳號中沒有電子郵件地址
- 帳號中沒有已確認的電子郵件地址
- 帳號中沒有已驗證的電子郵件地址
- 用戶輸入的安全檢查項目要求用戶再次確認電子郵件地址，但是尚未確認
- 無法聯繫用戶的電子郵件地址
這些貼文無法透過 API 擷取，因為在此類貼文中，用戶的內容是在粉絲專頁上轉貼，而且該用戶並未授權應用程式查看其內容。
如果用戶針對貼文的內容類型關閉了基本權限，就無法透過 API 取得用戶在粉絲專頁動態時報上分享的貼文。
若要查看遺失的粉絲相片貼文，您可以使用粉絲專頁存取權杖來擷取粉絲專頁的相簿──相片應該會在動態時報相簿中。
在有些情況下，特定應用程式（或任何應用程式）會因為 Facebook 用戶的隱私設定而無法取得與該用戶相關的任何資料，這種情況包括在您應用程式應該能夠查看貼文的範圍內，存取該用戶所發佈的貼文時（例如粉絲專頁管理）
例如，當用戶已封鎖應用程式，或是已停用所有平台應用程式，使其無法透過 API 存取其資訊。
推出圖形 API 第 2.1 版後，我們就移除了這項功能。如果是在 2014 年 8 月 7 日前建立的應用程式，signed_request 中就不會再有此欄位。
針對在此日期之前建立的應用程式，liked 屬性將一律傳回 true，無論該用戶是否已對粉絲專頁按讚。
若要取得其他結果頁面，請直接使用回應中傳回的 paging.next 和 paging.previous 連結。使用所提供的連結，可確保如果將來分頁連結的格式有所變更，您的應用程式將不會受到影響。
就像 API 上的多數項目一樣，這些並非完全 1:1 對應於主要 Facebook 網站上的功能。粉絲專頁洞察報告 UI 與透過 API 所稱的自主觸及人數有很大的不同，計算方式也不同。
例如，粉絲專頁洞察報告 UI 中的「organic」值對應的是透過圖形 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。
有些公開的粉絲專頁貼文是從用戶內容轉貼的。如果建立貼文的用戶尚未將所需權限授予應用程式，應用程式就無法透過圖形 API 存取用戶的貼文，因此也無法回應這些貼文。
以內嵌方式建立成廣告創意一部分的貼文，無法單獨加強推廣。因此，這些貼文也不會顯示在粉絲專頁的 /promotable_posts 端點呼叫中。
如果您使用仍然在開發模式的應用程式來排程貼文，就會發生這種情形。請使用已正式推出的應用程式，就不會發生這個問題了。
很抱歉，我們目前不支援透過 API 建立、更新或刪除封面相片。
若要瞭解有關封面相片 API 的詳情，請瀏覽 https://developers.facebook.com/docs/graph-api/reference/cover-photo/#Creating
否，無法透過 API 編輯寬度。
這是目前的行為。粉絲專頁管理員無法透過圖形 API 以自己的身分發佈貼文到粉絲專頁。此功能只能在 http://www.facebook.com/ 和我們的行動應用程式中使用。
不可以，沒有任何方式能夠取得對粉絲專頁按讚的完整用戶名單。系統的設計就是如此。
代表粉絲專頁執行動作時，請務必使用粉絲專頁存取權杖。這則錯誤訊息代表您使用的是用戶存取權杖，而不是粉絲專頁存取權杖。
您可以到以下網址瞭解各種類型的存取權杖： https://developers.facebook.com/docs/facebook-login/access-tokens
沒有辦法，您只能透過原生 Facebook 產品將貼文置頂與閱讀置頂貼文。
如果已經在某個時間點針對外部網址開啟留言同步功能，對於同步留言的貼文，其心情會針對網址本身記錄，並且將會在呼叫 {URL-id}/reactions> 時傳回。
目前不支援針對 /app_insights/app_event 端點提取超過 1000 個資料解析值的資料。如果您想要將資料按特定類別細分，建議利用 Facebook 分析工具 UI 切入至特定資料點，例如特定國家／地區。
您可能在資料傳播到我們的伺服器前，就已經呼叫該端點。
您應該等候 1-2 秒，讓資訊傳播到我們所有的伺服器，再發出 API 呼叫。
「page_fans_country」指標通常是「page_fans」計數的子集。這個指標涵蓋粉絲專頁按國家／地區細分的粉絲人數，但前提是我們要能準確判別用戶的國家／地區。
這個指標也僅包含粉絲專頁粉絲的熱門國家／地區（按粉絲人數），並未包含粉絲所在的所有國家／地區；對於粉絲散布在許多國家／地區的粉絲專頁，這個指標不會包含粉絲人數較少的國家／地區。
此 API 不支援使用位移型分頁。
您應該改為使用在每個圖形 API 回應結尾傳回的「分頁處理」連結，或是使用「游標」型分頁（建議使用）。
您可以到以下網址瞭解更多有關如何透過圖形 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
您可以在不同的粉絲專頁重複使用摘要網址，但請注意，系統只會擷取其標準 URL 和粉絲專頁領取的網域相符的文章。
我們建議的方式是各個粉絲專頁使用個別的 RSS 摘要，而且摘要中只包含該粉絲專頁應該擷取的文章。
當文章處於草稿模式時，只有對粉絲專頁管理員才會顯示為即時文章。當文章一旦發佈並上線後，便可供任何的 Facebook 用戶分享，而且對所有人都會顯示為即時文章。
如果您在文章中使用 dir="rtl" 屬性來顯示由右至左書寫的語言，有可能用於瀏覽文章的應用程式並未支援即時文章中由右至左書寫的語言。
請檢查您是否使用應用程式的最新版本。各應用程式支援由右至左書寫語言的最低版本為：
- iOS 版 Facebook：52.0
- Android 版 Facebook：69.0
- iOS 版專頁小助手：44.0
請檢查文章的 <body> 標籤是否設定 dir="rtl" 屬性。如果您的文章並未使用由右至左書寫的語言，則不應在文章中設定這個屬性。
如果在即時文章發佈之前就分享文章的網址，用戶會被重新導向至文章的行動網頁版。即時文章一旦發佈之後，所有的連結分享，包括在文章發佈之前張貼的分享，在行動裝置上檢視時，都會自動顯示即時文章。
我們尚未在 Android 版專頁小助手中提供開發摘要的支援。目前若要在 Android 上查看文章，因應措施為可以嘗試將文章以草稿的方式加入生產摘要。
若要編輯即時文章，您可以使用粉絲專頁介面。若要以這種方式進行，您可以在瀏覽器中前往您的粉絲專頁，然後前往「發佈工具 > 即時文章」。您會在該處看到您的文章，並且就地進行編輯。您可以在此詳讀更多資訊：https://developers.facebook.com/docs/instant-articles/publishing。
摘要下載的逾時時間目前為 30 秒。
不可以，分享連結必須是文章的標準 URL。如果變更這個網址（例如加入參數），就會被視為不同的網址。
系統擷取 RSS 摘要時發生的任何錯誤或警告都會顯示在「設定」頁面的「即時文章」頁籤中。您也可以在「發佈工具」頁面的「即時文章」頁籤中點擊文章，以檢視個別文章的警告和錯誤。
我們會嘗試在 10 秒內完整載入並剖析您的 RSS 摘要。這個錯誤表示嘗試並不成功。
解決這個問題的方法之一，是在您的 RSS 摘要中包含較少的項目，例如：僅包含過去 10 分鐘內新增／變更的文章。因為系統每 3 分鐘就會擷取摘要一次，所以包含未變更的文章是不必要的。
很抱歉，我們沒有網路爬蟲所用的靜態 IP 位址清單。不過，您可以改用我們網路爬蟲的用戶代理程式：facebookexternalhit/1.1
請檢查重複的文章是否使用不同的標準 URL。我們使用文章的標準 URL 做為文章的唯一識別碼，所以使用不同標準 URL 的文章會被視為個別文章處理。
一個常見的問題是，您的內容管理系統可能會使用不同的 URL 來發佈文章更新，導致系統將更新擷取為新文章。
是，每個粉絲專頁都會唯一對應到一個網域名稱，而且是 1:1 對應。 我們要求屬於特定粉絲專頁的即時文章，其標準 URL 必須屬於該指定網域或相同網域的子網域。
不過，RSS 摘要網址本身的網域不需要和對應至粉絲專頁的網域相符。這項限制僅適用於摘要中文章的標準 URL。
如果您想要根據粉絲專頁的語言將文章發佈到不同的粉絲專頁，您應該為每種語言設定不同的 RSS 摘要，然後將各個粉絲專頁設定為使用合適的 RSS 摘要。
不會，一旦從 RSS 摘要中擷取文章後，該篇文章就會以即時文章的方式持續保存，直到從粉絲專頁的發佈工具中刪除為止。然後，您就可以從 RSS 摘要中安全移除該篇文章，以加快下一次的擷取程序。
目前無法透過 API 來發佈或刪除文章，但我們正在研究這項功能。
「讚」按鈕會使用您樣式設定中所設定的輔色色彩。請檢查您是否設定在頁首襯托下明顯可見的色彩。
此外，只有在瀏覽文章的用戶尚未對該粉絲專頁按讚時，才會顯示「讚」按鈕。因此，對於先前已經對該粉絲專頁按過讚的粉絲專頁管理員，系統並不會顯示「讚」按鈕。
請檢查並未在同一列中使用多個 <br> 標籤。若要將文章正文分割成多個段落，建議您使用段落（<p>）標籤，而不是換行符號。
請確保在包裝追蹤像素的 <figure> 標籤中加入「op-tracker」類別。若無這個標籤，追蹤像素會被視為內嵌圖像處理。
如果您在段落（<p> 標籤）內包裝非文字內容，如圖像或互動內嵌功能，通常就會顯示這項警告。段落只應該包含正文，其他任何內容都應該加入 <figure> 標籤內或其他合適的容器元素中。
不可以，說明（<figcaption>）元素僅支援 <h1>、<h2> 和 <cite> 標籤。不支援段落（<p>）標籤。
文章中的廣告是使用標準的 HTML5 <figure> 元素來定義，該元素用於包裝內含廣告標記的 <iframe> 元素。您可以將 op-ad 類別套用至 <figure> 元素，以在文章中指定廣告。指定廣告有兩種方式：透過在 iframe 中使用「src」屬性，直接指定廣告的網址；或透過在 iframe 中內嵌未逸出的 HTML 和指令碼。
您可以在這裡找到有關廣告的更多資訊：https://developers.facebook.com/docs/instant-articles/reference/ad。
標準圖像元素不支援使用 SVG 圖像。您可以改用互動內嵌功能（「op-interactive」），在 iframe 內加入 <img> 元素，並將「src」屬性設為 SVG 圖像的網址。
您可以使用這裡記載的地圖元素：https://developers.facebook.com/docs/instant-articles/reference/map。這是在即時文章中加入地圖的建議方式。
如果您以互動內嵌功能的方式在文章中加入 Google 地圖內嵌，由於內嵌功能運作方式上的已知問題，可能會造成地圖無法顯示。若要避免發生這個問題，您需要將載入地圖內容（「https://www.google.com/maps/embed?...」）的 iframe 包含在另一個 iframe 內。
您可以使用含 op-interactive 的 figure 來內嵌互動式模組。您可以在這裡取得詳細資訊和程式碼範例：https://developers.facebook.com/docs/instant-articles/reference/interactive。
若要定義高度，請將「height」屬性加入包裝所內嵌內容的 <iframe> 元素中。該屬性值應該是整數值，指出以像素表示的高度。高度最大可設為 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" 屬性會在圖像上顯示按讚和留言功能。
如需詳細資訊，您可以參閱意見回饋屬性相關文件。
指定互動內嵌功能等項目的寬度時，請使用整數值來指定以像素表示的寬度。根據預設，項目會以全寬度顯示。
若要在顯示互動內嵌功能時不含任何邊界，您可以在包含該內容的 iframe 中加入「no-margin」類別。
如果我們已經批准您粉絲專頁的 RSS 摘要，即使變更摘要網址，也無需再次提交送審。
我們會將每個粉絲專頁對應到唯一的網域名稱。RSS 摘要本身的網址不需要和這個網域名稱相符。不過，摘要內個別文章的標準 URL 必須屬於相同網域或其子網域。如果您只是變更 RSS 摘要的網址，並不會造成任何問題。
如果您同時更新文章的標準 URL 來指向新網域，則需要透過合作夥伴經理要求這個網域更新，他們應該能夠引導您完成程序。
請確認您的 Facebook 應用程式已設定真正的 iPhone Store 編號、iPad Store 編號（如果是測試用途，並不需要使用您真正的編號。您可以使用 Apple App Store 提供的任一應用程式編號），而且應用程式中心列出的平台中也啟用了 iPad 版的 iOS。
系統的設計就是如此。「動態」對話方塊會發佈含有附件的內容，因此無法自訂其他附件。
這是刻意的變更。我們已縮短朋友名單，為的是讓遊戲邀請和適當的玩家更具關聯性。請注意，玩家還是可以使用「搜尋」欄位選擇任意數目的朋友。
好消息是，透過這個變更，我們看到點擊率有所增加，整體 CTR 也有相當大的提升。我們期望讓這個管道更臻完美，也希望能夠找到全新的方式來確保向理想用戶顯示適當遊戲。
變更 og:title、og:image 等內容，只會套用到之後分享的連結。
用戶或粉絲專頁分享連結後，若該則貼文有超過 50 次互動（留言、讚、分享等），就無法變更其標題。此舉旨在避免網站在您與其互動後，變更了連結的詳細資訊，讓您認為自己是與其他網站互動。其他所有屬性則可隨時修改。
如果已分享連結並更新圖像，除非您在原分享貼文重新整理圖像，否則貼文會繼續顯示舊圖像。
若要重新整理貼文的連結圖像：- 前往動態消息的該則貼文。
- 點擊貼文右上角的刪節號。
- 選擇重新整理分享的附件。
許多因素會影響圖像裁切方式。例如，我們會盡量讓能偵測到的臉孔出現在圖像中央。
若是大型圖像，圖像長寬比越接近 1.91:1 越好，這樣不需裁切也能在動態消息中顯示完整圖像。
專頁貼文的連結分享一向以大型的橫向圖像呈現，桌面版和行動版動態也是如此。請嘗試將圖像長寬比盡可能保持為 1.91:1，以便在動態顯示未經裁切的完整圖像。
圖像以非同步方式快取，因此用戶第一次分享您的內容時可能不會轉譯圖像。您可以執行下列其中一項來避免這種情況：
- 使用 [分享偵錯工具]（/tools/debug/）來觸發抓取，以預先快取圖像
- 使用 [
og:image:height及og:image:width標籤]（/docs/sharing/opengraph/object-properties#image）來明確指定圖像
小於 600 x 315 像素、大於 200 x 200 像素的圖像，都會以小正方形圖像顯示。
網址代表的是資源（粉絲專頁／圖像）的標準位置，因此所有網址皆必須為絕對網址，以便我們將按讚和分享次數妥善轉移至正確的網址及快取圖像。
這表示原始圖像已無法使用、檔案過大，或因暫時性的問題而無法擷取。確保我們的網路爬蟲可抓取圖像網址，檔案不超過 8 MB 且延遲顯示的時間在幾秒之內。
在變更網頁的 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.
請稍候片刻再嘗試 GET 廣告詳細資料，就可避免這個問題發生。
有時候，嘗試在特定行銷活動中使用特定廣告創意時，您可能會遇到驗證錯誤。 行銷活動的目標與您所使用的廣告創意不相容時，就可能會發生這種情形。 例如，如果您的廣告創意指向畫布遊戲，行銷活動目標卻是「MOBILE_APP_INSTALLS」時，就可能會發生這種情形。
若要解決您可能看到的驗證錯誤，您可以遵循行銷 API 驗證最佳作法。
請檢查未含有相關項目的上傳連線階段沒有出現任何失敗。
只有在 deletion_enabled 設為 true 時，才會將成功上傳連線階段的動態中已不存在的項目刪除。
如果您遇到這個錯誤，請檢查要指定的廣告帳號狀態。廣告帳號的狀態為未結清時，經常會傳回此錯誤。
這是預期的行為，因為粉絲專頁洞察報告的後端資料只會儲存 2 年。因此，呼叫預期會傳回零值。唯一不會是零的項目是貼文上的內嵌按讚數／留言數／分享次數，因為這些資料會由貼文本身保留。
請檢查目標設定規格的語法，尤其是要確認目標設定規格具備有效的 geo_locations 參數和值。
使用特定目標建立廣告時，會設定預設轉換規格。如果您對轉換規格做出變更，就會覆寫現有的規格。
請注意，特定目標不會有預設轉換規格，而必須明確指定。
這可能是因為您設定為目標的國家／地區的 work_positions 廣告受眾規模太小，無法影響觸及人數預估。我們將持續收集資料，希望能夠改善新增到 work_positions 排除的人數，進而影響觸及人數預估。
該用戶很可能是透過企業管理平台與帳號建立關聯，因此不會顯示為明確的圖形 API 關聯。
請確認您已在適當的目標設定欄位中指定合作夥伴類別。從「/partnercategories」端點擷取的合作夥伴類別會包含名為「targeting_type」的欄位，用於指定您在指定目標設定類型時，需要使用的目標設定欄位。
例如，如果您的合作夥伴類別傳回的「targeting_type」為「behaviors」，則您必須在目標設定規格的「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 端點會使用游標型分頁，因此不會傳回 count、limit 和 offset 欄位。建議對所有端點都使用游標型分頁，才能獲得一致的結果。
如需更多有關如何使用游標分頁的資訊，請查閱以下網址：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 平台整合，使用平台測試用戶的因應措施如下：
- 在應用程式的角色頁面，點擊「新增」按鈕，建立新的測試用戶。
- 切換為此應用程式授權測試用戶？選項，然後授予「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]（說明文件） - 按照上述步驟操作後，您就會收到測試粉絲專頁的即時更新，並且能夠從測試粉絲專頁傳送訊息給測試用戶。
除了上述步驟之外，如果存取權杖太快到期而無法測試，您可將存取權杖替換為長期權杖。請按照此處的說明文件進行：
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 平台驗證取得的用戶編號才可用於 Messenger 平台。
- 您使用的編號有不正確的粉絲專頁存取權杖： 用於 Messenger 平台的用戶編號侷限於粉絲專頁的範圍，因此是粉絲專頁特定的用戶編號。如果您使用有效的用戶編號，但使用的粉絲專頁存取權杖與不同的粉絲專頁相關聯，則呼叫會失敗。請務必使用與相同粉絲專頁相關聯的用戶編號和粉絲專頁存取權杖。
- 您傳送到最近並未驗證的電話號碼： 使用傳送 API 搭配電話號碼時，只有在電話號碼最近經過驗證時，我們才會傳送訊息。即使顯示電話號碼已經過驗證，但如果最近並未驗證，傳送仍可能失敗。請重新驗證電話號碼，然後等候 24 小時後再試。
使用「傳送到 Messenger」外掛程式時，您可使用 data-ref 參數作為傳遞參數，以傳遞任何有關點擊內容的資訊。
用戶也可能透過在 Messenger 中搜尋來探索您的粉絲專頁。在這種情況下，您就沒有傳遞參數。您可使用帳號連結功能，將對話串與您網站上的用戶帳號建立關聯。
您可以前往「Messenger 設定」底下的應用程式主控板，然後使用名為「顯示最新錯誤」的按鈕查看 Webhooks 是否收到回覆 200 或失敗。
我們提供一個可顯示最新 Webhook 錯誤的工具。在 Webhooks 無法傳遞的情況下，Facebook 伺服器會取消訂閱您的網址。若要尋找該工具，請依序點擊「應用程式主控板」>「Messenger」>「設定」，在 Webhooks 卡中找到名為「顯示最新錯誤」的按鈕
請確定 Webhook 以狀態代碼 200 回應。這樣會告知我們已成功收到 Webhook。如果您未傳回狀態代碼 200，我們會重新嘗試呼叫，直到成功完成為止。此外，如果 Webhook 很長一段時間都未傳回狀態代碼 200，我們就會傳送開發人員重要通知。
另請注意，成功狀態代碼必須即時傳回。Webhook 呼叫會在 20 秒後逾時。請務必在設計程式碼架構時，以非同步的方式處理 Webhook，以便可立即傳回成功狀態代碼，然後分別處理 Wehbook。
對 Webhook 發出的呼叫會在標頭中包含名為 X-Hub-Signature 的欄位，您可使用這個欄位來驗證呼叫是否來自 Facebook。
除了提供粉絲專頁的 OG 標籤以外，分享的開放社交關係圖動態時，您無法控制貼文在動態消息或動態時報上的顯示方式。Facebook 會自動將貼文最佳化，以確保您的內容能夠獲得最多的互動。
是的，動作連結功能已經停用。我們已經從 Facebook 網站移除動作連結的支援，因此開放平台也會停用此功能。我們將來可能會再次推出此功能，但是目前並無此規劃。
如果您的網頁使用開放社交關係圖中繼標籤，而且含有 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 應用程式設定。如果您已啟用 pass_through 並使用 WhatsApp Business API 用戶端 v2.29.1 或以上版本，將不會收到任何讀取狀態回呼。
如果您想接收讀取狀態回呼，請停用 pass_through 應用程式設定。請注意，若停用 pass_through，您的資料庫儲存可能會快速增加。如需管理資料庫的詳細資訊，請參閱資料庫管理文件。
資料庫記憶體回收會定期清除 messages 和 messages_reciept_log 資料表，以協助管理資料庫。
記憶體回收器會保留特定訊息，以便成功進行傳送／處理。例如，保留傳入的訊息一段時間，以允許企業整合工具將訊息標記為已讀。
核心應用程式將以隨機的間隔（即每隔幾小時）執行記憶體回收。如此可避免因資料庫爭用而導致高可用性堆疊的潛在效能下降。
記憶體回收獨立於回呼佇列。例如，如果 Webhook 伺服器有 4 天無法使用，則將儲存回呼以在 Webhook 伺服器連接恢復時進行傳送。
只有當收件人已將您的企業電話號碼保存為聯絡人或您擁有官方商業帳號時，連結才會呈現為可點擊。
在 v2.29.x 之前，傳出的訊息佇列大小會隨時間增加是因故障之故。升級至 v2.29.3 即可解決此問題。
您將負責根據用戶的預期地點和語言來使用適當的 QR 條碼。
QR 條碼現在可以直接於 WhatsApp Business Management API 內產生和管理，用戶可以使用 WhatsApp、iOS 或 Android 相機對其進行掃描。
此外，透過 WhatsApp QR 條碼
- 可以完整自訂預先填入的訊息，並且可以隨時變更或刪除內容，
- 用戶將一律直接進入應用程式，沒有任何插頁廣告頁面，
- 針對已失效的條碼，應用程式內部體驗會向用戶傳送清楚的訊息。
如果用戶嘗試存取已刪除的 QR 條碼或短連結，將會看到錯誤訊息，指出 QR 條碼／短連結已失效。
如果用戶安裝了 WhatsApp 桌面用戶端，將會啟用與您企業的對話。若沒有安裝，系統將提示用戶安裝 WhatsApp 桌面用戶端。
新的短連結可讓您隨時編輯或刪除與連結相關聯的預先填入訊息。短連結還能將網址的語法簡化為隨機代碼，如此就不需要在網址中內嵌訊息，並可遮罩電話號碼。
建議使用 .svg 檔案格式，以在列印材質上獲得最佳品質。
您可以在 WhatsApp Business Management 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 的數量與預期的 params num2 數量不符」，您嘗試傳送的訊息範本，其參數數量與預期的參數數量不符。請檢查 API 叫用是否正確。
- 「your-template-name 是一個 Rich 型範本，需要使用範本訊息 API」，您嘗試將媒體訊息範本以一般訊息範本的方式傳送。請確認訊息類型為
template。如需詳細資訊，請參閱媒體訊息範本文件。 - 在企業管理平台中核准（或刪除）範本後，WhatsApp Business API 用戶端最多可能需要 20 分鐘才能收到更新的範本。如果您嘗試傳送含有剛經核准範本的訊息，並且收到該範本不存在的錯誤，可以在等待前述指定時間後重試傳送該訊息。
系統會將重複訊息傳送到 WhatsApp Webhook，因為系統的唯一保證是至少會收到一次（而不是只收到一次）。如果這會影響您處理訊息的方式，建議您根據訊息編號來刪除重複的 Webhook 訊息。
如果設定 AWS 部署時收到類似下列錯誤，請嘗試更改為 8 個或更少字元的堆疊名稱。
國家／地區名稱（兩個字母代碼）[AU]：省／市名稱（完整名稱）[Some-State]：位置名稱（例如城市）[]：組織名稱（例如公司）[Internet Widgits Pty Ltd]：組織單位名稱（例如部門）[]：一般名稱（例如伺服器 FQDN 或您的名稱）[]：字串太長，必須為少於 64 個位元組長的一般名稱（例如伺服器 FQDN 或您的名稱）[]：電子郵件地址 []：錯誤，設定檔中未指定物件的問題導致憑證要求建立internal-wa-inc-name-LB-123456789.ap-southeast-1.elb.amazonaws.com 的裝置密鑰
訊息範本中允許的參數數量沒有限制。
每個 WhatsApp 企業帳號的訊息範本數上限為 250 個。
若因故（例如用戶端離線）未能傳遞 Webhook 事件，或是 Webhook 要求傳回 200 之外的 HTTP 狀態碼，我們將重試傳遞 Webhook。我們會繼續重試傳遞，並將延遲增加至特定逾時（通常為 24 小時，但可能有所不同），或直到傳遞成功為止。
在某些情況中，您可能需要更多時間來處理顧客查詢，並且只能在 24 小時後回覆。我們建議建立訊息範本來執行下列步驟：
- 傳遞結果給用戶，或
- 提示用戶進行回覆以啟動顧客服務視窗。
在上述兩種情況中，請務必盡可能為訊息範本提供更多內容。例如：
- 「您好 {{1}}，關於您之前回報的問題，我們很遺憾地通知您 {{2}}。造成您的不便我們深表歉意。」
- 我們已就您的票證進行更新。如果您希望繼續支援，敬請回覆。」
WhatsApp 進行實驗以衡量和瞭解 WhatsApp Business API 通知對用戶體驗和整體產品的一般影響。如果您傳訊的用戶是這些實驗的其中之一，即使他們已選擇接收通知，也不會收到您的通知。
有，網路應用程式容器和核心應用程式容器的記錄檔輪替方式稍有不同：
- 網路應用程式：保留最後 30 個記錄檔。記錄檔只會在大小超過 20MB 時輪替。
- 核心應用程式：保留最後 30 個記錄檔。記錄檔只會在大小超過 15MB 時輪替。系統會壓縮輪替的檔案。
所有 WhatsApp Business API 用戶端組建自發行日起有效期為 6 個月。如果您看到此錯誤，請儘快升級到最新版本。
來自用戶的訊息酬載可以是文字或媒體檔案。
若是文字，將視為沒有任何已知危險。
若是媒體檔案：
- 通常，企業應具備一些防護軟體（即防毒、反惡意軟體等）來分析任何潛在威脅。
- WhatsApp 無法識別或檢查端對端加密傳輸的檔案內容（此亦適用於純文字內容）。
- 有一個選項可以防止在 WhatsApp Business API 用戶端中自動下載媒體檔案。如果企業不想接收用戶的任何檔案，可以將
auto_download欄位設為空陣列。
不行，無法使用 WhatsApp Business API 偵測相同手機號碼的裝置。
當電話無法讀取範本訊息時，會發生結構無法使用的錯誤。
範本儲存在伺服器上。使用 訊息 節點傳送範本訊息時，系統只會將命名空間、語言、元素名稱和本地化參數傳送到電話，而不是傳送整個訊息。當這些值傳遞到電話時，系統會嘗試轉譯訊息。
如果轉譯過程中發生任何錯誤，系統會傳送 「結構無法使用」 錯誤到包含收件人和訊息編號的回呼網址。這些錯誤可能是肇因於命名空間錯誤、本地化參數不符、元素名稱錯誤等等。
請前往 Facebook 企業管理平台，在 WhatsApp 管理工具中查看正確的參數數量。請仔細檢查命名空間是否正確以及元素名稱是否存在。
沒有為所有使用中的範本建立翻譯是一項常見的錯誤來源。例如，如果您通常會傳送 2 個範本，並為其中一個範本新增語言翻譯，請務必同時為另一個範本新增該語言翻譯。如果您計劃支援多種語言，您應該為所有範本提供所有支援語言的翻譯。
好消息是， 「結構無法使用」 錯誤絕大部分是肇因於 訊息 API 呼叫中的錯誤，這可以藉由變更傳送承載來修復。
您可以在 Facebook 企業管理平台的 WhatsApp 帳號中註冊和刪除新舊電話號碼。
- 在您的 WhatsApp 帳號中，前往設定。
- 點擊 WhatsApp 管理工具。
- 選擇電話號碼頁籤。您可以在此管理該帳號的所有電話號碼。
圖像可加入說明文字。Android 和 iPhone 圖像的說明文字皆以完整長度顯示。
若是文件，這類文字會取代檔案名稱。這並不會在用戶裝置顯示為說明文字，而是顯示為檔案名稱。iPhone 會顯示完整文字，Androids 則會截斷檔案名稱；這是目前 WhatsApp 在兩種裝置上的技術限制。
如果因使用「簡訊」嘗試次數過多而註冊失敗，且收到「存取遭拒」的訊息，請嘗試使用「語音」註冊。
目前是 7 天。如果超過 7 天未更新快取，無論套件是否已有該元素，系統都將從伺服器中提取最新的語言套件。
裝置會先從快取載入內容，此時若存在元素，將使用該訊息範本來解壓縮訊息。因此，最安全的方式不是修改訊息範本，而是加入具有不同元素名稱的新範本。如此一來，可確保在找不到該元素時重新下載語言套件。訊息範本的儲存成本可忽略，因此無需刪除訊息範本。
如需詳細資訊，請參閱傳送訊息範本 - 語言。
為了確保企業和用戶獲得高品質的體驗，我們提供有限的公開預覽。我們持續擴大合作機會，如有意願請提交有關貴企業的詳細資訊以供參考，或是與您現有的 Facebook 代表聯繫。
透過 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 資料庫堆疊。新的 RDS 堆疊與原始堆疊的主機名稱會不同，且 Docker 容器將無法連接到資料庫。解決方案是將 SSH 放入由 CloudFormation 建立的 EC2 實例，並使用新的主機名稱更新 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 訊息字元和格式，包括表情符號、粗體、斜體等。若是表情符號，您必須使用表情符號字元（複製／貼上），而不是其對等的 unicode。
不可以！在任何指定時間，您只能使用單一電話號碼執行一個 WhatsApp Business API 用戶端實例。只要您註冊第二個實例，第一個實例將啟動並失敗。我們正在研究適當的解決方案來提供這項功能。若有任何最新消息，我們將隨時通知您。
由於端點之間沒有第三方存取內容，因此 WhatsApp 將與 Business API 用戶（該用戶管理其控制之伺服器上的 API 端點）的通訊視為端對端加密。
某些組織可能選擇將 WhatsApp Business API 端點委託給第三方企業解決方案供應商管理。在此情況中，通訊仍會使用相同的訊號協定加密。但是，由於 WhatsApp Business API 用戶選擇第三方來管理端點，因此 WhatsApp 不會將這些訊息視為端對端加密。未來在 2021 年中，此情況也適用於選擇使用 Facebook 代管之雲端型 API 版本的企業。
此外，若使用 HTTPS 呼叫 WhatsApp Business API 用戶端，該資料將採用 SSL 加密（從後端用戶端到 WhatsApp Business API 用戶端）。
請參閱我們的 WhatsApp Encryption Overview technical whitepaper（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、16 GB RAM 和 4 核心 CPU。不建議使用 HDD，因為 I/O 速度會成為負載的瓶頸。
如果要設定為多點連線生產伺服器，建議每個核心應用程式／Master 節點／網路應用程式容器至少配備 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