"문제가 발생했습니다."와 같은 오류 메시지가 표시되고 원인을 확인하는 데 어려움이 있는 경우 조치 가능한 정보를 표시하는 세부 오류 메시지를 활성화하도록 선택할 수 있습니다. SDK의 init()' 메서드에 대한 디버그 플래그에 관한 자세한 내용은 https://developers.facebook.com/docs/accountkit/webjs/reference에서 확인할 수 있습니다.
Android 소비자가 Facebook에 등록된 것과 일치하는 전화번호를 입력한 경우에는 Account Kit 즉시 인증에서 SMS를 통한 인증 코드를 요구하지 않습니다.
이는 사용자가 Android용 Facebook 앱을 사용하는 경우에만 필요할 수 있습니다. 일치하는 전화번호를 확인할 수 없는 경우 일반 플로를 통해 연결하고 SMS를 통해 인증 코드를 받습니다.
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 연결만 지원됩니다. 이 스크립트는 accountkit.com 또는 브라우저의 캐시에서 최신 SDK를 읽어들이는 SDK 로더를 가져옵니다.
자체 서버를 통해 SDK를 호스팅하려는 경우 24시간의 유예 기간이 있습니다. 이 유예 기간 후에 SDK에서 경고를 발행하기 시작하며 7일 후에는 작동을 중지합니다.
enableSendToFacebook 매개변수(iOS) 또는 setFacebookNotificationsEnabled 매개변수(Android)를 true로 설정합니다.
SMS로 전송할 수 없고 사용자가 사용 중인 전화번호가 Facebook 계정과 연결된 기본 전화번호인 경우 사용자가 개발자의 앱에 로그인하면 Facebook 알림을 통해 확인 메시지가 제공됩니다.
사용자가 모바일 공유 대화 상자 또는 모바일 피드 대화 상자를 열지만 취소하여 닫는 경우 onSuccess() 콜백 방법을 통해 앱에 알림을 보냅니다. onSuccess() 콜백을 대화 상자가 어떤 식으로든 성공적으로 닫혔다는 것을 알리는 메커니즘으로 생각할 수 있지만 무언가 실제로 게시되었는지 확인하기 위해 사용할 수 없습니다. 사용자가 앱에 'publish_actions' 권한 범위를 부여한 경우에는 onCancel() 콜백 방법이 취소 시 호출됩니다.
FacebookCallback 클래스의 상세 정보를 보려면 참조 문서를 참조하세요.
네이티브 좋아요 버튼(LikeView)은 웹 기반 좋아요 버튼과 동일하게 작동합니다. 대부분의 Facebook 기반 URL은 공개 범위로 인해 사용할 수 없습니다. 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.
앱 검수의 필요성은 앱 ID 레벨에 따라 달라집니다. 해당 권한 또는 기능을 사용하는 각 앱은 검수를 위해 제출해야 합니다.
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에 앱 검수가 필요할 경우 앱 검수를 위해 앱을 제출해야 합니다.
이미 비즈니스 관리자 계정이 있다면 기존 비즈니스 관리자에 앱을 연결하는 것이 좋습니다.
비즈니스에 속한 비즈니스 관리자 계정이 여러 개라면 각 비즈니스 관리자 계정을 생성한 목적을 확인하고 가장 적절한 비즈니스 관리자와 앱을 연결합니다. 비즈니스가 비즈니스 관리자를 통해 설정된 크레딧 라인이 있다면 크레딧 라인이 있는 비즈니스 관리자와 앱을 연결하는 것이 좋습니다.
개발자는 Facebook에서 사용하기를 원하는 추가 구성, 화이트리스트 설정 또는 테스트 사용자 프로필 정보가 있을 경우 특정 테스트 사용자를 제공할 수 있습니다. 테스트 사용자를 제공하지 않으면 Facebook에서 보유한 자체 테스트 사용자를 사용하게 됩니다. 이 필드는 선택 사항으로 표시되어야 하며 완료하지 않아도 차단되지 않아야 합니다.
앱별로 앱 검수를 받아야 합니다. 앱 대시보드를 살펴보고 검수가 필요한 권한의 구체적인 리스트를 확인하는 것이 좋습니다.
비즈니스 인증은 비즈니스 관리자별로 한 번만 필요합니다. 모든 앱을 동일한 비즈니스 관리자와 연결할 경우 비즈니스 인증은 한 번만 받으면 됩니다.
앱은 앱을 최종적으로 소유하고 앱에서 생성되는 데이터에 액세스할 권한이 있는 비즈니스 관리자와 연결되어야 합니다. 이 비즈니스가 비즈니스 인증 절차를 거쳐야 합니다.
언제든 앱 대시보드의 앱 검수 탭에서 비즈니스 인증 및 계약 상태와 비즈니스 인증 패널에서 실행해야 하는 단계를 확인할 수 있습니다. 절차를 진행하는 동안 어떤 조치가 필요한지 알림을 보내드릴 것입니다.
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 로그인 관련 확장된 권한 및 API 6개(페이지, Messenger, 비즈니스 관리자, Instagram, 그룹, 이벤트)를 호출하는 모든 기존 앱은 비즈니스 인증 및 계약 서명이 포함된 새로운 앱 검수 플로를 위해 제출되어야 합니다. 8월 1일은 제출 기한이며, 앱 검수 절차가 완료되어야 하는 날짜를 의미하지 않습니다. 2018년 8월 1일까지 제출하지 않으면 2018년 8월 2일부터는 해당 API에 액세스할 수 없습니다.
마케팅 API 및 잠재 고객용 광고 데이터 가져오기 API를 호출하는 모든 기존 앱은 2019년 2월 1일 전에 비즈니스 인증 및 계약 서명이 포함된 새로운 앱 검수 플로에 제출되어야 합니다.
비즈니스는 한 번만 인증하면 됩니다. 계약도 마찬가지로 비즈니스 수준에서 한 번만 서명하면 됩니다. 이후의 앱 제출에는 인증이 아닌 앱 검수가 필요합니다.
앱 검수는 앱 ID 수준을 기반으로 합니다. 해당 권한 또는 기능을 사용하는 각 앱을 검수를 위해 제출해야 합니다.
2018년 5월 1일에 Facebook은 Facebook 로그인(확장된 권한) 및 API 6개(페이지, Messenger, 비즈니스 관리자, Instagram, 그룹, 이벤트)에 필요한 새로운 앱 검수 절차를 발표한 바 있습니다. 이러한 API에 대한 액세스 권한을 유지하려면 2018년 8월 1일까지 해당 API/권한에 대해 앱 검수를 제출해야 합니다.
또한 2018년 7월 2일에는 마케팅 API 및 잠재 고객용 광고 데이터 가져오기 API에 대해서도 앱 검수가 필요하다고 발표했습니다. 액세스 권한을 유지하려면 2019년 2월 1일까지 이 API에 대한 앱 검수 제출이 필요합니다. 기한에 관한 자세한 내용은 여기를 참조하세요.
그래프 API v3.0에서는 비즈니스 관리자 API에 변동이 없습니다. Business_Management 권한에 액세스해야 하는 앱은 Facebook의 검수를 받아야 합니다.
Facebook의 마케팅 API를 사용하는 앱에 영향을 미치는 Facebook의 앱 검수 정책에는 변동이 없습니다. 실제 API의 변경 사항은 그래프 API 변경 사항을 참조하세요.
예, 앱 검수를 받지 않으면 앱은 사용자 이름, 이메일 주소, 프로필 사진에만 액세스할 수 있습니다. 그 외에 다른 모든 권한은 Facebook의 검수를 받아야 합니다.
Instagram API는 그래프 API v3.0의 영향을 받지 않습니다. 그러나 Instagram API를 사용하는 모든 앱은 Facebook의 검수를 받아야 합니다.
그래프 API v3.0에서 이벤트에 액세스하는 앱은 user_events 권한을 사용해야 합니다. 해당 권한을 사용하는 앱은 Facebook의 검수를 받아야 합니다.
user_managed_groups 권한은 그래프 API v3.0에서 사용이 중단됩니다. 그 대신 앱은 publish_groups 및 read_groups_user_data 권한과 함께 새 그룹 API를 사용할 수 있습니다. 새 API와 권한을 사용하는 앱은 Facebook의 검수를 받아야 합니다.
publish_actions 권한은 그래프 API v3.0에서 사용이 중단됩니다. 앱에서는 여전히 웹의 Facebook 공유 대화 상자나 iOS 및 Android의 공유 시트와 같은 미디에이션 환경을 통해 스토리를 게시할 수 있습니다. 앱은 publish_groups 권한을 사용하여 그룹에 게시할 수 있고 이 경우 앱 검수를 거쳐야 합니다.
예, v3.0에서 모든 Messenger 플랫폼 API가 Pages_messaging 권한에 포함되고 검수가 필요하게 됩니다.
예, 전체 공개 페이지의 콘텐츠에 액세스하는 앱은 페이지 전체 공개 콘텐츠 액세스 기능을 요청해야 하고 Facebook의 검수를 받아야 합니다.
검수 절차 중에 검수 팀이 개발자의 안내에 따라 앱에서 권한이 사용되는 방식을 재현합니다. 예를 들어 개발자의 지침을 따를 수 없거나 앱에 로그인할 수 없는 이유로 이 환경을 재현하지 못하는 경우 제출을 승인할 수 없습니다.
이 문제를 방지하려면 다음을 수행하세요.
- 권한을 사용하며 제대로 작동하는 앱 버전 제공
- 노트 추가 섹션의 내용이 명확한지 확인
- 요청한 로그인 권한이 개인화된 사용자 환경을 제공하며 Facebook의 원칙을 준수하는지 확인
특히 publish_actions 권한의 경우 앱의 게시 기능이 올바르게 구성되었는지 확인하세요. 검수 절차에서 Facebook에 다시 앱의 콘텐츠를 게시할 수 있어야 합니다.
앱 검수 절차에서는 지원되는 각 플랫폼에서 앱을 읽어들이고 Facebook으로 로그인하며 검수를 요청한 모든 Facebook 통합을 사용합니다. 이 과정에서 '일반 문제'라고 하는 상황이 종종 발생합니다. 일반 문제란 앱을 읽어들이거나, 앱에 로깅하거나, 앱의 일반 기능과 관련된 오류 또는 버그입니다. 따라서 Facebook이 개발자가 제출을 통해 요청한 권한을 테스트할 수 없습니다.
이러한 문제는 Facebook 기능을 검수할 수 없게 하므로 검수를 위해 제출한 앱이 Facebook 기능을 어떻게 사용하는지에 대해 자세히 설명해드릴 수 없습니다. 이 경우 '일반 문제'로 앱을 거부하며 각 플랫폼에서 이에 대한 피드백을 제공합니다.
'일반 문제' 거부를 받았다면 모든 피드백을 신중하게 검토하세요. 검수에서 발생한 문제를 설명하는 개별 피드백이 플랫폼마다 제공됩니다.
검수 답변에는 앱이 승인되지 않은 이유와 개발자가 수행해야 하는 다음 단계가 명확하게 설명되어 있습니다. 최대한 신속하게 절차를 처리해드릴 수 있도록 이 피드백을 꼼꼼히 확인하세요. 필요한 사항을 변경하고 나면 검수를 위해 다시 제출할 수 있습니다.
앱에서 승인할 수 없는 방식으로 권한을 사용하는 경우 피드백에서 해당 내용을 확인할 수 있으며 검수를 위해 다시 제출하지 않아야 합니다.
앱 센터에 대해 승인을 받으려면 앱이 적합성 요구 사항을 만족해야 합니다. Facebook 앱 센터에 앱을 표시하려면 Facebook 로그인을 사용하거나 Facebook 캔버스 앱이 있어야 합니다.
앱 센터에 나열될 수 있는 앱은 다음과 같습니다.
- Facebook 캔버스 앱
- iOS용 Facebook 로그인 또는 Android용 Facebook 로그인을 사용하여 iOS 또는 Android용으로 빌드된 모바일 앱
- Facebook 로그인을 사용하는 웹 또는 모바일 앱
텍스트 자산 및 홍보성 이미지도 Facebook 가이드라인을 충족해야 합니다.
소셜 플러그인을 사용하거나 페이지 좋아요를 설정하는 데 혜택을 제공하는 것은 플랫폼 정책 4.5에 위배됩니다. 여기에는 사용자가 페이지 좋아요를 클릭했는지에 따라 보답, 조건 앱 또는 앱 콘텐츠를 제공하는 행위가 포함됩니다. user_likes는 이 용도로 승인되지 않습니다.
더욱 가치 있는 연결을 제공하고 비즈니스가 중요한 사용자에게 도달할 수 있도록 Facebook은 사용자가 인위적인 혜택 때문이 아니라 순수하게 비즈니스에 연결하여 소통하기 위해 페이지 좋아요를 설정하기를 원합니다. 이 정책은 사용자와 광고주 모두에게 더 높은 품질의 서비스를 제공하기 위함입니다.
검수 팀에서 검수를 완료하기 위해 앱의 추가 로그인 정보가 필요할 수 있습니다.
앱에서 Facebook 로그인 전이나 후에 보조 로그인이 필요한 경우 해당 로그인에 맞는 사용자 이름과 비밀번호를 제공하세요. 여기에는 테스트나 데모 서버, 앱의 보조 로그인 또는 이메일 등록 플로에 사용할 로그인 정보가 포함될 수 있습니다.
준비 또는 개발 서버에서 호스팅되는 앱은 서버에 액세스하기 위해 추가 로그인이 필요할 수 있습니다. 이러한 로그인에 필요한 로그인 정보도 모두 제공해주세요.
누락된 로그인 정보가 무엇인지 확실하지 않은 경우 다음번에 제출할 때 Facebook 로그인 옵션 및 관련 Facebook 통합을 모두 나타내는 동영상을 제공할 수 있습니다.
검수 팀이 앱 제출을 승인하기 위해서는 개발자의 앱에 로그인하여 모든 Facebook 통합을 확인해야 합니다.
검수자가 앱을 읽어들이거나 사용할 수 없는 경우 다음을 확인하세요.
- 앱 URL이 공개적으로 액세스 가능하며 로컬 호스트로 구성되지 않았는지 여부
- 개발 또는 준비 사이트에 액세스하는 데 필요한 사용자 이름과 비밀번호를 제공했는지 여부
- 사이트의 보안 인증서가 최신 상태이며 새 사용자에 대해 오류를 발생시키지 않는지 여부
- 새로 만든 테스트 사용자로 앱에 로그인하여 사용할 수 있는지 여부
- 검수를 위해 제출한 항목이 빌드되어 앱에서 작동 중인지 여부
동일한 이유로 다시 거부되는 경우 검수 안내 또는 노트 추가 섹션을 업데이트하여 검수자에게 명확한 설명 및 추가 정보를 요청하세요.
스크린캐스트는 앱을 통해 검수팀을 안내하고 앱에서 요청된 권한을 어떻게 사용하는지 보여줄 수 있는 훌륭한 방법입니다. 다음은 스크린캐스트를 만들 때 유용한 모범 사례와 타사 리소스입니다.
동영상에는 앱이 요청하는 각 권한을 어떻게 사용하는지 나타나 있어야 합니다. publish_actions를 요청하는 경우 앱이 콘텐츠를 만들고 Facebook에 공유하는 방식에 대해서도 설명되어야 합니다.
Facebook 검수팀이 개발자가 제공하는 내용을 사용하여 앱의 Facebook 통합을 테스트합니다.
검수자가 앱을 거부한 것이 잘못되었다고 생각하는 경우 더욱 자세한 정보를 제공하도록 검수 지침을 업데이트하여 다시 제출해야 합니다.
검수 절차는 노트를 업데이트하여 개발자가 받은 피드백을 설명할 수 있으므로 검수자와 소통하는 데 가장 효율적인 방법입니다.
아니요, 권한이 승인되고 나면 모든 플랫폼 및 버전에서 사용할 수 있습니다.
새 플랫폼에서 앱을 확장하고 개발하는 경우 검수를 위해 제출하지 않아도 됩니다. 검수는 앱에 새 기능을 추가하는 등 앱에 새 권한을 요청할 때만 다시 제출하면 됩니다. 앱 상세 정보나 오픈 그래프 액션을 변경하고 제출해도 승인된 권한에는 영향을 미치지 않습니다.
앱이 게임이며 Facebook 캔버스가 있는 경우
다음 중 하나를 사용하여 게임에 새로운 게이머를 초대할 수 있습니다.
- 요청 대화 상자 요청을 사용할 때 'filters=app_non_users'를 설정하여 앱을 사용하지 않는 사람만 표시하도록 대화 상자를 필터링할 수 있습니다. 앱에 캔버스가 있는 경우 iOS 및 Android에서 요청 대화 상자를 사용할 수도 있습니다.
- 초대 가능한 친구 API. 게임 앱에서 친구 선택 도구를 자체적으로 빌드하려는 경우 초대 가능한 친구 API를 사용할 수 있습니다. 이 경우 앱을 사용하지 않는 친구에 대해 순위가 매겨진 리스트가 반환됩니다. 초대할 친구 수를 선택하고 나면 초대 가능한 친구 API에서 반환한 토큰을 요청 대화 상자 필드에 전달할 수 있습니다. 그러면 사용자가 선택한 수의 친구에게 초대를 보낼 수 있습니다.
앱에 Facebook 캔버스가 없는 경우
iOS의 메시지 대화 상자 및 Android의 메시지 대화 상자 또는 웹의 보내기 대화 상자를 사용할 수 있습니다. 이러한 제품을 사용하면 앱 링크를 포함한 메시지를 친구에게 직접 보낼 수 있습니다.
이 유형의 메시지는 소수의 사용자와 직접적인 방법으로 소통하는 데 유용한 채널입니다. 메시지 대화 상자와 보내기 대화 상자 모두에 자동 완성 검색 기능이 있습니다. 이 기능을 사용하면 여러 명의 친구를 초대할 때 친구를 쉽게 선택할 수 있습니다.
검수 팀에서는 개발자가 앱의 설정 섹션에 나열한 모든 플랫폼에서 앱이 각 권한을 어떻게 사용하는지 테스트합니다. 검수자는 Facebook 로그인 통합이 올바르게 작동하며, 요청된 각 권한이 Facebook의 원칙과 유틸리티 가이드라인을 준수하는 동시에 향상된 사용자 환경을 제공하는지 확인합니다.
자세한 내용은 Facebook 원칙 및 유틸리티 가이드라인을 참조하세요.
검수자가 user_likes에 대한 요청을 승인하려면 먼저 앱이 사용자로부터 받는 좋아요 정보를 기반으로 사용자에게 고유한 환경을 제공하는지 확인해야 합니다. 이를 위해 검수 팀에서는 서로 다른 좋아요와 관심사 집합이 있는 다양한 테스트 사용자를 통해 앱을 테스트합니다.
user_likes에 대한 요청을 제출할 경우 다음을 포함하여 자세한 안내를 작성해야 합니다.
- user_likes를 요청하는 이유와 이 권한이 앱에서 사용자의 환경을 어떻게 개선하는지 명확하게 설명.
- user_likes 사용을 확인하기 위해 검수자가 좋아요를 설정할 샘플 페이지 리스트. 앱을 테스트하기 전에 검수자가 좋아요를 설정해야 하는 페이지에 직접 연결된 링크를 제공해주세요.
user_likes를 알고리즘의 일부로 사용하는 경우 검수자가 이 알고리즘의 결과와 이 알고리즘이 사용자에게 표시되는 콘텐츠에 어떤 영향을 미치는지 확인할 수 있어야 합니다.
아니요, 모바일 앱 설치 광고를 실행하는 경우 검수를 위해 제출하지 않아도 됩니다. iTunes App Store 또는 Google Play 스토어에서 실행 중인 앱만 있으면 됩니다. 모바일 앱 설치 광고를 만들기 위한 Facebook 가이드를 참조하세요.
앱이 잘 작동하며 Facebook 정책을 따르는지 확인할 수 있도록 앱의 각 권한 또는 기능을 테스트하는 방법을 정확하게 설명해야 합니다. 앱이 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 파트너 관리자가 없는 비즈니스에서는 이 요청을 실행할 수 없습니다.
여러분의 비즈니스가 관리하는 모든 앱을 대표하여 인증해야 합니다.
여러 앱을 관리하는 개발자는 여러 앱에 대한 데이터 사용 확인을 한번에 완료할 수 있습니다. 앱 대시보드의 '내 앱' 페이지로 이동하여 이 플로에 액세스할 수 있습니다. 여기서 여러분이 관리자인 모든 앱이 표시되며, 하위 세트(예: 데이터 사용 확인이 필요한 앱만)로 필터링할 수 있으며 데이터 사용 확인을 완료할 수 있습니다.
여러분이 관리하는 각각의 앱마다 검사를 완료해야 합니다(각 앱에는 여러 권한이 있을 수 있음). 각 앱에 설정된 기한 이전에 절차를 완료하면 앱을 개별적으로 인증하고 원하는 대로 우선순위를 정할 수 있습니다.
여러분이 액세스할 수 있는 모든 권한을 인증하라는 메시지가 표시될 것입니다. 하지만 더 이상 특정 권한에 액세스할 필요가 없다는 사실을 인지한 경우, 해당 권한을 삭제하고 더 이상 인증할 필요가 없습니다.
라이브 모드와 개발자 모드는 앱 기능과 데이터 사용 확인에 영향을 주는 두 가지 앱 모드입니다. 개발자 모드는 일반적으로 API 상품/권한을 테스트 및 탐색하고 앱 검수를 완료하는 데 사용되며, 개발자 모드의 앱은 사용자 수준 데이터를 호출할 수 없습니다. 라이브 모드는 프로덕션 시나리오에 사용되며 앱 검수에서 승인된 데이터/권한에 대한 액세스를 제공하지 않습니다. 라이브 모드 앱만 데이터 사용 확인이 필요합니다.
일반적으로 앱 관리자가 동일한 경우에는 앱에 대한 절차 완료 기한을 통일하도록 조치했으므로, 각 앱의 완료 기한이 동일할 가능성이 높습니다. 하지만 일부 앱 관리자의 경우 예외적으로 앱마다 절차 완료 기한이 다를 수도 있습니다. 예를 들어, 여러 앱에 대한 데이터 사용 확인을 진행한 후에 어떤 앱을 새로 만드는 경우 연간 완료 기한이 다르게 적용될 수 있습니다.
앱 대시보드의 '내 앱' 페이지로 이동하면 데이터 사용 확인이 필요한 모든 앱을 확인할 수 있습니다. 여기서 여러분이 관리하는 모든 앱을 확인할 수 있으며, 데이터 사용 확인이 필요한 앱만 필터링할 수 있습니다.
앱 관리자는 누구든지 앱을 인증할 수 있습니다. 앱에 대한 관리자가 여러 명 있는 경우 그 중 한 명만 인증하면 됩니다.
절차 시작 시점(첫 번째 개발자 알림을 수신한 시점)부터 완료 기한까지 60일 안에 완료해야 합니다.
Facebook은 기한 날짜로부터 한 달에 걸쳐 API 호출을 제한하여 플랫폼에 대한 액세스를 취소하기 시작합니다. 이 기간 동안에 앱 대시보드로 이동하여 데이터 사용 확인을 완료하면 앱을 규정 준수 상태로 되돌리고 플랫폼에 대한 액세스를 완전히 되찾을 수 있습니다. 하지만 기한으로부터 한 달이 경과하면 플랫폼 액세스가 전면 취소됩니다.
해당 경우에도 앱 대시보드로 돌아가서 데이터 사용 확인을 완료하고 액세스 권한을 되찾을 수 있습니다. 하지만 비활성 앱의 '권한 획득'은 주기적으로 비활성화됩니다. 즉, 일정 기간 동안 권한을 사용하지 않으면 해당 권한이 영구적으로 삭제될 수 있으며, 다시 액세스하려면 앱 검수를 위해 제출해야 합니다. 이러한 상황을 방지하려면 완료 기한 이전에 데이터 사용 확인을 완료하는 것이 좋습니다.
데이터 사용 확인은 현재 사용 중 여부에 관계없이 앱이 액세스할 수 있는 모든 권한을 표시합니다. 이번 기회를 통해 통합을 검토하고, 앱의 기능을 더 잘 이해하고, 필요하지 않은 권한에 대한 액세스를 삭제하시기를 권장해드립니다.
데이터 사용 확인 플로에서 API 사용 정보를 바로 확인할 수 있는 경우도 있습니다. 그렇지 않은 경우, 앱 대시보드의 '권한 및 기능' 섹션에서 각 권한에 대한 사용 수준을 확인할 수 있습니다. 로그인한 후 페이지 왼쪽의 '앱 검수'를 클릭한 다음, 드롭다운에서 '권한 및 기능'을 선택합니다. 'API 호출'에 대한 열이 표시됩니다. 이 열은 해당 권한이 현재 사용 중인 것으로 로그에 나타나면 녹색으로 체크됩니다. 이러한 안내는 단지 추정일 뿐이며, 통합을 위해 권한이 필요한지 여부에 대해서는 개발 팀과 상의하시기 바랍니다.
Facebook은 자동 할당되는 이러한 '기본' 권한을 개발자가 인증하도록 요구하고 있습니다. 이러한 권한은 널리 사용되며 사용자 데이터에 대한 액세스를 제공하기 때문입니다. 하지만 인증은 데이터 미사용을 포함해 권한이 규정에 맞게 사용되고 있음을 나타내기 때문에, 이러한 데이터를 사용한 적이 없는 경우에도 이 절차를 완료하는 데 어려움이 없을 것입니다.
아니요. 앱 대시보드에서 사용 권한을 삭제한 후 데이터 사용 확인 페이지를 새로 고침하면 삭제한 사용 권한은 사라집니다.
앱이 액세스할 수 있는 모든 권한에 대해 데이터 사용 확인을 완료해야 합니다.
데이터 사용 확인은 점차적으로 적용할 예정이므로, 절차를 완료해야 하는 기한은 향후 몇 개월 이내이며 구체적인 완료일은 변동될 수 있습니다. 앱 대시보드의 연락처 정보가 최신 상태인지 확인하고 개발자 알림을 참고하여 기한에 대한 구체적인 정보를 확인하시기 바랍니다.
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에 같은 권한을 요청하기 전에 자신의 앱에서 기능을 완전히 테스트하도록 하기 위한 것입니다. 테스트 앱에서 테스트해도 기본 앱에서 안정된 같은 동작이 보장되지는 않습니다. 기본 앱에서 테스트 요청을 하여 외부 타겟에 대해 활성화하기 전에 예상대로 작동하는지 확인해야 합니다. 수동 요청에 대해 제공된 단계에 따르고 대시보드에 이 경고가 더 이상 표시되지 않는지 확인하세요.
'스트림 게시물 URL 보안' 마이그레이션을 사용하면 Facebook 앱에서 앱 소유의 도메인으로 다시 연결되지 않는 URL을 더 이상 게시하지 않습니다. 앱에서 다른 사이트의 링크를 게시하지 않는 경우 이 옵션을 사용하지 마세요.
이는 의도된 동작이며 https://developers.facebook.com/docs/apps/test-users#rules에 문서화되어 있습니다. 테스트 사용자는 공개 Facebook 페이지의 팬이 되거나 페이지의 담벼락에 글을 쓰는 등 페이지에 콘텐츠를 작성할 수 없습니다. 단, 앱과 연결된 페이지의 모든 앱 탭을 확인하고 상호작용하는 것은 가능합니다.
의도된 동작입니다. 보안상의 이유로 여러 개의 임의 도메인이 허용되지 않습니다.
의도된 동작입니다. 로그인 대화 상자는 고정된 너비를 사용하며 더 큰 화면에 맞게 크기가 조정되지 않습니다.
의도된 동작입니다. 사용자의 기기를 기반으로 적절한 'redirect_uri'를 설정하는 것은 개발자의 책임이므로, 사용자가 모바일 기기를 사용하는 경우 'redirect_uri'는 모바일 사이트 URL이어야 합니다.
이는 잠재적인 보안 취약점을 차단하기 위한 의도된 동작입니다. 일부 브라우저에서는 URL의 해시 프래그먼트를 리디렉션된 새 URL의 끝에 추가합니다(새 URL 자체에 해시 프래그먼트가 없는 경우).
예를 들어, example1.com이 example2.com으로의 리디렉션을 반환하면 example1.com#abc로 이동하는 브라우저가 example2.com#abc로 이동하며, example1.com의 해시 프래그먼트 콘텐츠를 example2.com의 스크립트에서 액세스할 수 있습니다.
하나의 인증 플로를 다른 인증 플로로 리디렉션할 수 있으므로 한 앱의 민감한 인증 데이터를 다른 앱에서 액세스할 수 있습니다. 새 해시 프래그먼트를 리디렉션 URL에 추가하여 이 브라우저 동작을 차단하면 문제가 완화됩니다. 결과 URL의 모양 또는 클라이언트 측 동작에 관심이 있는 경우 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.
URL을 공유하려면 연결된 이미지가 200x200픽셀 이상이어야 합니다. 그렇지 않은 경우 '제공된 og:image가 충분히 크지 않습니다. 200x200픽셀 이상인 이미지를 사용하세요.'와 비슷한 오류가 발생합니다.
URL용 이미지를 선택하기 위해 Facebook에서는 먼저 'og:image' 태그가 존재하고 200x200픽셀 이상인지 확인합니다. 'og:image' 태그가 존재하지 않으면 웹페이지에서 처음 보이는 이미지를 선택합니다.
오류가 발생하지만 사이트 이미지가 200x200픽셀보다 크다고 생각되면 'og:image' 태그를 올바로 설정했는지 확인해야 합니다. 가장 그럴듯한 원인은 사이트에서 잘못된 이미지를 가져오기 때문입니다.
공유자 플러그인의 동작을 플랫폼의 다른 플러그인 및 기능과 일치하도록 변경했습니다.
공유자가 더 이상 맞춤 매개변수를 받지 않으며 Facebook이 미리 보기에 표시되는 URL OG 메타 태그의 정보를 Facebook에 게시물로 표시하는 것과 같은 방법으로 추가합니다.
아니요. 공유 URL의 '캡션'은 덮어쓸 수 없습니다. '제목'과 '설명'만 덮어쓸 수 있습니다.
앱에서 다른 앱에서 만든 사진첩에 업로드할 수 없습니다.
때로는 어느 앱에도 연결되지 않는 사진첩이 있습니다(담벼락 사진 사진첩). can_upload 필드를 선택하시기 바랍니다. can_upload 필드에서 false를 반환하면 사용자가 자신의 프로필에서 사진첩 보기를 통해 이 사진첩에 직접 사진을 추가할 수 없다는 것을 의미합니다.
행동 유도 버튼은 동영상이 종료된 후 '다시 보기' 아이콘 아래 표시됩니다.
Facebook에서 GIF를 재생하려면 GIF의 크기가 8MB 미만이어야 합니다.
현재 API를 통해 비공개 게시물에 댓글을 남길 수 없습니다.
직접 생성된 동영상 게시물은 이미 홍보되었기 때문에 promotable_posts 엔드포인트에 표시되지 않습니다. 직접 생성된 동영상 게시물은 광고 만들기의 일부로 생성된 게시물이며, 따라서 따로 홍보할 수 없습니다.
그러므로 직접 생성된 게시물은 /promotable_posts 엔드포인트에 표시되지 않을 것으로 예상됩니다.
토큰과 연결된 사용자가 페이지의 설정 아래 페이지 역할에 분석자로 나열되는 페이지 액세스 토큰을 사용하는 경우 이러한 일이 발생할 수 있습니다.
그래프 API를 사용하여 데이터를 요청하는 경우 다양한 공개 범위 설정 규칙이 적용되어 특정 데이터가 웹사이트에는 표시되지만 반환되지 않을 수 있습니다. 이는 사용자의 공개 범위 설정, 앱 수준 권한 등 다양한 요인에 따라 달라질 수 있습니다. 즉, API에서 반환하는 데이터에 웹사이트에 표시되는 모든 데이터가 포함되지는 않습니다.
게시물이 11번 이상 공유되는 경우 shares 필드가 반환됩니다. 게시물이 10번 미만 공유된 경우 이 필드를 생략하거나 숫자를 반환할 수 있습니다.
이 엔드포인트에 대한 자세한 내용은 다음을 참조하세요. https://developers.facebook.com/docs/graph-api/reference/v2.4/post.
이 값은 이전 인프라에서 사용되던 이전 값이며 Facebook은 새 인프라로 이동할 때 이전 버전과의 호환성을 유지했습니다.
이 오류는 이전 게시물의 경우 발생하며 최신 게시물의 경우에는 발생하지 않습니다.
의도된 동작입니다. 게시물과 게시물의 사진들은 연결되지 않습니다. 게시물 내에 업로드된 첫 번째 이미지만 반환됩니다.
게시물이 Facebook 웹사이트 또는 모바일 앱에서 생성된 경우 'application' 필드가 반환되지 않습니다. 이 기능은 해당 유형의 게시물에 대한 속성을 표시하지 않는 사이트에 맞게 조정됩니다.
게시물의 'privacy' 필드에는 Facebook에서 해당 게시물의 공개 범위에 대한 정보가 포함되지만, 페이지 게시물이 특정 타겟만 볼 수 있도록 타게팅되거나 제한되는 경우 'privacy' 필드에 선택된 모든 타게팅 옵션이 표시되지 않습니다.
게시물이 타게팅되거나 제한되는 방식의 모든 상세 정보를 보려면 'targeting' 필드(제한의 경우) 및 'feed_targeting' 필드(뉴스피드 타게팅의 경우)를 선택합니다. 사용 가능한 필드에 대한 자세한 내용은 게시물 문서를 참조하세요.
게시물에 대해 반환되는 comment_count 값에는 숨겨지거나 삭제된 댓글이 포함될 수도 있습니다. 게시물에 표시되는 댓글의 수는 comment_count를 초과하지 않습니다.
공유 URL의 '캡션'은 덮어쓸 수 없습니다. 해당 URL의 '제목'과 '설명만 덮어쓸 수 있습니다.
그래프 API를 통해 게시할 수 있는 필드에 대한 자세한 내용은 다음의 /feed 문서를 참조하세요. https://developers.facebook.com/docs/graph-api/reference/v2.3/page/feed#publish
의도된 동작입니다. Facebook 앱(모바일 또는 웹)에서 생성된 콘텐츠가 (Facebook 자체에 대한 기여 없이) 표시되는 방식과 관련이 있습니다.
Facebook은 API를 통해 스트림 및 게시물 데이터를 가져오고 표시하는 방법을 업데이트했습니다.
API에서 게시물을 가져오는 데 문제가 있고 문서화된 대로 작동하지 않는다고 생각되면
- 사용 중인 액세스 토큰에 관심이 있는 게시물에 액세스할 수 있는 적절한 권한이 있는지 확인하세요.
- 게시물을 가져오기 위한 API 호출에서 이전 호출에서 반환된 'id'를 사용하고 페이지, 사용자 또는 다른 ID를 기반으로 수동으로 ID를 만들고 있지 않은지 확인하세요.
Instragram을 통해 업로드된 사진은 오픈 그래프 액션으로 게시되며 그래프 API에서 적절한 오픈 그래프 권한을 읽어야 합니다.
Instagram 사진의 경우 'instapp'이 Instagram에 대한 앱 네임스페이스이므로 필요한 권한은 'user_actions:instapp'입니다.
오픈 그래프 액션은 /feed 연결에 표시되지 않지만 사진이 오픈 그래프 액션으로 업로드되는 경우 적절한 권한을 사용하여 사용자의 사진첩 연결 또는 /photos 연결을 통해 액세스할 수 있습니다.
오픈 그래프 권한에 대한 자세한 내용은 여기를 참조하세요.
의도된 동작입니다. Facebook 시스템에서는 삭제되었거나 공개 범위/권한 확인을 위해 표시되지 않는 개체에 대해 위와 같은 오류 메시지를 반환합니다.
이 동작은 예상되는 동작이며 댓글에는 이러한 형태의 페이지 매김이 지원되지 않습니다.
/{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
앱 범위 사용자 ID를 사용하게 됨으로써 엔드포인트에서 데이터를 반환하는 방법이 달라졌습니다.
v1.0이 사용 중단되었으므로 여기서는 v2.x에 초점을 맞춥니다. /v2.0/{id}는 https://www.facebook.com/{id}를 반환하거나 https://www.facebook.com/app_scoped_user_id/{id}를 반환할 수 있습니다.
의도된 동작입니다. 이 오류는 확장하려는 액세스 토큰에서 해당 토큰을 확장하려고 하는 앱 ID에 액세스할 수 없기 때문입니다.
가장 그럴듯한 이유는 앱에 인구 통계학적 제한 사항이 적용되고 확장하려는 토큰의 사용자가 이러한 제한 사항을 충족하지 못하는(또는 더 이상 제한 사항을 충족하지 하는) 것으로 확인되는 경우 사용자가 위치를 옮겼거나 이제 더 정확한 위치를 확인할 수 있기 때문입니다.
두 번째로 가능성이 높은 이유는 사용자가 요구 사항을 충족하는지 확인할 수 없고 앱의 제한 사항에 따라 이러한 사용자가 앱에 액세스할 수 없기 때문입니다.
2014년 4월 30일 후에 만든 앱에서는 API 버전 2 이상을 사용합니다. 이 버전에서는 질문처럼 /me/friends 엔드포인트와 함께 앱 친구만 반환합니다. 더불어 이제 모든 사용자의 ID는 앱 범위 ID로, 특정 앱에 고유하고 영구적입니다.
v2.0의 일부로 포함된 새로운 기능과 변경 사항에 대해 자세히 알아보세요.
User 개체의 email 필드에 대한 문서에 여기에서 예상되는 동작("유효한 이메일 주소를 사용할 수 없는 경우 이 필드가 반환되지 않습니다")이 명확히 설명되어 있습니다.
사용자가 이메일 주소를 반환해야 한다고 생각하지만 그렇게 하지 않는 경우가 많습니다. 개인 정보 보호 및 보안상의 이유로 특정 사용자의 이메일 주소가 반환되지 않는 정확한 이유를 자세히 설명할 수는 없습니다.
몇 가지 가능한 이유는 다음과 같습니다.
- 계정에 이메일 주소가 없음
- 계정에 확인된 이메일 주소가 없음
- 계정에 인증된 이메일 주소가 없음
- 사용자가 이메일 주소를 재확인해야 하는 보안 체크포인트를 입력했지만 아직 이메일 주소를 재확인하지 않음
- 사용자의 이메일 주소에 도달할 수 없음
이러한 게시물에서는 사용자의 콘텐츠가 페이지에 다시 공유되고 해당 사용자가 앱에서 자신의 콘텐츠를 볼 수 있도록 승인하지 않았기 때문에 API를 통해 게시물을 가져올 수 없습니다.
사용자가 게시물의 콘텐츠 유형에 대한 기본 권한을 제거한 경우 API를 통해 페이지의 타임라인에 공유되는 사용자의 게시물을 이용할 수 없습니다.
누락된 팬의 사진 게시물을 보기 위해 페이지 액세스 토큰을 사용하여 페이지의 사진첩을 가져올 수도 있습니다, 사진은 타임라인 사진 사진첩에 있어야 합니다.
특정 앱 또는 모든 앱에서 Facebook 사용자의 공개 범위 설정으로 인해 해당 사용자에 대한 정보를 가져오지 못하는 경우가 있습니다. 앱에서 게시물을 볼 수 있을 것으로 예상되는 상황에서 해당 사용자가 만든 게시물에 액세스하는 경우가 포함됩니다(예: 페이지 관리).
예를 들어, 사용자가 앱을 차단했거나 모든 플랫폼에서 API를 통해 정보에 액세스할 수 없도록 비활성화한 경우가 이에 해당합니다.
그래프 API v2.1이 릴리스되면서 이 기능은 삭제되었습니다. 2014년 8월 7일 전에 만든 앱의 경우 이 필드가 signed_request에 더 이상 존재하지 않습니다.
이 날짜 전에 만든 앱의 경우 사용자가 페이지에 좋아요를 눌렀는지 관계없이 liked 속성이 항상 true를 반환합니다.
다른 결과 페이지를 얻으려면 응답에 반환되는 paging.next 및 paging.previous 링크를 사용하세요. 제공된 링크를 사용하면 앞으로 페이지 매김 링크의 형식이 변경되는 경우에도 앱이 중단되지 않습니다.
API의 대부분의 항목과 마찬가지로, 이들 기능과 기본 Facebook 사이트의 기능이 정확히 1:1로 매핑되는 것은 아닙니다. 페이지 인사이트 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/ 및 Facebook의 모바일 앱에서만 사용할 수 있습니다.
아니요. 페이지에 좋아요를 표시한 사람들의 전체 리스트를 얻을 수 있는 방법은 없습니다. 의도된 동작입니다.
페이지 대신 액션을 수행할 때 페이지 액세스 토큰을 사용하고 있는지 확인하세요. 이 오류 메시지는 페이지 액세스 토큰 대신 사용자 액세스 토큰을 사용하고 있다는 것을 나타냅니다.
여러 종류의 토큰에 대해 알아보려면 다음을 참조하세요. https://developers.facebook.com/docs/facebook-login/access-tokens
불가능합니다. 네이티브 Facebook 제품을 통해서만 게시물을 상단 고정하고 상단 고정 게시물을 읽을 수 있습니다.
외부 URL에 대해 댓글 미러링을 설정한 경우 댓글이 미러링되는 게시물에 대한 반응이 URL에 대해 기록되었다가 {URL-id}/reactions>를 호출하면 반환됩니다.
현재 데이터 가져오기는 /app_insights/app_event 엔드포인트의 분석 데이터 값이 1,000개를 초과하는 경우에는 지원되지 않습니다. 데이터를 특정 카테고리(예: 특정 국가) 기준으로 분석하려는 경우 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의 검색 자동 완성에서 실행되는 검색과 동일하게 작동하도록 디자인되지 않았습니다.
Facebook은 명시적으로 Facebook.com의 검색과 동일한 양의 결과 또는 특정 결과를 반환하는 검색 API를 지원하거나 목표로 하지 않습니다. 그리고 일반적으로 API를 통해 반환되는 게시물은 Facebook 자체의 동일한 게시물보다 더 제한적인 공개 범위 및 보안 검사의 적용을 받습니다.
Facebook 시스템에서는 앱의 API 호출에 속도 제한을 적용합니다. 다양한 한계에 대해 자세히 알아보고 앱이 제한되지 않도록 하려면 https://developers.facebook.com/docs/marketing-api/api-rate-limiting을 참조하세요.
피드 URL을 여러 페이지에서 재사용할 수는 있지만, 페이지에서 소유권을 요청한 도메인과 일치하는 표준 URL이 있는 아티클만 수집됩니다.
수집해야 하는 아티클만을 포함하는 각 페이지에 대해 별도의 RSS 피드를 사용하는 것이 좋습니다.
소셜 포함(embed)을 사용하여 동영상을 포함하여 지원되는 소셜 포함(embed)을 추가할 수 있습니다. 기타 타사 동영상 플레이어의 경우 인터랙티브 포함(embed)으로 아티클에 추가할 수 있습니다.
아티클이 임시 저장 모드일 경우에는 페이지 관리자에게 인스턴트 아티클로서만 표시됩니다. 아티클이 게시되어 라이브 상태가 되면 Facebook에서 누구하고나 공유할 수 있으며 모든 사람에게 인스턴트 아티클로서 표시됩니다.
아티클 자체에 오른쪽에서 왼쪽으로 읽는 언어가 표시되게 dir="rtl" 속성을 사용하면, 인스턴트 아티클에서 오른쪽에서 왼쪽으로 읽는 언어를 지원하지 않는 앱에서도 아티클을 볼 수 있습니다.
앱의 최신 버전을 사용 중인지 확인하세요. 오른쪽에서 왼쪽으로 읽는 언어를 지원하는 각 앱의 최소 버전은 다음과 같습니다.
- iOS용 Facebook: 52.0
- Android용 Facebook: 69.0
- iOS용 페이지 관리자: 44.0
아티클의 <body> 태그에 dir="rtl" 속성이 설정되었는지 확인하세요. 오른쪽에서 왼쪽으로 읽는 언어를 사용하지 않는 경우 아티클에서 이 속성을 설정해서는 안 됩니다.
인스턴트 아티클을 게시하기 전에 아티클의 URL을 공유하면 아티클의 모바일 웹 버전으로 리디렉션됩니다. 인스턴트 아티클이 게시되면, 모바일에서 볼 때 링크의 모든 공유(아티클 게시 전에 게시된 것 포함)가 자동으로 인스턴트 아티클을 표시합니다.
Android용 페이지 관리자에서는 개발 피드에 대한 지원이 아직 시작되지 않았습니다. 현재 Android에서 아티클을 보기 위한 해결 방법은 아티클을 임시 저장본으로 프로덕션 피드에 추가해보는 것입니다.
인스턴트 아티클을 수정하려면 페이지 인터페이스를 사용할 수 있습니다. 먼저 브라우저에서 페이지로 이동한 다음 게시 도구 > 인스턴트 아티클로 이동합니다. 아티클이 보이면 그곳에서 직접 수정할 수 있습니다. 자세한 내용은 여기에서 확인할 수 있습니다. https://developers.facebook.com/docs/instant-articles/publishing.
피드 다운로드의 시간 초과는 현재 30초입니다.
아니요. 공유 링크는 아티클의 표준 URL이어야 합니다. 예를 들어 매개변수를 추가하여 URL을 변경하면 다른 URL로 간주됩니다.
RSS 피드를 수집할 때 발견되는 오류나 경고는 설정 페이지의 인스턴트 아티클 탭에 표시됩니다. 또한 게시 도구 페이지의 인스턴트 아티클 탭에서 아티클을 클릭하여 개별 아티클에 대한 경고 및 오류를 볼 수도 있습니다.
Facebook에서는 RSS 피드를 10초 내에 완전히 읽어들여 구문 분석하려고 시도합니다. 그렇게 하지 못한 경우 오류가 표시됩니다.
이 문제를 해결하는 한 가지 방법은 RSS 피드에 항목을 더 적게 포함하는 것입니다. 예를 들면, 마지막 10분 이내에 새로 추가되거나 변경된 아티클만 포함할 수 있습니다. 피드를 3분마다 가져오기 때문에 변경되지 않은 아티클은 포함할 필요가 없습니다.
아쉽게도 크롤러에 대한 고정 IP 주소 목록은 없습니다. 그러나 대신 Facebook 크롤러의 사용자 에이전트를 사용할 수 있습니다(facebookexternalhit/1.1).
중복된 아티클이 서로 다른 표준 URL을 사용 중인지 확인하세요. Facebook에서는 아티클의 표준 URL을 고유 식별자로 사용하므로 서로 다른 URL을 가지고 있는 아티클은 별개의 아티클로 취급됩니다.
한 가지 일반적인 문제는 CMS가 다른 URL을 사용하여 아티클에 업데이트를 게시할 수 있다는 것입니다. 그러면 업데이트가 새 아티클로 수집됩니다.
예. 각 페이지는 도메인 이름에 고유하게 매핑되며 이것이 1:1 매핑입니다. 특정 페이지에 속한 인스턴트 아티클에는 지정된 도메인 또는 하위 도메인에 속한 표준 URL을 사용해야 합니다.
그러나 RSS 피드 URL 자체의 도메인은 페이지에 매핑된 것과 일치할 필요가 없습니다. 이 제한은 피드에 있는 아티클의 표준 URL에만 해당됩니다.
아티클을 언어별로 각기 다른 페이지에 게시하려면 각 언어에 대해 서로 다른 RSS를 설정하고 적절한 RSS 피드를 사용하도록 각 페이지를 구성해야 합니다.
아니요. RSS 피드에서 수집된 아티클은 페이지의 게시 도구에서 삭제될 때까지 인스턴트 아티클로서 저장된 상태가 유지됩니다. 다음 가져오기 속도를 높이려면 RSS 피드에서 안전하게 제거할 수 있습니다.
Facebook에서 작업 중이기는 하지만, 지금은 API를 통해 아티클을 게시하거나 삭제할 수 있는 방법이 없습니다.
좋아요 버튼은 스타일 설정에 구성된 강조 색상을 사용합니다. 헤더를 배경으로 눈에 띄는 색상을 구성했는지 확인하세요.
또한 좋아요 버튼은 아티클을 보는 사용자가 아직 좋아요를 누르지 않은 경우에만 표시됩니다. 따라서 이미 페이지에서 좋아요를 누른 페이지의 관리자에게는 표시되지 않습니다.
한 행에 <br> 태그를 여러 번 사용하고 있지 않은지 확인하세요. 아티클의 텍스트를 여러 단락으로 나누려면 줄바꿈 대신 단락(<p>) 태그를 사용하는 것이 좋습니다.
추적 픽셀을 감싸는 <figure> 태그에 "op-tracker" 클래스를 추가했는지 확인하세요. 이 태그가 없으면 이미지 포함(embed)으로 처리됩니다.
단락(<p> 태그) 내에 텍스트가 아닌 콘텐츠(예: 이미지 또는 인터랙티브 포함(embed))를 추가한 경우에 주로 이 경고가 표시됩니다. 단락에는 본문 텍스트만을 포함해야 하며, 다른 콘텐츠는 <figure> 태그나 기타 적절한 컨테이너 요소 내에 추가해야 합니다.
아니요. Caption(<figcaption>) 요소는 <h1>, <h2> 및 <cite> 태그만 지원합니다. 단락(<p>) 태그는 지원되지 않습니다.
현재 <video> 요소에서는 "muted" 속성이 지원되지 않습니다.
아티클의 광고는 표준 HTML5 <figure> 요소를 사용하여 정의됩니다. 이 요소가 광고에 대한 마크업을 포함하는 <iframe> 요소를 둘러싸게 됩니다. op-ad 클래스를 <figure> 요소에 적용하여 아티클에서 광고를 지정할 수 있습니다. 광고를 지정하는 두 가지 방법이 있습니다. 하나는 iframe에서 "src" 속성을 사용하여 광고의 URL을 직접 지정하는 것이고, 다른 하나는 iframe 내부에 이스케이프 처리되지 않은 HTML과 스크립트의 세트를 포함하는 것입니다.
자세한 내용은 여기에서 알아볼 수 있습니다. https://developers.facebook.com/docs/instant-articles/reference/ad.
표준 이미지 요소는 SVG 이미지 사용을 지원하지 않습니다. 대신 인터랙티브 포함(embed)("op-interactive")을 사용하고, "src" 속성을 SVG 이미지의 URL로 설정하여 iframe 내에 <img> 요소를 추가할 수 있습니다.
다음에 설명되어 있는 Map 요소를 사용할 수 있습니다. https://developers.facebook.com/docs/instant-articles/reference/map. 인스턴트 아티클에 지도를 추가할 경우에는 이 방법을 권장합니다.
Google 지도 포함(embed)을 인터랙티브 포함(embed)으로 아티클에 추가하는 경우, 포함한 지도가 표시되지 않을 수 있는 알려진 문제가 있습니다. 이 문제를 해결하려면 지도 콘텐츠("https://www.google.com/maps/embed?...")를 읽어들이는 iframe을 또 다른 iframe 내에 포함해야 합니다.
op-interactive figure를 사용하여 인터랙티브 모듈을 포함할 수 있습니다. 자세한 내용과 예는 여기에서 확인할 수 있습니다. https://developers.facebook.com/docs/instant-articles/reference/interactive.
높이를 정의하려면 포함된 콘텐츠를 둘러싸는 <iframe> 요소에 "height" 속성을 추가하면 됩니다. 속성의 값은 픽셀 단위로 높이를 표시하는 정수여야 합니다. 최대 높이는 960픽셀까지 설정할 수 있습니다.
이미지 사이에 공간을 추가하려면 이미지 사이에 빈 단락(예: <p> </p>)을 추가할 수 있습니다.
속성을 추가하려면 <figcaption> 요소 내에 <cite> 요소를 사용합니다.
Cover 이미지에서 속성이 항상 표시되도록 지정할 수 있습니다. <cite> 요소의 세로 정렬 속성 중 하나를 명시적으로 지정하면 됩니다. 그렇지 않으면 이미지가 확대될 때까지는 인용구가 이미지에 표시되지 않습니다.
동영상 파일(예: mp4 파일)에 대한 직접 링크를 사용하여 커버를 추가해야 합니다. Facebook에 호스팅되는 동영상은 직접 링크를 제공하지 않으므로 커버로 사용하려면 동영상을 다른 곳에 호스팅해야 합니다.
리스트 항목 내에서 몇 가지 HTML 태그를 사용하여 텍스트를 굵게 표시하거나 링크를 추가할 수 있습니다. 색상 또는 글꼴 스타일을 맞춤 설정하려면 Facebook 페이지 인터페이스(설정->인스턴트 아티클)에서 스타일 편집기를 사용할 수 있습니다.
<video> HTML 요소를 사용하여 동영상을 포함하는 경우, 여러 동영상의 연속 재생이 지원되지 않으므로 추가할 수 없습니다.
iframe에 소셜 포함(embed)으로 동영상 플레이어를 포함하는 경우, 포함된 플레이어가 이를 지원하는 경우에 한해 추가할 수 있습니다.
인용문은 지원되지 않으며, 단락 태그 외부에 두어야 합니다.
아티클의 제목이 길어서 두 줄에 표시되는 경우 뉴스피드에 제목만 표시됩니다. 제목이 한 줄에 꼭 맞는 경우 뉴스피드 미리보기에 아티클 텍스트의 시작 부분도 표시됩니다.
아티클을 원래 게시한 날짜/시간을 지정하려면 op-published 클래스를 사용하여 각 아티클의 HTML 마크업에 <time> 요소를 포함해야 합니다.
op-modified 클래스는 필요하지 않습니다. 아티클의 내용을 업데이트함에 따라 저장된 아티클의 버전을 업데이트해야 하는 경우에만 이 클래스로 <time> 요소를 포함해야 합니다.
<figure>를 단락(<p> 태그)에 포함하지 않았는지 확인하세요. 이미지는 article 태그 바로 아래의 figure 태그에 포함해야 합니다.
아쉽게도 슬라이드쇼에서 개별 이미지에 캡션을 추가할 수 없습니다. 전체 슬라이드쇼에 단일 캡션만 추가할 수 있습니다.
자세한 내용은 슬라이드쇼에 대한 문서를 참조하세요.
이미지를 포함하는 <figure> 태그에서 "data-feedback" 속성을 지정하여 이미지에 좋아요 또는 댓글을 추가할 수 있습니다. 예를 들어 data-feedback="fb:likes,fb:comments" 속성을 추가하면 이미지에 좋아요와 댓글이 모두 표시됩니다.
자세한 내용은 피드백 속성에 대한 문서를 참조하세요.
인터랙티브 포함(embed) 같은 항목에 대해 너비를 지정할 때에는 정수 값을 사용하여 너비를 픽셀로 지정하세요. 기본적으로 항목은 전체 너비로 표시됩니다.
인터랙티브 포함(embed)을 여백 없이 표시하려면 콘텐츠가 포함된 iframe에 "no-margin" 클래스를 추가할 수 있습니다.
페이지에 대한 RSS 피드의 승인을 이미 받았으면, 피드 URL을 변경한 경우 다시 승인을 받기 위해 등록할 필요가 없습니다.
Facebook에서는 모든 페이지를 고유한 도메인 이름에 매핑합니다. RSS 피드 자체의 URL은 이 도메인 이름과 일치할 필요가 없습니다. 그러나 피드 내 개별 아티클의 표준 URL은 동일한 도메인 또는 하위 도메인에 속해야 합니다. RSS 피드의 URL만 변경하는 경우에는 아무런 문제도 발생하지 않습니다.
새 도메인을 가리키도록 아티클의 표준 URL을 업데이트하는 경우 파트너 관리자를 통해 이 도메인 업데이트를 요청해야 합니다. 그러면 파트너 관리자는 진행 과정을 안내합니다.
Facebook 앱에 실제 iPhone Store ID, iPad Store ID(테스트의 경우 실제 ID가 아니어도 되며 Apple App Store에서 제공되는 어느 앱이나 사용할 수 있음) 세트가 있는지 확인하고 앱 센터 등록 플랫폼에서 iOS - iPad를 활성화하세요.
의도된 동작입니다. 피드 대화 상자는 첨부 파일이 있는 콘텐츠를 게시하므로 추가 첨부 파일을 맞춤 설정할 수 없습니다.
의도적인 변경 사항입니다. 적절한 게이머와 더욱 관련성 높은 게임 요청을 하기 위해 친구 리스트를 단축했습니다. 게이머는 여전히 검색 필드를 사용하여 원하는 수의 친구를 선택할 수 있습니다.
좋은 소식은 이 변경 사항으로 인해 클릭수가 증가하고 전체 CTR이 크게 증가했다는 것입니다. Facebook은 이 채널을 계속 최적화하고 적절한 사람에게 적절한 게임을 제공하는 새로운 방법을 찾을 수 있을 것으로 기대하고 있습니다.
링크에서 og:title, og:image 등을 변경하면 변경한 시점 이후에 발생한 공유에만 변경 내용이 반영됩니다.
사용자 또는 페이지가 링크를 공유한 후에 게시물에 대한 반응(댓글, 좋아요, 공유 등)이 50회를 넘은 시점부터는 제목을 변경할 수 없습니다. 이는 링크와 상호작용을 한 이후에 사이트가 링크의 상세 정보를 변경하여 다른 항목과 상호작용한 것처럼 보이지 않도록 하기 위한 조치입니다. 다른 속성은 모두 언제든지 변경할 수 있습니다.
링크를 공유한 후에 이미지를 변경한 경우 게시물의 이미지를 새로 고치지 않으면 원래 공유에 이전 이미지가 계속 표시됩니다.
게시물의 링크 이미지를 새로 고치려면 다음 단계를 따르세요.- 뉴스피드의 게시물로 이동합니다.
- 게시물 오른쪽 상단의 생략 부호를 클릭합니다.
- 공유 첨부 파일 새로 고침을 선택합니다.
이미지를 자를 때는 많은 요인을 고려합니다. 예를 들어 Facebook은 감지할 수 있는 면의 중앙에 이미지를 배치하려고 시도합니다.
큰 이미지의 경우 가로세로비를 최대한 1.91:1에 가깝게 유지하여 잘리는 부분 없이 피드에 전체 이미지를 표시하도록 하세요.
페이지 게시물에서는 링크 공유에 항상 가로 방향의 대형 이미지를 사용합니다. 데스크톱과 모바일 피드 모두 마찬가지입니다. 잘리는 부분 없이 피드에 전체 이미지가 표시되도록 최대한 1.91:1 화면 비율에 가깝게 이미지를 유지해야 합니다.
이미지는 비동기식으로 캐시되므로, 사용자가 처음 콘텐츠를 공유할 때 이미지가 표시되지 않을 수 있습니다. 다음을 수행하면 이 문제를 방지할 수 있습니다.
- 공유 디버거로 스크랩을 트리거하여 이미지를 미리 캐시
- 'og:image:height' 및 'og:image:width' 태그를 사용하여 이미지를 명시적으로 지정
600 x 315픽셀보다 작지만 200 x 200픽셀보다 큰 이미지는 작은 정사각형 이미지로 표시됩니다.
모든 URL은 리소스(페이지/이미지)의 표준 위치를 나타내므로 절대 URL이어야 공유와 좋아요를 올바른 URL과 캐시 이미지에 제대로 연결할 수 있습니다.
원본 이미지를 더 이상 사용할 수 없거나, 이미지가 너무 크거나, 일시적인 문제로 인해 가져올 수 없는 경우입니다. 이미지 URL이 Facebook의 크롤러에 액세스할 수 있고, 8MB를 초과하지 않으며, 몇 초의 대기 시간 내에 표시되는지 확인하세요.
페이지의 og:image를 변경할 때 사이트에서 이전 이미지를 삭제하지 마세요. 삭제할 경우 기존의 공유된 콘텐츠에 이러한 흰색 영역이 표시됩니다.
데이터 센터 간의 복제 지연으로 발생할 수 있는 문제입니다. 이 프로세스를 마치는 데 몇 초 정도 걸립니다. 그 때까지 API를 통해 개체 ID를 이용할 수 없습니다.
광고가 완전히 저장되기 이전에 광고 세부 사항을 확인하려고 하는 경우 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 타겟이 너무 작아 도달 예측치에 영향을 미치지 못하기 때문에 발생할 수 있습니다. Facebook은 계속해서 work_positions 제외에 추가되는 도달 예측치에 영향을 미치는 사람 수를 개선할 수 있는 데이터를 수집하고 있습니다.
이 오류는 앱에서 스트림 게시물 URL 보안 마이그레이션을 활성화했기 때문에 발생합니다.
앱에서 이 설정을 켠 경우 앱 설정에서 참조되는 캔버스 URL로 리디렉션되지 않는 한 시스템에서 어떠한 종류의 링크 게시물도 만들 수 없습니다. 앱이 캔버스 앱 및 캔버스 앱 도메인으로 다시 리디렉션되는 게시물 소식만이 아닌 경우 활성화할 필요가 없습니다.
사용자가 명시적인 그래프 API 연결로 표시되지 않는 비즈니스 관리자 연결을 통해 계정과 연결되어 있을 가능성이 있습니다.
적절한 타게팅 필드에 파트너 카테고리를 지정했는지 확인하세요. '/partnercategories' 엔드포인트에서 가져온 파트너 카테고리에는 타게팅 유형을 지정할 때 사용해야 하는 타게팅 필드를 지정하는 'targeting_type'이라고 하는 필드가 포함됩니다.
예를 들어, 파트너 카테고리에서 'behavior '의 '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 엔드포인트에서는 커서 기반 페이지 매김을 사용하므로 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를 쿼리하여 메시지 기록을 가져오고 잠재 고객 확보 중 공유된 정보를 받을 수 있습니다.
잠재 고객 확보 광고가 진행되는 동안에는 기본적으로 보내기 API와 webhook가 차단됩니다. Messenger 잠재 고객 확보 앱에 대한 앱 ID: 413038776280800에 스레드 관리 권한이 부여됩니다. 광고 내 '템플릿 만들기' 대화 상자에서 '보내기 API 차단' 토글을 사용하여 이 동작을 비활성화할 수 있습니다.
잠재 고객 제출이 종료되면 앱이 사용자 메시지에 대한 webhook를 받고 해당 메시지에 답장할 수 있게 됩니다. 앱의 일부로 특정 앱이 선택된 경우 해당 앱만 답장할 수 있고 메시지 채널에 대한 webhook를 받게 됩니다. 메시지 창이 열리고 앱은 보내기 API를 사용하여 답장할 수 있습니다.
Facebook 로그인 을 사용하고 특정 페이지에 pages_messaging 권한을 부여하여 앱 웹사이트에서 앱이 설치됩니다. 승인된 앱은 고급 메시지 기능 내 페이지 설정에 표시됩니다.
페이지에 대해 승인된 앱만 표시됩니다. 고급 메시지 기능 내 페이지 설정에서 승인된 앱을 확인할 수 있습니다. Facebook 로그인 을 사용하고 특정 페이지에 pages_messaging 권한을 부여하여 앱 웹사이트에서 앱이 설치됩니다.
예, Facebook 앱은 여러 페이지를 받아볼 수 있습니다. permission pages_messaging과 같이 앱 검수에 들어가면 앱이 2개 이상의 페이지에서 Webhooks를 수신하도록 받아볼 수 있습니다. 페이로드에 기초하여 각 Webhook의 컨텍스트를 알아보는 것은 사용자가 해야 합니다.
다음은 플랫폼 테스트 사용자를 Messenger 플랫폼 통합에 사용하는 방법입니다.
- 앱의 역할 페이지에서 추가 버튼을 클릭하여 새 테스트 사용자를 만듭니다.
- 이 앱의 테스트 사용자를 승인하시겠어요? 옵션을 토글하고 "manage_pages" 및 "page_messaging" 권한을 부여합니다.
- 수정 버튼을 사용하여 이 사용자를 위한 액세스 토큰을 받습니다(v2.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 로그인의 ID를 사용하고 있습니다. Facebook 로그인의 사용자 ID는 보내기/받기 API와 함께 사용하기 위한 것이 아닙니다. Messenger 플랫폼의 인증을 통해 얻은 사용자 ID만 Messenger 플랫폼에 사용할 수 있습니다.
- ID를 잘못된 페이지 액세스 토큰과 함께 사용하고 있습니다. Messenger 플랫폼을 위한 사용자 ID는 한 페이지로 범위가 지정되는 페이지별 ID입니다. 유효한 사용자 ID를 사용하지만 페이지 액세스 토큰이 다른 페이지와 연결된 경우 호출이 작동하지 않습니다. 같은 페이지와 연결된 사용자 ID와 페이지 액세스 토큰을 사용하세요.
- 최근에 인증되지 않은 전화번호로 메시지를 보내고 있습니다. 보내기 API를 전화번호와 함께 사용하는 경우 전화번호가 최근에 인증된 경우에만 메시지를 보냅니다. 전화번호가 인증된 것으로 표시되더라도 최근에 인증되지 않은 경우 메시지를 보내지 않습니다. 전화번호를 다시 인증하고 24시간 후에 다시 시도해보세요.
"Messenger로 보내기" 플러그인을 사용하는 경우 data-ref 매개변수를 클릭의 컨텍스트와 관련된 정보를 통해 보낼 패스스루 매개변수로 사용할 수 있습니다.
사람들은 Messenger의 검색을 통해 페이지를 찾을 수도 있습니다. 이러한 경우에는 패스스루 매개변수가 없습니다. 계정 연결 기능을 사용하여 대화를 사이트의 사용자 계정에 연결할 수 있습니다.
Messenger 설정에 있는 앱 대시보드의 '최근 오류 보기' 버튼을 누르면 Webhook가 200 response를 수신하거나 실패했는지 표시됩니다.
최근의 Webhook 오류를 보여주는 도구가 있습니다. Webhook가 전달되지 않으면 Facebook 서버가 URL 받아보기를 취소합니다. 도구를 찾으려면 앱 대시보드 > Messenger > 설정으로 이동하여 Webhook 카드 내의 최근 오류 보기 버튼을 확인하세요.
Webhook에서 상태 코드 200을 사용하여 응답하도록 하세요. 이렇게 하면 webhook이 수신되었다는 것을 Facebook에서 알 수 있습니다. 200을 반환하지 않으면 완료될 때까지 호출을 재시도합니다. Webhook에서 장기간 200을 반환하지 않는 경우에는 개발자 알림을 표시합니다.
또한 성공 상태 코드가 적시에 반환되는지 확인하세요. Webhook은 20초 후에 시간 초과됩니다. Webhook이 비동기식으로 처리되어 성공 상태 코드가 즉시 반환되고 별도로 처리되도록 코드를 구성하세요.
Webhook 호출에는 X-Hub-Signature라는 이름의 필드가 헤더에 포함되며 이 필드는 Facebook에서 webhook이 호출되었는지 확인하기 위해 사용할 수 있습니다.
페이지에 대한 OG 태그를 제공하는 것 외에 오픈 그래프 소식을 공유할 때 뉴스피드 또는 타임라인에 게시물이 표시되는 방식을 제어할 수 없습니다. Facebook은 콘텐츠에 대한 참여를 극대화하기 위해 게시물을 자동으로 최적화합니다.
예. 액션 링크 기능은 사용 중단되었습니다. Facebook에서 액션 링크에 대한 지원이 중단되었으며, 이에 따라 플랫폼에서도 더 이상 이용할 수 없습니다. 이 기능은 나중에 다시 논의할 수도 있지만 현재 로드맵에는 포함되어 있지 않습니다.
웹 페이지에서 OpenGraph 메타 태그를 사용하며 og:image 항목이 포함된 경우 이미지를 가져와 미리 보기에 표시합니다. 또한, 사이트에서 og:image, og:image:width, og:image:height를 모두 제공하는 경우 첫 번째 생성된 공유에 대해서도 이미지가 사용됩니다.
이들 항목을 제공하지 않을 경우 Facebook 크롤러가 먼저 이미지를 가져와 분석할 때까지 기다려야 합니다. 이 작업을 수행하는 방법의 예는 http://ogp.me/#structured를 참조하세요.
의도된 동작입니다. REST API는 오래전에 사용 중단되었으며, 계속 작동할 것으로 예상되지 않습니다. 제한이 있습니다. 페이지 액세스 토큰은 REST API와 함께 사용할 수 없습니다.
JS SDK의 'locale' 매개변수를 사용하여 좋아요 버튼의 언어를 설정할 수 있습니다. 이 기능은 로그인하지 않은 사용자만 사용할 수 있습니다. 사용자가 로그인한 경우 해당 사용자의 언어 기본 설정도 고려됩니다. 언어 기본 설정이 특정 언어로 설정된 경우 좋아요 버튼이 해당 언어로 표시됩니다.
Facebook에 로그인하지 않고 페이지를 방문하여(또는 브라우저의 비공개 세션을 사용하여) 이 동작을 테스트할 수 있습니다.
Facebook에 공유할 때 텍스트 영역을 미리 채우는 것은 Facebook 정책에 위배됩니다. 앱 사용자가 공유할 텍스트를 직접 채워야 합니다.
공유할 때 텍스트 영역에 미리 입력하는 것은 플랫폼 정책 2.3( https://developers.facebook.com/policy/#control )을 위반하는 것입니다. Facebook은 사용자가 정확히 Facebook에 공유하고 싶은 콘텐츠를 공유하고, 자신이 승인하지 않은 텍스트를 실수로 공유하지 않도록 하기 위해 이 정책을 적용합니다.
웹 페이지의 URL을 변경하거나 수정하는 경우 이러한 동작이 예상됩니다. 댓글 플러그인이 포함된 각 URL은 별도의 오픈 그래프 개체로 간주되며 댓글은 해당 개체와 연결됩니다. 따라서, URL을 수정하는 경우 새 개체가 생성되며 기존 댓글이 페이지에 표시되지 않을 수도 있습니다.
아니요. API를 통해 댓글 플러그인에 댓글을 게시할 수 없습니다.
공유자가 맞춤 매개변수의 전달을 허용하지 않고 대신 페이지의 open-graph 메타 태그에서 meta-data를 직접 가져옵니다.
콘텐츠 공유의 모범 사례에 대해 자세히 알아보려면 다음 문서를 참조하세요. 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/)로 변경할 수 없습니다. 모든 미디어 스토리지는 이 기본 위치로 설정해야 제대로 작동합니다.
아니요, 지금은 Coreapp과 Webapp 사이에서 미디어 볼륨을 공유하려면 AWS EFS를 사용해야 합니다.
아니요, Facebook에서는 KOPS를 지원하지 않습니다. ECS 기반 AWS 솔루션은 지원합니다. 또한 일반적인 Kubernetes minikube 설정이 있습니다.
Coreapp이 Coreapp 컨테이너에 있는 /usr/local/waent/data와 /usr/local/waent/log 디렉터리를 확인하여 저장 공간이 10MB 이상 남아 있는지 확인합니다. 그렇지 않을 경우 이런 치명적 오류가 발생합니다.
로그와 데이터 디렉터리에서 저장 공간이 충분한지 확인하세요.
아니요. 현재 동일한 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 테이블을 정기적으로 정리하여 데이터베이스 관리를 돕습니다.
가비지 컬렉터는 특정 메시지를 보관하여 성공적으로 전송/처리되도록 합니다. 예를 들어 일정 기간 수신되는 메시지를 보관하여 비즈니스 통합에서 해당 메시지를 읽음으로 표시하도록 합니다.
Coreapp이 임의의 간격(예: 몇 시간 간격)으로 가비지 컬렉션을 실행합니다. 이는 고가용성 스택에서 데이터베이스 충돌로 인해 성능이 저하되지 않도록 방지하기 위한 조치입니다.
가비지 컬렉션은 콜백 대기열과는 무관합니다. 예를 들어 Webhook 서버를 4일 동안 사용할 수 없을 경우 콜백을 저장하여 Webhook 서버 연결이 복원되었을 때 전송되도록 합니다.
링크는 공식 비즈니스 계정이 있거나 수신자가 비즈니스 전화번호를 연락처로 이미 저장한 경우에만 클릭이 가능합니다.
v2.29.x 이전에는 버그로 인해 시간이 지날수록 발송 메시지 대기열이 늘어나는 경우가 있었습니다. 이 문제를 해결하려면 v2.29.3으로 업그레이드하세요.
사용자의 예상 위치와 언어에 따라 적절한 QR 코드를 사용해야 합니다.
이제 WhatsApp Business Management API에서 직접 QR 코드를 생성하고 관리할 수 있으며, 사용자는 WhatsApp, iOS 또는 Android 카메라로 QR 코드를 스캔할 수 있습니다.
또한 WhatsApp QR 코드를 사용할 경우
- 미리 입력된 메시지를 완전히 맞춤 설정하고 언제든 변경하거나 삭제할 수 있습니다.
- 사용자는 항상 삽입 페이지 없이 바로 앱으로 이동합니다.
- 만료된 코드의 경우 앱 내 환경에서 사용자에게 명확한 메시지를 보냅니다.
사용자가 삭제된 QR 코드나 단축 링크에 액세스하려고 시도하면 QR 코드/단축 링크가 만료되었다는 오류 메시지가 표시됩니다.
사용자가 WhatsApp 데스크톱 클라이언트를 설치한 경우 비즈니스와의 대화가 시작됩니다. 그렇지 않을 경우 WhatsApp 데스크톱 클라이언트를 설치하라는 프롬프트가 표시됩니다.
새로운 단축 링크는 링크와 연결되어 미리 입력된 메시지를 언제든지 편집하거나 삭제할 수 있습니다. 또한 URL 구문을 무작위 코드로 축약하므로 URL에 메시지를 포함하고 전화번호를 가릴 필요가 없습니다.
최상의 인쇄 품질을 얻으려면 .svg 파일 형식을 권장합니다.
WhatsApp Business Management API 또는 비즈니스 관리자 UI에서 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 클라이언트는 Windows용 Docker에서 실행되지 않습니다. 개발에 필요한 경우 Linux Virtual 기기를 사용해서 Docker를 실행하는 것이 좋습니다. 프로덕션 작업 부하의 경우 Linux Server를 사용하여 호환성 및 성능 문제가 발생하지 않도록 하는 것이 좋습니다.
오류 코드 471은 품질에 기반한 사용 제한과 관련이 있습니다. 자세한 정보는 품질 기반 사용 제한 문서를 참조하세요.
모든 비즈니스는 가장 낮은 등급에서 시작하고 품질이 좋은 메시지를 더 많이 발송할수록 더 높은 등급으로 자동 업그레이드됩니다.
예, 메시지 템플릿을 전송할 때 수신하는 측에 메시지가 표시되지 않으면 메시지를 표시하지 못했다는 것을 나타내는 오류 개체에 "사용할 수 없는 구조"와 함께 "실패함" 상태 콜백이 수신됩니다. 수신자에 따라서 "전송됨" 상태 콜백을 수신할 수도 있습니다. 이는 그저 수신자가 메시지를 표시하는 데 실패한 이후에 수신자에게 메시지가 전송되었다는 것을 의미합니다.
다음은 메시지 템플릿 전송 측의 인증 오류와 그 이유입니다.
- "your-language 언어로 메시지 템플릿이 존재하지 않습니다" 또는 "your-language 언어 및 your-locale 로캘에 메시지 템플릿이 존재하지 않습니다" — 해당 언어 팩이 존재하지 않습니다. 비즈니스 관리자 계정을 확인하세요.
- "your-template-name 템플릿이 your-language 언어로 존재하지 않습니다" 또는 "your-template-name 템플릿이 your-language 언어 및 your-locale 로캘로 존재하지 않습니다" — 존재하지 않는(생성되지 않았거나 아직 승인되지 않은) 템플릿을 사용하려고 합니다. 삭제된 템플릿으로 메시지를 전송하려고 시도해도 이 오류가 발생합니다.
- "localizable_params num1 개수가 예상 params num2 개수와 일치하지 않습니다" — 예상 매개변수 개수와 일치하지 않는 매개변수를 포함하여 메시지 템플릿을 전송하려고 합니다. API 호출에서 올바른지 확인하세요.
- "your-template-name은(는) 서식이 있는 템플릿이므로 사용할 템플릿 메시지 API가 필요합니다" — 미디어 메시지 템플릿을 일반 메시지 템플릿으로 보내려고 시도합니다. 메시지 유형이
template인지 확인하세요. 자세한 내용은 미디어 메시지 템플릿 문서를 참조하세요. - 비즈니스 관리자에서 템플릿을 승인하면(또는 삭제하면) WhatsApp Business API 클라이언트가 업데이트된 템플릿을 수신하기까지 최대 20분이 소요될 수 있습니다. 방금 승인을 받은 템플릿으로 메시지 전송을 시도하면 템플릿이 존재하지 않는다는 오류가 표시되고, 위의 지정된 시간만큼 기다린 이후에 메시지 전송을 시도할 수 있습니다.
메시지는 (정확히 한 번이 아니라) 적어도 한 번 수신하도록 보장되어 있기 때문에 WhatsApp Webhook으로 중복 메시지가 전송될 수 있습니다. 이로 인해 개발자 측에서 메시지를 처리하는 데 영향이 발생한다면 메시지 ID를 기준으로 Webhook 메시지의 중복을 제거하는 것이 좋습니다.
v2.18.26 릴리즈부터 앱 통계 엔드포인트에서 내부 지표를 Prometheus 텍스트 형식으로 내보낼 수 있게 되었습니다. 자세한 내용은 인스턴스 모니터링 문서를 참조하세요.
비즈니스 프로필이 부분적으로만 채워져 있는 경우 빈 profile 개체가 반환됩니다. 이 문제를 해결하려면 v2.21.4로 업그레이드하세요.
비즈니스 프로필 작성에 대한 자세한 내용은 비즈니스 프로필 설정 문서를 참조하세요.
AWS 배포를 설정할 때 다음과 유사한 오류를 수신하는 경우, 스택 이름을 8자 이하로 변경해보세요.
국가 이름(2자 코드) [AU]:주 또는 도 이름(전체 이름) [Some-State]:인근 지역 이름(예: 도시) []:조직 이름(예: 회사) [Internet Widgits Pty Ltd]:조직 부서 이름(예: 섹션) []:일반 이름(예: FQDN 서버 또는 q본인의 이름) []:문자열이 너무 깁니다. 길이가 64바이트 미만이어야 합니다. 일반 이름(예: FQDN 서버 또는 본인의 이름) []:이메일 주소[]:오류, 구성 파일에 지정된 개체가 없음, 인증서 요청 중 문제 발생, internal-wa-inc-name-LB-123456789.ap-southeast-1.elb.amazonaws.com에 대한 기기 키가 생성됨
메시지 템플릿에서 허용되는 매개변수 개수에는 제한이 없습니다.
WhatsApp 비즈니스 계정 1개당 최대 250개 메시지 템플릿이 허용됩니다.
어떤 이유로든 Webhook 이벤트가 전송되지 않거나(예: 클라이언트가 오프라인인 경우) Webhook 요청이 200 외에 다른 HTTP 상태 코드를 반환하면 Webhook 전송을 다시 시도합니다. 지연 시간이 점차 늘어나 특정 시간 초과에 도달하거나(일반적으로 24시간이지만 차이가 있을 수 있음) 전송이 성공할 때까지 다시 시도합니다.
고객 문의를 처리하는 데 더 많은 시간이 필요하고 24시간이 지난 이후에만 응답을 할 수 있는 경우가 있습니다. 다음과 같이 메시지 템플릿을 생성해서 처리하는 것이 좋습니다.
- 사용자에게 결과를 전달합니다.
- 또는 고객 서비스 창을 활성화하기 위해 답장할 사용자를 호출합니다.
두 경우 모두 메시지 템플릿에 최대한 많은 컨텍스트를 제공하세요. 예를 들면 다음과 같습니다.
- "{{1}} 님, 안녕하세요. 앞서 신고한 문제와 관련하여 유감스럽지만 {{2}}임을 알려드립니다. 불편을 끼쳐드려 죄송합니다."
- 관련 티켓을 업데이트했습니다. 지원을 계속 받으시려면 회신해주세요."
WhatsApp은 WhatsApp Business API 알림이 사용자 경험과 제품 전반에 미치는 영향을 측정하고 이해하고자 실험을 수행합니다. 메시지를 보내려고 하는 사용자가 이런 실험에 속해 있다면 알림을 수신하도록 옵트인했더라도 알림을 받지 못할 수 있습니다.
현재 설정을 백업하고 새 기기에서 복원할 경우, 구현과 함께 등록 정보도 이동합니다. 자세한 내용은 백업 및 복원 설정 문서를 참조하세요.
예, Webapp 컨테이너와 Coreapp 컨테이너의 로그 로테이션은 약간 다르게 동작합니다.
- Webapp: 최근 30개 로그 파일이 보관됩니다. 용량이 20MB를 넘는 경우에만 로그 파일이 로테이션됩니다.
- Coreapp: 최근 30개 로그 파일이 보관됩니다. 용량이 15MB를 넘는 경우에만 로그 파일이 로테이션됩니다. 로테이션된 파일은 압축됩니다.
WhatsApp Business API 클라이언트의 모든 빌드에는 릴리스 날짜로부터 6개월의 만료기간이 있습니다. 이 오류가 표시되면 가능한 한 빨리 최신 릴리스 버전으로 업그레이드하세요.
사용자가 보내는 메시지 페이로드는 텍스트 또는 미디어 파일입니다.
텍스트의 경우, 확인된 위험은 없는 것으로 간주됩니다.
미디어 파일:
- 일반적으로 비즈니스에서는 각종 잠재적인 위협을 분석하기 위해 일종의 보호 소프트웨어(예: 바이러스 백신, 악성 코드 방지 등)를 확보하고 있을 것으로 예상됩니다.
- WhatsApp은 엔드투엔드로 암호화되어 있으므로 전송 중인 파일의 내용을 식별하거나 검사할 수 없습니다(텍스트만 있는 콘텐츠의 경우에도 마찬가지).
- WhatsApp Business API 클라이언트에서 미디어 파일이 자동으로 다운로드되지 못하게 하는 옵션이 있습니다. 비즈니스가 사용자로부터 파일을 수신하고 싶지 않을 경우
auto_download필드를 빈 배열로 설정하면 됩니다.
아니요, WhatsApp Business API를 사용하여 여러 기기가 동일한 번호를 사용하는지 확인할 방법은 없습니다.
사용할 수 없는 구조 오류는 휴대폰에서 템플릿 메시지를 읽을 수 없을 경우에 발생합니다.
템플릿은 서버에 저장됩니다. 템플릿 메시지가 messages 노드를 사용하여 전송되는 경우전체 메시지가 아니라 네임스페이스, 언어, 요소 이름, 현지화된 매개변수만 전화번호로 전송됩니다. 이 값이 휴대폰으로 전달되면 메시지 렌더링을 시도합니다.
렌더링 중 오류가 발생할 경우 structure unavailable 오류가 받는 사람과 메시지 ID가 포함된 콜백 URL로 전송됩니다. 이 오류는 네임스페이스가 잘못되었거나, 현지화된 매개변수가 일치하지 않거나, 요소 이름이 잘못된 것 등이 원인일 수 있습니다.
Facebook 비즈니스 관리자의 WhatsApp 관리자에서 매개변수의 올바른 개수를 확인하세요. 네임스페이스가 올바른지, 요소 이름이 존재하는지 다시 한번 확인하세요.
가장 일반적인 오류 원인은 사용 중인 모든 템플릿에 번역을 생성하지 않은 것입니다. 예를 들어 일반적으로 전송하는 템플릿이 2개이고 하나의 템플릿에 새 언어 번역을 추가한다면 나머지 다른 템플릿에도 새 언어 번역을 추가해야 합니다. 2개 이상의 언어를 지원할 계획이라면 모든 지원되는 언어로 모든 템플릿에 번역문을 제공해야 합니다.
다행히 structure unavailable 오류는 messages API 호출에서의 실수로 인해 발생하는 경우가 대부분이고 이는 전송 페이로드를 변경하면 수정할 수 있습니다.
Facebook 비즈니스 관리자의 WhatsApp 계정에서 새 전화번호를 등록하고 기존 전화번호를 삭제할 수 있습니다.
- WhatsApp 계정에서 설정으로 이동합니다.
- WhatsApp 관리자를 클릭합니다.
- 전화번호 탭을 클릭합니다. 여기에서 이 계정의 모든 전화번호를 관리할 수 있습니다.
이미지 캡션은 설명으로 추가됩니다. 캡션 텍스트는 Android와 iPhone의 이미지에서 모두 전체 길이가 표시됩니다.
문서 캡션은 파일 이름을 대체합니다. 사용자 기기에 설명 텍스트로 표시되지 않고 파일 이름으로 표시됩니다. iPhone은 전체 텍스트를 표시하지만 Android는 파일 이름을 자릅니다. 이는 두 기기에서 실행하는 WhatsApp 최신 구현에 적용된 기술적 제한입니다.
시도 횟수를 초과해서 "sms" 등록이 실패하고 "access denied" 메시지가 나왔다면 "음성" 등록을 시도하세요.
현재는 7일이 소요됩니다. 캐시가 7일 이상 업데이트되지 않으면 팩에 그 요소가 존재하는지 여부와 관계없이 서버에서 최신 언어 팩을 가져옵니다.
기기는 먼저 캐시에서 메시지를 읽어들이고, 요소가 있는 경우 해당 메시지 템플릿을 사용해 메시지의 압축을 풉니다. 따라서 메시지 템플릿을 수정하는 것보다는 간단히 다른 요소 이름을 가진 새 템플릿을 추가하는 것이 안전합니다. 이렇게 하면 해당 요소를 찾을 수 없을 때 언어 팩을 다시 다운로드하도록 보장할 수 있습니다. 메시지 템플릿은 저장소 비용이 미미한 수준이므로 메시지 템플릿을 꼭 삭제할 필요는 없습니다.
자세한 내용은 메시지 템플릿 전송 — 언어를 참조하세요.
비즈니스와 사용자에게 좋은 품질의 경험을 제공하기 위해 제한적 공개 미리보기를 실시하는 중입니다. 당사와 협력하고자 하는 경우, 가용 범위를 꾸준히 확장하는 동안 귀사에 관한 자세한 정보를 제출하여 고려해줄 것을 요청하거나 Facebook 담당자가 이미 있는 경우 해당 담당자에게 문의하시기 바랍니다.
users 엔드포인트를 통해 사용자를 로그아웃시키면 해당 계정에 할당된 모든 인증 토큰이 무효화됩니다. 사용자를 삭제해도 같은 결과를 얻을 수 있지만, 이것은 훨씬 극단적인 방법입니다. 사용자를 users 엔드포인트를 통해 로그인시키면 새 인증 토큰이 반환되지만 해당 사용자에 대해 돌고 있는 인증 토큰이 무효화되지 않습니다. 이전에 프로비저닝된 토큰을 소유한 사람은 누구나 만료되거나 앞서 말씀드린 방법 중 하나로 무효화하기 전까지 해당 토큰을 계속 사용할 수 있습니다.
이 오류가 표시되었지만 누락된 필수 매개변수가 json 본문에서 설정된 매개변수를 나타낸다면 json 파싱 오류일 수 있습니다. json 형식 지정 오류로 인해 json 페이로드 전체를 파싱할 수 없을 때 이 오류가 발생합니다. 이 매개변수 값에 잘못된 json 문자가 있는지 확인하세요(예: 끝에 캐리지 리턴). 매개변수가 json을 손상시키는 문자가 포함된 추가 공백과 같이 복사될 수 있습니다.
이유는 여러 가지가 있습니다. Coreapp이 중단되었거나 데이터베이스가 올바르게 설정되지 않았을 수 있습니다. 이 경우가 아니라면 Coreapp 로그를 참조하세요(다중 연결을 실행 중이라면 마스터 Coreapp 로그 참조). 데이터베이스 연결 오류가 나타나면 데이터베이스가 연결되지 않았을 가능성이 큽니다. 이 오류에 대한 내용은 MySQL 문서 또는 PostgreSQL 문서를 참조하세요.
데이터베이스에서 데이터베이스 연결 수를 늘리는 것이 좋습니다. 데이터베이스 연결은 1000개가 안정적이지만 연결 개수는 정보에 입각하여 직접 결정해주세요. 오류가 지속되면 지원 티켓을 여세요.
메시지 템플릿이 거부될 만한 이유는 다음과 같습니다.
- 욕설이나 스팸성 콘텐츠와 같은 잠재적인 모욕적 콘텐츠 포함
- 홍보성 콘텐츠 포함
- 선택 태그 유형과 일치하지 않음
- 잘못된 서식
"연결이 거부됨" 오류가 발생했다면 Coreapp이 실행되고 있지 않을 가능성이 큽니다. docker ps를 사용하여 Coreapp이 실행되고 있는지 확인하세요. 실행되고 있지 않은 경우, Docker 로그를 살펴봅니다. Coreapp이 데이터베이스에 연결하지 못할 수 있습니다. 데이터베이스가 올바르게 설정되어 있어야 합니다.
Docker 브리지가 손상되면 발생하는 오류입니다. 가장 좋은 해결 방법은 Docker 서비스를 중단하고 다시 시작하는 것입니다. 컨테이너에서 docker restart를 시도해볼 수도 있습니다.
WhatsApp은 제공된 번호가 실제로 전화기에서 사용하는 번호인지 엄격히 확인합니다. 사용자에게 WhatsApp 계정이 있다는 것은 사용자가 전화번호를 인증하였고 그 이후에 그 번호를 WhatsApp에 등록한 사람이 없다는 증거입니다. 그러나 SIM 카드의 물리적 위치를 보증하지는 않습니다.
반면, 사용자의 전화기가 분실되거나 도난 당하는 경우 사용자가 WhatsApp 계정을 비활성화할 수 있습니다. 사용자가 계정을 비활성화할 수 있는 방법에 대해 자세히 알아보려면 전화기 분실 및 도난 FAQ를 참조하세요.
고객 전화번호가 비활성화되었지만 고객이 아직 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.
예, TCP 연결이 필요합니다. 비즈니스에서 추가 포트를 열 수 없다면 terminated SSL을 사용하세요.
자세한 내용은 네트워크 요구 사항 문서를 참조하세요.
이는 알려진 문제입니다. WhatsApp Business API 클라이언트를 CloudFormation 스크립트를 사용해 업그레이드하면 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 클라이언트는 Coreapp 컨테이너를 통해 Webhook 콜백을 전송합니다. 따라서 Webhook 엔드포인트를 구성해야 Coreapp에서 인바운드 요청을 수락할 수 있습니다.
테스트를 위한 두 번째 전화번호를 등록하고 두 번째 CloudFormation 스택이나 Docker 인스턴스를 만들어야 합니다. 같은 전화번호를 사용하는 WhatsApp Business API 클라이언트가 두 개 있을 경우 암호화 키가 서로 충돌하므로 서버에서 퇴출됩니다. 프로덕션 클라이언트로 마이그레이션하기 전에 프로덕션이 아닌 인스턴스를 테스트하는 데 사용할 두 번째 환경을 준비하는 것이 좋습니다.
MySQL 5.7.x, PostgreSQL 9.5.x, 9.6.x, 10.x 버전을 사용해야 합니다. 그 이하의 버전을 사용하면 Unable to initialize config store 오류가 발생합니다.
메시지를 전송하는 즉시 메시지 ID로 돌아갑니다. 즉, 메시지 요청이 데이터베이스에 저장된 것을 의미합니다. WhatsApp Business API 클라이언트는 WhatsApp 서버에서 승인할 때까지 해당 메시지의 전송을 계속 시도합니다. 이 프로세스는 종료 시간이 정해져 있지 않습니다. 그러면 WhatsApp 서버에서 사용자 전화기로 해당 메시지를 전송하려고 시도할 것입니다. 사용자의 전화기가 온라인 상태가 아니라면 메시지는 30일간 보관되었다가 WhatsApp 서버에서 폐기합니다.
데이터베이스 테이블은 앱 설정, 채팅 스레드, 메시지, 미디어 등과 관련된 정보가 저장됩니다. 이 정보들은 모두 앱이 작동하는 데 필요합니다.
고객이 WhatsApp 전화번호를 변경하더라도 비즈니스에 알리지 않습니다. contacts 노드를 사용하면 해당 전화번호의 상태가 invalid됩니다.
아니요, 인스턴스당 1개 계정을 운영할 수 있습니다. 두 번째 테스트 계정이 필요한 경우 두 번째 인스턴스에는 다른 번호를 사용하세요.
용량이 차면서 시스템 속도가 점점 느려질 수 있습니다. 이런 일은 미디어 파일, 메시지 및 크기가 큰 로그 파일이 많아서 발생할 가능성이 있습니다. 로그 파일은 자동으로 로테이션되지만 용량이 커지기 시작하면 삭제하는 것이 안전합니다.
메시지는 데이터베이스에 저장됩니다. 메시지는 필요에 따라 삭제해도 됩니다. 또한 앱 설정에서 pass_through를 false로 설정하면 모든 메시지가 확실히 삭제할 때까지 데이터베이스에 저장됩니다.
사용자가 보내는 미디어 파일은 미디어 볼륨에 다운로드됩니다. 삭제할 미디어 파일을 선택할 결정권은 비즈니스에 있지만, 보통은 모든 미디어 파일을 삭제하는 것이 안전합니다. 미디어 볼륨 폴더가 어디 있는지 확인하려면 docker inspect your-container-id를 사용하면 됩니다.
Docker를 사용하여 로컬에서 MySQL을 설정하려면 Docker MySQL 가이드를 따르세요.
Docker를 사용하여 로컬에서 PostgreSQL을 설정하려면 Docker PostgreSQL 가이드를 따르세요.
대부분의 경우 데이터베이스를 Core 및 Web 컨테이너와는 별개의 물리적 서버에서 실행해야 합니다. 데이터베이스 서버는 컴퓨터에서 지연이 몇 밀리초 이내로만 발생해야 합니다.
미디어 삭제 시점은 귀하가 결정할 수 있습니다.
미디어를 업로드한 후 미디어 ID를 수신하는데, 이 ID를 사용하여 업로드된 미디어 요소를 포함한 메시지를 전송할 수 있습니다. 미디어 메시지를 전송할 때 WhatsApp Business API가 미디어를 암호화하여 WhatsApp 서버에 업로드합니다. 미디어는 서버에 14일간 저장됩니다. 그 이후에는 미디어 ID를 제공하여 미디어를 삭제하거나 보관했다가 나중에 사용할 수 있습니다. 미디어 보관 기간은 30일을 권장하지만 비즈니스 정책이나 사용 사례에 따라 보관 정책을 결정하시기 바랍니다.
예, 데이터베이스는 WhatsApp 관련 테이블을 건드리지 않고 다른 방식으로 사용할 수 있습니다.
허용 리스트는 호스트 이름 또는 IP 주소로 작성할 수 있습니다.
자세한 내용은 네트워크 요구 사항 문서의 호스트 이름 섹션을 참조하세요.
예! WhatsApp에서는 메시지 안의 선택된 텍스트를 굵게, 기울임, 취소선 또는 고정 너비로 서식을 지정할 수 있습니다.
예, 메시지 템플릿은 이모티콘, 굵게, 기울임 등을 포함한 모든 WhatsApp 메시지 문자와 서식을 지원합니다. 이모티콘의 경우 유니코드 대신 이모티콘 문자(복사/붙여넣기)를 사용해야 합니다.
국가 번호가 포함되어 있다면 수신자 부담 전화번호를 사용할 수 있습니다. 국가 번호가 없는 수신자 부담 번호는 고유하게 식별할 수 없기 때문입니다(같은 번호가 두 국가에 해당될 수 있음).
또한 수신자 부담 번호와 관련된 부가적인 복잡성 문제가 있다는 점도 유의해야 합니다. 일반적으로, 국가 번호를 포함한 수신자 부담 번호로 해당 국가의 국내에서 전화를 걸면 연결되지 않습니다. 이것은 다시 말해 국내 고객이 비즈니스 연락처에 표시된 번호(국가 번호 포함)로 전화할 때 연락이 닿지 않을 가능성이 있다는 뜻입니다. 이런 상황이 우려되는 경우, 그러한 사실을 확실히 알려야 합니다.
수신자 부담 번호에 대한 자세한 내용은 여기를 참조하세요.
아니요! 언제든 하나의 전화번호에 대해 WhatsApp Business API 클라이언트 인스턴스는 하나만 실행할 수 있습니다. 두 번째 인스턴스를 등록하는 즉시 첫 번째 인스턴스가 작동하지 않고 실패합니다. Facebook에서는 이 기능을 사용할 수 있도록 적절한 해결책을 모색하는 중입니다. 업데이트가 있으면 알려드리겠습니다.
WhatsApp은 관리 중인 서버에서 API 엔드포인트를 관리하는 Business API 사용자와의 통신을 엔드투엔드 암호화로 간주합니다. 그 이유는 엔드포인트 사이에 제삼자 액세스가 없기 때문입니다.
WhatsApp Business API 엔드포인트의 관리를 타사 비즈니스 솔루션 제공업체에 위임하는 조직도 있습니다. 이와 같은 경우에도 통신은 여전히 동일한 신호 프로토콜 암호화를 사용합니다. 그러나 WhatsApp Business API 사용자가 엔드포인트 관리를 타사에 위탁했기 때문에 WhatsApp에서는 해당 메시지를 엔드투엔드 암호화로 간주하지 않습니다. 향후 2021년부터는 Facebook에서 호스팅하는 클라우드 기반 버전을 사용하는 비즈니스에도 이와 같은 정책이 적용됩니다.
또한 WhatsApp Business API 클라이언트에 호출을 보낼 때 HTTPS를 사용한다면 해당 데이터는 (백엔드 클라이언트에서 WhatsApp Business API 클라이언트까지) SSL로 암호화됩니다.
자세한 내용은 WhatsApp 암호화 개요 기술 백서를 참조하세요.
이전 버전 iOS 클라이언트에 있는 버그로 인해 발생하는 오류입니다. 일반 집단 업그레이드로 점차 오류가 감소할 것으로 예상합니다.
아니요, 메시지가 도착하는 순서는 보낸 순서와 동일하게 보장되지 않습니다. 사용 사례에서 순서가 중요한 경우 첫 번째 메시지의 전송된 콜백을 수신한 다음, 두 번째 메시지를 보내는 것이 좋습니다.
컨테이너의 오래된 로그를 정리하기 위해 외부에서 트리거할 수 있는 스크립트가 있습니다.
docker exec CONTAINER_NAME /opt/whatsapp/bin/cleanup.sh
스크립트는 Webapp과 Coreapp 컨테이너에서 모두 작동합니다. 이 스크립트를 실행하면 오래된 로그 파일이 삭제되고 컨테이너에는 30개 로그 파일만 남습니다.
참고: WhatsApp Business API를 사용하여 동일한 수신자에게 반복적으로 동일한 메시지를 보내지 마세요.
전달률이 100%가 아닌 이유는 여러 가지가 있을 수 있습니다. 일반적인 사례로는 사용자가 네트워크에 산발적으로 액세스하거나, 일정 기간 비활성화 상태이거나 좋은 품질의 사용자 경험을 만들기 위해 전달되지 않은 경우가 있습니다.
WhatsApp으로 전송 가능한 메시지는 전달률이 매우 높습니다. 그러나 메시지가 전달되지 않는 이유는 여러 가지가 있습니다. 콜백을 모니터링하면 메시지의 정확한 상태에 액세스할 수 있습니다. 예를 들어 이는 SMS로 메시지를 전송하는 것과는 다른데, SMS로 메시지를 전송할 때는 최종 전달된 상태에 액세스할 수 없고 메시지를 다시 전송하면 다른 결과를 초래할 수 있습니다.
메시지가 전달되지 않은 이유는 사용자의 전화기를 사용할 수 없거나, 배터리가 모두 소모되었거나, 전화기를 분실해서 새로운 전화기를 구매했고 SIM을 비활성화했기 때문일 수 있습니다. 비즈니스 클라이언트가 네트워크에 연결하는 기능에 오류가 발생했을 수도 있습니다. 또한 콜백(Webhooks)이 전송되지 않았을 수도 있습니다. health 노드를 사용하여 이러한 상황을 모니터링할 수 있습니다. 서버 수신 콜백을 활성화하면 메시지가 WhatsApp 서버 클라우드로 전달되었는지 알 수 있습니다.
사용자가 네트워크에 다시 연결하면 전송한 모든 메시지가 전달됩니다. 동일한 내용의 메시지를 2번 이상 수신하는 것은 사용자에게 불쾌한 경험을 제공합니다. 그러면 사용자가 차단하거나 불만을 접수할 가능성이 크고 비즈니스가 차단될 가능성이 더욱 커집니다.
메시지를 전송하고 API로부터 메시지 ID를 받았다면 이 메시지 전송을 위해 할 수 있는 일을 완료한 것입니다. 동일한 내용을 동일한 수신자에게 다시 보내지 마세요.
오랫동안 전달률이 낮게 유지되면 기술 지원에 지원 티켓을 제출하세요.
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가 실행되고 인터넷이 연결된 모든 컴퓨터에서 실행할 수 있습니다. 예를 들어 간단한 테스트는 노트북에서 진행할 수 있습니다.
단일 인스턴스 프로덕션 서버 설정에서는 250GB SSD, 16GB RAM, 4코어 CPU 이상의 사양을 권장합니다. HDD는 부하 시에 I/O 속도로 인한 병목 현상이 발생하므로 권장하지 않습니다.
다중 연결 프로덕션 서버 설정에서는 각 Coreapp/Master/Webapp 컨테이너에 대해 50GB SSD, 4GB RAM, 2코어 CPU 이상의 사양을 권장합니다.
대부분의 경우 데이터베이스를 Core 및 Web 컨테이너와 분리된 물리적 서버에서 실행해야 합니다. 데이터베이스 서버는 컴퓨터에서 지연이 몇 밀리초 이내로만 발생해야 합니다.
이 설정은 초당 약 20개 메시지를 전송하도록 지원합니다.
물론입니다! WhatsApp 담당자에게 연락하여 요청하세요.
지금은 채팅 기능을 비활성화할 수 없습니다. WhatsApp에서 사용자가 보낸 인바운드 응답을 처리할 수 없다면 적절한 지원 채널로 리디렉션되는 자동 답글 메시지를 전송하는 것이 좋습니다.
예, 운영을 시작할 때 새 전화번호를 설정하거나 인증된 이름을 변경할 수 있습니다.
최대 파일 업로드 용량은 64MB이며, 이 제한은 메시지에 포함한 모든 이미지, 문서 또는 동영상에도 적용됩니다.
아니요, WhatsApp Business API 솔루션은 이전에 사용하지 않은 번호가 필요합니다.
미디어 볼륨의 마운트 지점을 찾으려면 도커 명령을 실행합니다.
요청
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 컨테이너를 다시 시작할 수 있습니다.
Coreapp Docker 컨테이너
docker restart wacore<Current_WABA_Version>
Webapp 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