Wenn du eine Fehlermeldung wie „Leider ist etwas schiefgelaufen“ erhältst und die Ursache nicht bestimmen kannst, kann du optional auch detaillierte Fehlermeldungen aktivieren, in denen du mehr nützliche Informationen erhältst. Weitere Informationen zum debug-Flag der init()-Methode des SDK findest du unter: https://developers.facebook.com/docs/accountkit/webjs/reference.

Durch die direkte Account Kit-Bestätigung ist kein SMS-Bestätigungscode mehr erforderlich, wenn Android-Nutzer eine Telefonnummer eingeben, die mit der auf Facebook hinterlegten Nummer übereinstimmt.

Das ist nur möglich, wenn der Nutzer die App „Facebook für Android“ verwendet. Wenn wir die Übereinstimmung nicht bestätigen können, durchläuft der Nutzer den normalen Prozess und erhält einen SMS-Bestätigungscode.

Die Liste der Sprachen, für die eine lokalisierte Account Kit-UI vorhanden ist, findest du hier: https://developers.facebook.com/docs/accountkit/languages.

Die aktuelle Liste unterstützter Länder und Vorwahlnummern findest du unter: https://developers.facebook.com/docs/accountkit/countrycodes.

Nein, wir unterstützen nur die Verlinkung des JavaScript-SDK über https://sdk.accountkit.com/en_US/sdk.js. Das Skript ruft den SDK-Lader ab, der das aktuelle SDK entweder über accountkit.com oder aus dem Cache deines Browsers lädt.

Falls du das SDK auf deinem eigenen Server hosten möchtest, besteht eine Schonfrist von 24 Stunden. Nach Ablauf der Schonfrist gibt das SDK Warnmeldungen aus und stellt nach 7 Tagen den Betrieb ein.

Setze den Parameter enableSendToFacebook (unter iOS) oder setFacebookNotificationsEnabled (unter Android) auf „True“.

Nutzer, die sich bei deiner App anmelden, erhalten die Bestätigung als Facebook-Benachrichtigung, wenn die SMS nicht zugestellt werden konnte und es sich bei der entsprechenden Telefonnummer um die primäre Telefonnummer ihres Facebook-Kontos handelt.

Du musst die Berechtigung INTERNET hinzufügen, um API-Methoden aufzurufen. Darüber hinaus kannst du optional zusätzliche Berechtigungen hinzufügen, um den Anmeldeprozess zu optimieren:

• Füge für SMS-Zugriff die Berechtigungen RECEIVE_SMS und READ_PHONE_STATE hinzu.
• Füge für E-Mail-Funktionen die Berechtigung GET_ACCOUNTS hinzu.

Weitere Informationen zur Integration von Account Kit in deine Android-App findest du hier.

Wenn der Nutzer den mobilen „Teilen“- oder Feed-Dialog öffnet, ihn jedoch durch Abbrechen schließt, wird deine App mit dem onSuccess()-Rückruf darüber benachrichtigt. Der onSuccess()-Rückruf ist ein Mechanismus, der dir mitteilt, dass der Dialog auf irgendeine Art erfolgreich geschlossen wurde. Du kannst ihn jedoch nicht verwenden, um zu ermitteln, ob etwas gepostet wurde. Wenn ein Nutzer deiner App die „publish_actions“-Berechtigung gewährt hat, wird bei einem Abbruch die onCancel()-Rückrufmethode aufgerufen.

Details zu den verschiedenen Klassen von Facebook-Rückrufen findest du in der Referenzdokumentation.

Der native „Gefällt mir“-Button (LikeView) verhält sich ähnlich wie der webbasierte Button. Die meisten Facebook-basierten URLs können aufgrund der Privatsphäre nicht verwendet werden. Hiervon ausgenommen sind Facebook-Seiten und die Facebook-Homepage.

Du kannst einen Vorabtest durchführen, wenn du die Vorschau des „Gefällt mir“-Buttons verwendest.

Das ist so vorgesehen. Wir haben viele Spam-Meldungen erhalten, in denen wir über den Missbrauch dieses Features informiert wurden. Mit dieser Änderung wollen wir das Nutzererlebnis verbessern.

Es gibt bessere Möglichkeiten, Inhalte unter Android zu teilen. Entsprechende Informationen findest du hier.

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.

Business apps designed to help businesses and organizations manage Pages, Groups, Events, Ads, and ad-related assets.

• Die App wird zu einem anderen nicht verifizierten Unternehmen verschoben. Alle zuvor genehmigten Berechtigungen werden blockiert.

  • Wenn die App dann zum verifizierten Unternehmen zurückverschoben wird, werden die Berechtigungen entsperrt.
• Für die App ist Bereitstellung von Services für andere Unternehmen angegeben. Sie wurde dann aber zu einem anderen Unternehmen verschoben, das nicht verifiziert wurde.

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.

Weitere Einzelheiten findest du auf dieser Seite. Der Prozess bietet dir die Möglichkeit, Angaben zu den von dir benötigten Berechtigungen und deren Verwendung zu machen. Facebook prüft den Anwendungsfall und entscheidet, ob er nach unseren Richtlinien zulässig ist. Je nach API/Berechtigung sind nach der Berechtigungsprüfung möglicherweise zusätzliche Schritte erforderlich, etwa eine Unternehmensverifizierung und das Unterzeichnen eines Vertrags.

Ob ein App Review erforderlich ist, hängt von der Ebene der App-ID ab. Jede einzelne App, die diese Berechtigungen oder Features verwendet, muss zur Überprüfung eingereicht werden.

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.

Wenn für deine aktuelle Einreichung zusätzliche Informationen erforderlich sind, hast du 30 Tage nach Erhalt der Anfrage Zeit, auf diese zu reagieren und zur Überprüfung erneut einzureichen. Wenn für deine aktuelle Einreichung zusätzliche Informationen erforderlich sind, hast du 30 Tage nach Erhalt der Anfrage Zeit, auf diese zu reagieren und zur Überprüfung erneut einzureichen. Während dieser 30 Tage erhältst du vom App-Review-Team möglicherweise weitere Anfragen für zusätzliche Informationen. Während dieser 30 Tage erhältst du vom App-Review-Team möglicherweise weitere Anfragen für zusätzliche Informationen. Bitte beachte, dass das 30-Tage-Fenster in diesem Zeitraum nicht bei jeder Wiedervorlage zurückgesetzt wird.Bitte beachte, dass das 30-Tage-Fenster in diesem Zeitraum nicht bei jeder Wiedervorlage zurückgesetzt wird.

Um neue Features oder Berechtigungen zu testen, nachdem deine App überprüft und veröffentlicht wurde, kannst du das Feature Test-App erstellen im App-Dashboard verwenden. Damit kannst du einen Klon deiner Produktions-App erstellen. Klicke im Dashboard der Produktions-App im oberen linken Navigationsbereich auf den Nach-unten-Pfeil neben dem App-Namen und klicke auf Test-App erstellen. Der App-Klon, der mit dem Status In Entwicklung erstellt wurde, erlaubt allen App-Rollen Zugriff auf alle Features und Berechtigungen.

Wenn die Kunden auch die „Eigentümer“ der App sind, durchlaufen sie den Prozess selbst als direkte Entwickler. Wenn die Kunden einen externen Entwickler als „Eigentümer“ der App haben, dann durchläuft der Entwickler die Überprüfung.

Du musst die Berechtigungen leads_retrieval und pages_manage_ads anfordern.

Du kannst einen Screencast deiner Integration übermitteln oder, falls deine App keine Benutzeroberfläche besitzt, mindestens zwei Screenshots übermitteln, welche die Einstellungsansicht deiner Seite, deinen CRM oder Business Manager zeigen und eine Seiten-ID für eine Seite angeben, die du über diese Produkte verwendest. Weitere Informationen zu dieser Option findest du hier.

Der App Review-Prozess bezieht sich auf Apps, die bestimmte API-Berechtigungen erfordern. Hier findest du weitere Informationen zu den Berechtigungen, die eine Überprüfung erfordern. Zur Einrichtung des SDK selbst ist kein App Review erforderlich. Das SDK ermöglicht es Apps allerdings, Aufrufe an Facebook APIs durchzuführen. Wenn diese APIs eine Überprüfung erfordern, muss die App zum App Review eingereicht werden.

Wenn du bereits ein Business Manager-Konto hast, empfehlen wir dir, die App mit dem bestehenden Business Manager zu verbinden.

Wenn es mehrere Business Manager-Konten gibt, die zum Business gehören, empfehlen wir, die Gründe für mehrere Business Manager-Konten zu ermitteln und die App mit dem am besten geeigneten Business Manager abzustimmen. Wenn das Business über einen über den Business Manager eingerichteten Kreditrahmen verfügt, empfehlen wir, die App mit demjenigen zu verbinden, der über den Kreditrahmen verfügt.

Entwickler haben die Möglichkeit, bestimmte Testnutzer anzugeben, falls sie weitere Konfigurationen, Whitelists oder Testnutzer-Profilinformationen nutzen möchten. Wenn sie keinen Testnutzer angeben, verwenden wir einfach einen unserer Testnutzer. Das Feld sollte als optional markiert sein. Wenn es leer bleibt, sollte das zu keiner Blockierung führen.

Der App Review muss für jede App durchgeführt werden. Wir empfehlen dir, dein App-Dashboard zu prüfen. Hier findest du die genaue Liste der Berechtigungen, die überprüft werden müssen.

Die Unternehmensverifizierung ist einmal für jeden Business Manager erforderlich. Wenn du alle deine Apps mit dem gleichen Business Manager verknüpfen möchtest, muss die Unternehmensverifizierung nur einmal durchlaufen werden.

Die App sollte mit dem Business Manager für das Unternehmen verknüpft sein, dem die App letztendlich gehört und das Zugriff auf die Daten hat, die über die App generiert werden. Dieses Unternehmen sollte den Prozess für die Unternehmensverifizierung durchlaufen.

Badging for FMP and IGP will resume by the end of May.

Du kannst jederzeit den Status der Geschäftsverifizierung und der Verträge und Schritte finden, die du im Bereich für die Unternehmensbestätigung im Tab „App Review“ des App-Dashboards vornehmen kannst. Wir senden dir während des gesamten Prozesses Benachrichtigungen, damit du weißt, welche Maßnahmen erforderlich sind.

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.

Derzeit besteht eine gesteigerte Nachfrage. Der gesamte Vorgang kann mehrere Wochen dauern.

• Die Berechtigungsüberprüfung kann mehrere Wochen dauern. Hier findest du aktuelle Informationen zur Dauer.
• Die Unternehmensverifizierung sollte einige Tage dauern, was allerdings von der Qualität der Dokumente abhängt.
• Die Vertragsunterzeichnung kann erfolgen, sobald du deinen designierten Ansprechpartner den Vertrag unterzeichnen lässt.

Im Rahmen des Überprüfungsprozesses wirst du nach Unternehmensinformationen gefragt, etwa nach dem offiziellen Namen, der Adresse und der Telefonnummer des Unternehmens. Außerdem wirst du möglicherweise aufgefordert, Geschäftsdokumente wie Stromrechnungen, Lizenzen oder Gründungsurkunden einzureichen.

Same as other permissions, you will lose access.

Ab 1. August 2018 musst du nur den Business Manager verifizieren, mit dem die App verbunden ist.

Sobald neue APIs verfügbar sind, müssen diese über App Review angefordert werden. Eine Unternehmensverifizierung ist allerdings nur einmal pro Business Manager erforderlich. Daher muss keine erneute Unternehmensverifizierung durchgeführt werden, wenn für eine App neue Berechtigungen oder APIs benötigt werden.

Ja, Test-Apps übernehmen überprüfbare Berechtigungen von übergeordneten Apps.

Die Zeitangaben findest du in diesem Post.

Alle bestehenden Apps, die erweiterte Facebook Login-Berechtigungen aufrufen, und die 6 APIs (Pages, Messenger, Business Manager, Instagram, Groups und Events) müssen für den neuen App Review-Ablauf, inklusive Unternehmensüberprüfung und Vertragsunterzeichnung, eingereicht werden. Der App Review muss vor diesem Datum gestartet, aber nicht abgeschlossen werden. Wenn die Einreichung nicht vor dem 01. August 2018 erfolgt, geht der Zugriff auf diese APIs am 02. August 2018 verloren.

Alle bestehenden Apps, die die Marketing API und Lead Ads Retrieval API aufrufen, müssen vor dem 01. Februar 2019 für den neuen App Review-Ablauf, inklusive Unternehmensüberprüfung und Vertragsunterzeichnung, eingereicht werden.

Weitere Informationen dazu findest du auf dieser Seite. Bei diesem Prozess kannst du Details zu deinen benötigten Berechtigungen angeben und dazu, wie diese verwendet werden. Facebook prüft den Anwendungsfall und bestimmt, ob er unserer Richtlinie entspricht. Nach der Berechtigungsprüfung gibt es je nach API/Berechtigung eventuell noch weitere Anforderungen wie Unternehmensüberprüfung und Vertragsunterzeichnung.

Ein Unternehmen muss nur einmal verifiziert werden. Verträge müssen nur einmal auf Unternehmensebene unterzeichnet werden. Bei anschließenden App-Einreichungen ist zwar der App Review, aber nicht die Verifizierung erforderlich.

Ob der App Review erforderlich ist, wird basierend auf App-ID-Ebene bestimmt. Jede einzelne App, die diese Berechtigungen oder Features verwendet, muss zur Überprüfung eingereicht werden.

Am 01. Mai 2018 haben wir einen neuen App Review-Prozess angekündigt, der für Facebook Login (erweiterte Berechtigungen) und 6 APIs (Pages, Messenger, Business Manager, Instagram, Groups und Events) erforderlich ist. Die App Review-Einreichung für diese APIs/Berechtigungen muss vor dem 01. August 2018 erfolgen, um den Zugriff auf diese APIs aufrecht zu erhalten.

Am 02. Juli 2018 haben wir weitere APIs angekündigt, für die der App Review nötig ist: Marketing API und Lead Ads Retrieval. Die App Review-Einreichung für diese APIs muss vor dem 01. Februar 2019 erfolgen, um den Zugriff aufrecht zu erhalten. Weitere Informationen zu den Fristen findest du hier.

Graph API v3.0. umfasst keine Änderungen an Business Manager APIs. Apps, die Zugriff auf Business_Management-Berechtigungen benötigen, müssen von Facebook überprüft werden.

An der App Review-Richtlinie von Facebook wurden keine Änderungen vorgenommen, die sich auf Apps auswirken, welche die Marketing API von Facebook verwenden. Die Änderungen an der aktuellen API findest du im Änderungsprotokoll für die Graph API.

Ja. Apps können ohne App Review nur auf den Namen, die E-Mail-Adresse und das Profilbild eines Nutzers zugreifen. Alle anderen Berechtigungen erfordern eine Überprüfung durch Facebook.

Die Instagram API ist von Graph API v3.0 nicht betroffen. Allerdings müssen alle Apps, welche die Instagram API verwenden, von Facebook überprüft werden.

In Graph API v3.0 müssen Apps, die auf Events zugreifen, die Berechtigung user_events verwenden. Apps, die diese Berechtigung verwenden, müssen von Facebook überprüft werden.

Die Berechtigung user_managed_groups ist in Graph API v3.0 veraltet. Apps können stattdessen die neue Groups API und die Berechtigungen publish_groups und read_groups_user_data verwenden. Für die neue API und die neuen Berechtigungen müssen Apps von Facebook überprüft werden.

Die Berechtigung publish_actions ist in Graph API v3.0 veraltet. Apps können Meldungen weiterhin über Mediations-Erfahrungen wie den Dialog „Teilen“ von Facebook im Web oder über „Share Sheets“ bei iOS und Android posten. Apps können über die Berechtigung publish_groups, für die eine App den Review durchlaufen muss, in Gruppen veröffentlichen.

Ja. In v3.0 sind alle APIs der Messenger-Plattform unter der Berechtigung „pages_messaging“ enthalten und müssen überprüft werden.

Ja. Apps, die auf Inhalte öffentlicher Seiten zugreifen, müssen das Feature „Zugriff auf öffentliche Seiteninhalte“ anfordern und von Facebook überprüft werden.

Während des Überprüfungsvorgangs folgt unser Überprüfungsteam deinen Anweisungen, um zu reproduzieren, wie in deiner App Berechtigungen verwendet werden. Wenn wir dies nicht reproduzieren können, z. B. weil wir deine Anweisungen nicht befolgen können oder wir uns nicht bei deiner App anmelden können, können wir auch die Einreichung nicht genehmigen.

Gehe wie folgt vor, um dies zu vermeiden:

• Stelle eine funktionierende Version der App zur Verfügung, die die Berechtigung verwendet
• Prüfe, ob deine Anweisungen im Abschnitt „Notizen hinzufügen“ klar formuliert sind
• Prüfe, ob die angefragten Anmeldeberechtigungen die Nutzererfahrung personalisieren und unseren Grundsätzen entsprechen

Bestätige insbesondere für die publish_actions-Berechtigung, dass die Veröffentlichungsfunktion deiner App ordnungsgemäß konfiguriert ist. Wir müssen in der Lage sein, die Inhalte deiner App während des Überprüfungsvorgangs wieder auf Facebook zu veröffentlichen.

Beim App Review-Vorgang wird deine App auf jeder unterstützten Plattform geladen, die Anmeldung mit Facebook durchgeführt und jede Facebook-Integration verwendet, deren Überprüfung du angefragt hast. Dies führt häufig zu den sogenannten „allgemeinen Problemen“. Es handelt sich dabei um Fehler, die mit dem Laden deiner App, dem Anmelden bei deiner App oder allgemeinen Funktionen deiner App zusammenhängen. Es bedeutet, dass wir die Berechtigungen, die du bei deiner Einreichung angefragt hast, nicht testen konnten.

Da wir aufgrund dieser Fehler deine Facebook-Funktionen nicht überprüfen können, können wir auch keine genauen Angaben dazu machen, wie deine App die Facebook-Funktionen, die du zur Überprüfung eingereicht hast, verwendet. Aus diesem Grund erfolgt die Ablehnung aufgrund „allgemeiner Probleme“. Wie geben hierzu Feedback zu jeder Plattform.

Wenn du eine Ablehnung aufgrund „allgemeiner Probleme“ erhältst, lies dir bitte genau das gesamte Feedback durch. Jede Plattform erhält individuelles Feedback, in dem erklärt wird, welche Probleme bei der Überprüfung aufgetreten sind.

In der Antwort zu deiner Überprüfung wird dir genau erklärt, aus welchen Gründen deine App nicht genehmigt wurde. Zudem werden dir die nächsten Schritte empfohlen, die du ergreifen solltest. Wir möchten, dass du die Überprüfung so schnell wie möglich bestehst. Lies dir deshalb das Feedback sorgfältig durch. Sobald du die notwendigen Änderungen vorgenommen hast, kannst du deine App erneut zur Überprüfung einreichen.

Wenn deine App eine Berechtigung auf eine Weise verwendet, die nicht zulässig ist, wird dir dies ebenfalls im Feedback erläutert. In diesem Fall solltest du deine App nicht erneut zur Überprüfung einreichen.

Um für das App Center genehmigt zu werden, muss deine App unsere Auswahlkriterien erfüllen. Für das Facebook App Center in Frage kommende Apps müssen Facebook Login verwenden oder über eine Facebook-Canvas-App verfügen.

Die folgenden Apps können im App Center aufgeführt werden:

• Apps auf einer Facebook-Canvas
• Mobile Apps für iOS oder Android, die Facebook Login unter iOS oder Facebook Login unter Android verwenden
• Web-Apps oder mobile Apps mit Facebook Login

Deine Textelemente und Werbebilder müssen ebenfalls unseren Richtlinien entsprechen.

Wenn du den Dialog „Teilen“ oder ein anderes soziales Plugin verwendest, um Inhalte wieder auf Facebook zu veröffentlichen, musst du die App nicht zur Überprüfung einreichen. Wenn du dir noch immer unsicher bist, findest du weitere Informationen in unserer allgemeinen Überprüfungsdokumentation.

Es verstößt gegen die Plattform-Richtlinie 4.5, Personen einen Anreiz dafür zu bieten, soziale Plugins zu verwenden oder eine Seite mit „Gefällt mir“ zu markieren. Hierzu gehört das Anbieten von Belohnungen oder das Sperren von Apps oder App-Inhalten in Abhängigkeit davon, ob eine Person eine Seite mit „Gefällt mir“ markiert hat oder nicht. User_likes werden für diesen Zweck nicht genehmigt.

Um hochwertige Verbindungen zu gewährleisten und Unternehmen dabei zu unterstützen, die Personen zu erreichen, die ihnen wichtig sind, sollen Personen Seiten mit „Gefällt mir“ markieren, weil sie sich mit ihnen verbinden und mehr von dem jeweiligen Unternehmen erfahren möchten, und nicht aufgrund künstlicher Anreize. Wir sind davon überzeugt, dass die Menschen und Werbetreibenden gleichermaßen von dieser Richtlinie profitieren.

Möglicherweise benötigt unser Überprüfungsteam weitere Anmeldedaten für deine App, um deine Überprüfung abschließen zu können.

Wenn für deine App vor oder nach der Anmeldung mit Facebook Login eine zweite Anmeldung erforderlich ist, stelle hierfür unbedingt einen Nutzernamen und ein Passwort zur Verfügung. Dies können die Anmeldedaten für einen Test- oder Demoserver, für eine zweite Anmeldung in deiner App oder eine E-Mail-Registrierung sein.

Für Apps, die auf Staging- oder Entwicklungsservern gehostet werden, ist möglicherweise für den Zugriff auf deinen Server eine zusätzliche Anmeldung erforderlich. Bitte stelle auch hierfür alle notwendigen Anmeldedaten zur Verfügung.

Wenn du dir noch immer unsicher bist, welche Anmeldedaten fehlen, kannst du mit deiner nächsten Einreichung ein Video einsenden, in dem die Option von Facebook Login und alle relevanten Facebook-Integrationen zu sehen sind, die du einreichst.

Um deine App-Einreichung zu genehmigen, muss sich unser Überprüfungsteam bei deiner App anmelden und alle Facebook-Integrationen prüfen.

Wenn dein Reviewer deine App nicht laden oder verwenden konnte, überprüfe Folgendes:

• Auf die App-URL kann öffentlich zugegriffen werden und sie ist nicht als lokaler Host konfiguriert
• Du hast den Nutzernamen und das Passwort angegeben, mit denen auf deine Entwicklungs- bzw. Staging-Webseite zugegriffen werden kann
• Die Sicherheitszertifikate deiner Webseite sind aktuell und verursachen bei neuen Nutzern keine Fehler
• Du kannst dich als neu erstellter Testnutzer anmelden und deine App verwenden
• Die Elemente, die du zur Überprüfung eingereicht hast, sind in deine App integriert und funktionieren darin

Wenn du aus demselben Grund erneut abgelehnt wirst, bearbeite deine Überprüfungsanweisungen oder den Abschnitt Notizen hinzufügen, um deinen Reviewer um Aufklärung und weitere Informationen zu bitten.

Ein Screencast eignet sich hervorragend dazu, uns durch deine App zu führen und uns zu zeigen, wie du die angeforderten Berechtigungen verwendest. Nachfolgend findest du einige Best Practices und Ressourcen von Drittanbietern zum Erstellen eines Screencasts.

Im Video sollte gezeigt werden, wie deine App jede angefragte Berechtigung verwendet. Wenn du die publish_actions-Berechtigung anfragst, sollte darin auch gezeigt werden, wie Inhalte deiner App erstellt und auf Facebook geteilt werden.

Die für dein Instant Game erstellte Facebook-App-ID kann nicht für eine andere Plattform verwendet werden. Weitere Informationen erhältst du in unserer Dokumentation.

Unser Überprüfungsteam testet die Facebook-Integrationen deiner App anhand deiner Anweisungen.

Wenn du der Ansicht bist, dass unser Überprüfer deine App fälschlicherweise abgelehnt hat, solltest du deine App erneut mit überarbeiteten Anweisungen, die mehr Informationen für den Überprüfer enthalten, einreichen.

Der Überprüfungsvorgang ist am besten geeignet, um mit deinem Überprüfer zu kommunizieren. Reiche dabei deine bearbeiteten Hinweise ein, um auf das erhaltene Feedback einzugehen.

Unser Review-Team verwendet beim Überprüfen von Einreichungen mehrere Testnutzer. Dabei werden nicht immer die von dir bereitgestellten Testnutzer verwendet. Wenn deine Einreichung mit einem bestimmten Testnutzer überprüft werden muss, teile uns das bitte in deinen Überprüfungsanweisungen mit.

Wenn du einen Testnutzer zur Verfügung stellst, prüfe, ob du den Testnutzer ordnungsgemäß erstellt und ihn deiner Einreichung beigefügt hast.

Nein. Sobald du eine Berechtigung erhältst, kannst du sie bei allen Versionen deiner App und auf allen Plattformen verwenden.

Wenn du deine App auf eine neue Plattform ausweitest oder sie dort entwickelst, muss sie nicht erneut zur Überprüfung eingereicht werden. Du musst sie nur dann erneut zur Überprüfung einreichen, wenn du eine neue Berechtigung anfragen möchtest, z. B., wenn du deiner App eine neue Funktion hinzufügst. Das Ändern und Einreichen deiner App-Details oder Open Graph-Handlungen hat keinen Einfluss auf die Berechtigungen, die dir bereits gewährt wurden.

Wenn es sich bei deiner App um ein Spiel handelt und sie über eine Präsenz auf einer Facebook-Canvas verfügt

Du hast zwei Möglichkeiten, um neue Spieler zu deinem Spiel einzuladen:

• Dialog „Anfragen“ Bei Verwendung des Dialogs „Anfragen“ kannst du „filters=app_non_users“ festlegen, um den Dialog so zu filtern, dass nur Personen angezeigt werden, die deine App nicht verwenden. Wenn deine App über eine Canvas-Präsenz verfügt, kannst du auch den Dialog „Anfragen“ unter iOS und Android verwenden.
• Invitable Friends API Wenn deine App ein Spiel ist und du deine eigene Funktion zur Mehrfach-Freundesauswahl entwickeln möchtest, kannst du die Invitable Friends API verwenden, die eine Rangliste mit den Freunden der jeweiligen Person ausgibt, die die App nicht verwenden. Sobald eine Person Freunde zum Einladen ausgewählt hat, kannst du die von der Invitable Friends API zurückgegebenen Schlüssel zum Dialog „Anfragen“ weiterleiten, über den die Person dann eine Einladung an die jeweiligen Freunde senden kann.

Wenn deine App über keine Präsenz auf einer Facebook-Canvas verfügt

Du kannst den Dialog „Nachricht senden“ unter iOS und Android oder den Dialog „Senden“ im Web verwenden. Darüber können Personen direkt an ihre Freunde eine Nachricht senden, die einen Link zu deiner App enthält.

Diese Art von Nachricht ist hervorragend geeignet, um mit einer kleineren Anzahl an Personen auf direkte Weise zu kommunizieren. Der Dialog „Nachricht senden“ und der Dialog „Senden“ beinhalten beide eine Worterkennung, sodass mühelos die Freunde ausgewählt werden können, die eine Einladung erhalten sollen.

Genau genommen testet unser Review-Team, wie deine App die einzelnen Berechtigungen auf den in den Einstellungen deiner App aufgeführten Plattformen verwendet. Dein Reviewer prüft, ob deine Facebook Login-Integration richtig funktioniert und ob jede angefragte Berechtigung unseren Grundsätzen und Richtlinien zur Nützlichkeit entspricht und gleichzeitig für ein verbessertes Nutzererlebnis sorgt.

Weitere Informationen erhältst du in unseren Grundsätzen und Richtlinien zur Nützlichkeit.

Vor der Berechtigung deiner Anfrage für „user_likes“ muss dein Reviewer bestätigen, dass deine App auf Basis der user_likes-Informationen, die sie von den Nutzern erhält, für eine einzigartige Erfahrung sorgt. Hierfür testet unser Review-Team deine App mit unterschiedlichen Testnutzern, die jeweils über verschiedene „Gefällt mir“-Angaben und Interessen verfügen.

Wenn du deine Anfrage für user_likes einreichst, solltest du detaillierte Anweisungen verfassen, die Folgendes enthalten:

• Genaue Darlegung der Gründe, weshalb du user_likes anfragst, und eine detaillierte Erläuterung, wie dadurch die Erfahrung in deiner App verbessert wird
• Eine Liste mit Beispielseiten, die unsere Reviewer mit „Gefällt mir“ markieren können, um deine Verwendung von user_likes zu prüfen Bitte stelle direkte Links zu den Seiten zur Verfügung, die unser Reviewer vor dem Testen deiner App mit „Gefällt mir“ markieren sollte.

Wenn du user_likes in Verbindung mit einem Algorithmus verwendest, ist es wichtig, dass der Reviewer das Ergebnis dieses Algorithmus und seinen Einfluss auf die Inhalte, die Personen gezeigt werden, sehen kann.

In bestimmten Fällen muss der Reviewer unter Umständen eine bestimmte Verhaltensweise oder Erfahrung reproduzieren, die nur für einen bestimmten Testnutzer verfügbar ist. Wenn dies der Fall ist, kannst du diesen Nutzer deiner Einreichung auf der „App Review“-Seite hinzufügen. Im Abschnitt „Zu überprüfende Elemente“ siehst du den Abschnitt „Testnutzer (optional)“, in dem du den Namen des Nutzers eingeben kannst, der bei der Überprüfung verwendet werden soll.

Die einzigen Testnutzer, die hier verfügbar sind, sind im Abschnitt „Rollen“ deiner App als Testnutzer aufgeführt. Bitte teile in deinen Überprüfungsanweisungen keine Facebook-Anmeldedaten für Nutzer.

Erfahre mehr über das Erstellen eines Testnutzers.

Nein, du musst deine App nicht zur Überprüfung einreichen, um Mobile App Install Ads zu schalten. Du benötigst nur eine App, die im iTunes App Store oder Google Play Store erhältlich ist. Du kannst unseren Leitfaden zum Erstellen von Mobile App Install Ads verwenden.

Erkläre genau, wie jede Berechtigung und Funktion in deiner App getestet werden muss. Nur dann können wir sicherstellen, dass sie funktioniert und unsere Richtlinien erfüllt. Wir können deine App nicht genehmigen, wenn wir ihre Integration mit Facebook nicht vollständig testen können. Wenn du detaillierte Anweisungen zur Verfügung stellst, ist die Wahrscheinlichkeit geringer, dass du deine App erneut zur Überprüfung einreichen musst.

Gib für jede Berechtigung, die du anfragst, die Anweisungen zur Reproduzierung in einem Schritt-für-Schritt-Format an. Sämtliche Anweisungen müssen auf Englisch verfasst werden.

Deine Anweisungen sollten nicht:

• Auf Anweisungen anderer Einreichungen oder Dokumentationen verweisen
• Funktionen deiner App zusammenfassen, anstatt Anweisungen zu formulieren
• Technische Details zur Funktionsweise deiner APIs zur Verfügung stellen

Ein gutes Beispiel für Schritt-für-Schritt-Anleitungen:

1. Klicke im Menü links auf den Button „Einstellungen".
2. Wähle „Anmelden mit Facebook“ aus.
3. Schließe Schritt 3 ab.
4. Schließe Schritt 4 ab.

Wenn du dir noch immer unsicher bist, welche Schritte du integrieren solltest, findest du weitere Beispiele in unserem Abschnitt mit Beispielen für den App Review.

Aufgrund von kürzlich vorgenommenen Änderungen am Überprüfungsprozess und der zahlreichen Einreichungen können bis zum Abschluss des Überprüfungsprozesses für eingereichte Apps möglicherweise einige Wochen vergehen.

Stelle zur Unterstützung des Reviewers bitte möglichst viele Informationen zur Verfügung, einschließlich übersichtlicher Screenshots, detaillierter Schritt-für-Schritt-Anleitungen und einer Screencast-Aufnahme deiner App und ihrer Facebook-Integration.

Apps, die Mediationsprodukte zum Teilen verwenden wie soziale Plugins, den „Teilen“-Dialog und Share Sheets oder einen Teil von Facebook Login müssen nicht von Facebook überprüft werden. Mehr zu den Apps, die überprüft werden müssen, findest du in unserer Dokumentation App Review.

Wir prüfen deine App, um bei allen Apps eine hochwertige Facebook-Erfahrung sicherzustellen. Im Allgemeinen müssen sich die Menschen darüber bewusst sein, dass sie sich anmelden und Inhalte auf Facebook posten. Dabei sollten sie kontrollieren können, welche Daten sie mit deiner App und mit Facebook teilen.

Hinweis: Personen, die im „Rollen“-Tab deiner App aufgeführt sind, haben Zugriff auf erweiterte Berechtigungen, ohne überprüft werden zu müssen (z. B. user_posts). Wenn die App veröffentlicht wird, muss sie allerdings den App Review durchlaufen, um auf Informationen zuzugreifen. Dies gilt auch für Personen, die Rollen in deiner App haben.

Alle Funktionen sollten verfügbar sein, wenn sich deine App im Entwicklungsmodus befindet, aber du kannst nur auf deine Daten, die Daten deines Testnutzers oder deine Seitendaten zugreifen. Wenn du deine App veröffentlichen möchtest, musst du auch dann den App Review durchlaufen, wenn du der einzige Nutzer bist.

Wenn du über /BUSINESS_ID/pages eine Liste der Seiten eines Unternehmens abrufst, können nicht alle Felder der Seite angefordert werden und die API gibt möglicherweise einen Fehler aus: (#100) Unknown fields: <FIELD_NAME>.

Das liegt daran, dass dieser Endpunkt nicht wie ähnliche Endpunkte ein Seitenobjekt ausgibt. Darüber hinaus schließt er z. B. auch ausstehende Anfragen ein, die bisher nicht genehmigt wurden. Deshalb ist es nicht möglich, die Felderweiterung zu nutzen, um Felder der Seite zurückzugeben.

Du kannst <BUSINESS_ID>/owned_pages oder <BUSINESS_ID>/client_pages verwenden: Beide Endpunkte sollten Seitenobjekte zurückgeben und die Felderweiterung unterstützen.

Um eine Anfrage an eine verifizierte Seite zu senden, muss ein Facebook Partner Manager das Unternehmen konfigurieren und entsprechende Anfragen an das mit der Seite verbundene Unternehmen erlauben. Unternehmen ohne Facebook Partner Manager können solche Anfragen nicht senden.

Bei der Überprüfung der Datennutzung muss ein App-Admin Folgendes tun:
1. Die genehmigten Berechtigungen und Features einer App überprüfen
2. Bestätigen, dass die App der erlaubten Nutzung entspricht
3. Bestätigen, dass die Facebook-Plattform-Nutzungsbedingungen und Entwicklerrichtlinien eingehalten werden sowie alle anderen anwendbaren Nutzungsbedingungen und Richtlinien

Die Überprüfung der Datennutzung und der App Review sind zwei unterschiedliche (aber dennoch miteinander verknüpfte) Maßnahmen, mit denen die Integrität der Plattform geprüft wird. Der App Review ist ein zukunftsorientierter Prozess, der den Zugriff auf bestimmte Berechtigungen der Facebook-Plattform regelt. Entwickler müssen ihre App einreichen, um den Zugriff auf die Plattform zu rechtfertigen. Die manuelle Prüfung erfolgt durch unser Developer Operations-Team. Nachdem der Zugriff auf die Plattform gewährt wurde, erfolgt die Überprüfung der Datennutzung als jährlicher Prozess, bei dem die Entwickler bestätigen müssen, dass ihre fortgesetzte Nutzung der Facebook-Daten in Übereinstimmung mit unseren Plattform-Nutzungsbedingungen und den Entwicklerrichtlinien erfolgt.

Du musst für jede App, die dein Unternehmen verwaltet, eine Zertifizierung vornehmen.

Du musst den Check-up für jede App durchführen, die du verwaltest (jede App kann mehrere Berechtigungen haben). Du kannst die Zertifizierung für einzelne Apps vornehmen und nach Belieben Prioritäten setzen, solange du den Vorgang vor Ablauf der Frist für die jeweilige App abschließt.

Du wirst aufgefordert, alle Berechtigungen zu zertifizieren, auf die du Zugriff hast. Wenn du jedoch feststellst, dass du auf bestimmte Berechtigungen keinen Zugriff mehr benötigst, kannst du diese Berechtigungen entfernen und benötigst dann auch keine Zertifizierung dafür.

Du kannst alle Apps sehen, für die eine Überprüfung der Datennutzung erforderlich ist, indem du im App-Dashboard die Seite „Meine Apps“ aufrufst. Dort siehst du alle Apps, die du verwaltest, und kannst die Apps herausfiltern, für die eine Überprüfung der Datennutzung erforderlich ist.

Der Vorgang sollte vom App-Administrator ausgeführt werden. Du kannst überprüfen, wer Administrator deiner App ist. Melde dich dazu beim App Dashboard an und klicke links auf der Seite auf „Rollen“. Der App-Administrator sollte eine verantwortliche Stellung haben und berechtigt sein, im Namen deines Unternehmens, Handlungen vorzunehmen.

Jeder Admin kann die Zertifizierung der App vornehmen. Wenn es mehrere Admins für eine App gibt, ist es ausreichend, wenn ein Admin die Zertifizierung vornimmt.

Du hast 60 Tage Zeit ab Beginn des Vorgangs (wenn du die erste Entwickler-Benachrichtigung erhältst) bis zum Ablauf der Frist.

Nach Ablauf der Frist werden wir zunächst deinen Zugriff auf die Plattform sperren. Dazu drosseln wir im Laufe des Monats nach Fristende die API-Aufrufe. Während dieser Zeit kannst du dein App Dashboard aufrufen und die Überprüfung der Datennutzung durchführen, um deine App wieder in einen konformen Zustand zu bringen und den Zugriff auf die Plattform vollständig wiederherzustellen. Einen Monat nach Ablauf der Frist werden wir dir den Zugang zur Plattform vollständig entziehen.

Bei der Überprüfung der Datennutzung werden alle Berechtigungen ermittelt, auf die deine App Zugriff hat, unabhängig davon, ob du sie aktiv nutzt. Wir empfehlen dir, diese Möglichkeit zu nutzen, um deine Integration zu prüfen, die Funktionalität deiner App besser zu verstehen und den Zugriff auf Berechtigungen zu entfernen, die du nicht benötigst.

In einigen Fällen geben wir API-Nutzungsinformationen direkt bei der Überprüfung der Datennutzung an. Ansonsten kannst du die Nutzungsebenen für jede Berechtigung im Abschnitt „Berechtigungen und Features“ im App Dashboard sehen. Wenn du dich angemeldet hast, klicke links auf der Seite auf „App Review“ und wähle dann „Berechtigungen und Features“ im Dropdown-Menü aus. Du siehst eine Spalte für „API-Aufrufe“. Sie ist mit einem grünen Häkchen gekennzeichnet, wenn das Logging zeigt, dass du die Berechtigung aktiv nutzt. Beachte bitte, dass dies nur eine Schätzung ist. Du solltest dich an dein Entwicklerteam wenden, um zu prüfen, ob die Berechtigung für deine Integration erforderlich ist.

Wir verlangen von Entwicklern, dass sie diese automatisch gewährten allgemeinen Berechtigungen zertifizieren, denn sie sind weit verbreitet und ermöglichen den Zugriff auf Nutzerdaten. Auch wenn du diese Daten nicht verwendet hast, solltest du diesen Vorgang abschließen. Die Zertifizierung gibt an, dass jegliche Verwendung der Berechtigung konform ist. Dazu zählt auch, dass sie nicht verwendet werden.

Du solltest zunächst die Berechtigung über das App Dashboard entfernen (klicke im linken Dropdown-Menü unter „App Review“ auf „Meine Berechtigungen und Features“). Dann kannst du die verbleibenden Berechtigungen und Features zertifizieren, die du weiterhin verwendest.

Es gibt einige automatisch gewährte Berechtigungen, die nicht entfernt werden können und für die du eventuell um eine Bestätigung gebeten wirst. Wenn du diese Daten nicht verwendet hast, solltest du diesen Vorgang abschließen. Die Zertifizierung gibt an, dass jegliche Verwendung der Berechtigung konform ist. Dazu zählt auch, dass sie nicht verwendet werden.

Nein. Nachdem du die Berechtigung im App Dashboard entfernt hast, kannst du die Seite zur Überprüfung der Datennutzung aktualisieren. Die Berechtigung, die du entfernt hast, sollte nicht mehr angezeigt werden.

Du musst die Überprüfung der Datennutzung für alle Berechtigungen abschließen, auf die deine App Zugriff hat.

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.

Du kannst Screenshot- oder Banner-Bilder, die bereits für das App Center genehmigt wurden, nicht mehr löschen. Um entsprechende Bilder durch neue Bilder zu ersetzen, klicke auf dem Screenshot oder Banner auf „Bearbeiten“ und wähle ein Ersatzbild aus.

Überprüfe, ob du die Fehlermeldung auch siehst, ohne dass du eine Anfrage für Nutzerfotos sendest, und stelle sicher, dass die ursprüngliche Fehlermeldung sichtbar war. Führe dann die folgende API-Anfrage für „me/photos“ durch und kehre zurück, um zu überprüfen, ob die Fehlermeldung weiterhin sichtbar ist (sie sollte es nicht mehr sein). Stelle beim Testaufruf von „me/photos“ sicher, dass du die richtige App nutzt und den richtigen Zugriffsschlüssel abrufst, der die Berechtigung „user_photos“ erfordert. Dann bist du bereit.

Mit dieser Überprüfung wird gewährleistet, dass Entwickler das Feature in ihrer App gründlich getestet haben, bevor sie die Berechtigung bei uns anfordern. Über die Test-App lässt sich nicht das stabile Verhalten der Haupt-App testen. Du musst die Testanfrage über deine Haupt-App durchführen, um sicherzustellen, dass sie wie erwartet funktioniert, bevor du sie externen Nutzern zur Verfügung stellst. Führe folgende Schritte aus, um manuell eine Anfrage zu senden und zu überprüfen, ob die Warnung noch im Dashboard angezeigt wird (was nicht der Fall sein sollte).

Mit der „Stream-Post-URL-Sicherheit“-Migration verhinderst du, dass URLs von deiner Facebook-App gepostet werden, die nicht auf eine Domain zurückverweisen, die deiner App gehört. Verwende diese Option, wenn deine App Links zu anderen Webseiten veröffentlicht.

Dieses Dashboard-Feature wurde entfernt. Du musst den „/{App-ID}/accounts/test-users/“-Endpunkt verwenden, um einen Testnutzer mit einer App zu verknüpfen. Weitere Informationen findest du hier.

Dieses Verhalten ist so vorgesehen (siehe https://developers.facebook.com/docs/apps/test-users#rules): Testnutzer können keine Fans öffentlicher Facebook-Seiten werden oder Inhalte, wie Pinnwandeinträge, auf entsprechenden Seiten erstellen. Testnutzer können jedoch alle App-Tabs auf der Seite, die mit der von ihnen erstellten App verknüpft ist, anzeigen und mit ihnen interagieren.

Das ist so vorgesehen. Mehrere beliebige Domains sind aus Sicherheitsgründen nicht zulässig.

Das ist so vorgesehen. Der Login-Dialog verwendet eine feste Breite, die nicht an breitere Bildschirme angepasst wird.

Das ist so vorgesehen. Der Entwickler ist dafür verantwortlich, basierend auf dem Nutzergerät die richtige „redirect_uri“ festzulegen. Wenn der Nutzer ein Mobilgerät verwendet, muss als „redirect_uri“ die URL der mobilen Seite verwendet werden.

Das ist so vorgesehen: Hierdurch wird eine potenzielle Sicherheitsschwachstelle geschlossen. Manche Browser hängen das Hash-Fragment einer URL ans Ende der neuen URL an, zu der sie umgeleitet wurden (wenn die neue URL nicht selbst über ein Hash-Fragment verfügt).

Wenn beispielsweise example1.com eine Umleitung an example2.com zurückgibt, öffnet ein Browser, der example1.com#abc öffnen sollte, example2.com#abc. Über Skripte wären die Inhalte des Hash-Fragments von example1.com so auch auf example2.com abrufbar.

Da wir einen Authentifizierungs-Workflow zu einem anderen umleiten können, wäre es möglich, die vertraulichen Authentifizierungsdaten von einer App auf eine andere zu übertragen. Das wird verhindert,wenn wir ein neues Hash-Fragment an die Umleitungs-URL anhängen, um dieses Browser-Verhalten zu unterbinden. Wenn es dir um die Ästhetik oder das clientseitige Verhalten der entsprechenden URL geht, kannst du auch „window.location.hash“ (oder sogar eine eigene serverseitige Umleitung) verwenden, um die unerwünschten Zeichen zu entfernen.

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.

Um eine URL zu teilen, muss das zugehörige Bild mindestens 200 x 200 Pixel betragen. Ist das nicht der Fall, wird eine Fehlermeldung wie die folgende angezeigt: „Bereitgestelltes og:image ist nicht groß genug. Verwende ein Bild mit mindestens 200 x 200 Pixeln.“

Um ein Bild für eine URL festzulegen, untersuchen wir zunächst dein „og:image“-Tag, um zu ermitteln, ob es vorhanden ist und ob es mindestens 200 x 200 Pixel beträgt. Wenn das „og:image“-Tag nicht vorhanden ist, wählen wir das erste Bild aus, das wir auf der entsprechenden Webseite finden.

Wenn dein Bild größer ist als 200 x 200 Pixel und der Fehler dennoch angezeigt wird, solltest du überprüfen, ob du das „og:image“-Tag richtig festgelegt hast, da wir in diesem Fall wahrscheinlich das falsche Bild von deiner Webseite abrufen.

Wir haben das Verhalten des „Teilen“-Plugins geändert, damit es mit anderen Plugins und Features unserer Plattform übereinstimmt.

Das Plugin akzeptiert keine benutzerdefinierten Parameter mehr. Facebook ruft die Informationen, die in der Vorschau angezeigt werden, auf dieselbe Weise ab wie auf Facebook als Beitrag: von den URL-OG-Meta-Tags.

Nein, es ist nicht möglich, „caption“ bei einer geteilten URL zu überschreiben. Lediglich „title“ und „description“ können überschrieben werden.

Apps können keine Alben hochladen, die von anderen Apps erstellt wurden.

In einigen Fällen sind Alben mit keiner App verknüpft (Pinnwandfoto-Alben). Du solltest das „can_upload“-Feld überprüfen. Wenn das „can_upload“-Feld „false“ zurückgibt, bedeutet das, dass Nutzer Fotos nicht direkt über die Albenansicht ihres Profils in dieses Album laden können.

Der Call to Action wird unter dem Symbol für die erneute Wiedergabe angezeigt, sobald die Wiedergabe abgeschlossen ist.

GIFs müssen kleiner sein als 8 MB, damit sie auf Facebook abgespielt werden können.

Es ist derzeit nicht möglich, über die API Kommentare zu nicht veröffentlichen Beiträgen zu posten.

Inline erstellte Videobeiträge werden nicht im „promotable_posts“-Endpunkt angezeigt, da sie bereits hervorgehoben wurden. Bei einem inline erstellten Videobeitrag handelt es sich um einen Beitrag, der bei der Erstellung einer Werbeanzeige verfasst wurde und deshalb nicht erneut beworben werden kann.

Dass inline erstellte Beiträge nicht im „/promotable_posts“-Endpunkt angezeigt werden, ist also kein Fehler.

Das kann passieren, wenn du einen Seitenzugriffsschlüssel verwendest, bei dem der verknüpfte Nutzer in den Seitenrollen als Analyst aufgeführt ist.

Wenn eine Datenanfrage mithilfe der Graph API gesendet wird, gelten verschiedene Datenschutzregeln, durch die bestimmte Daten nicht zurückgegeben werden, obwohl sie auf der Webseite angezeigt werden. Das hängt von verschiedenen Faktoren ab, wie beispielsweise den Privatsphäre-Einstellungen des Nutzers, den Berechtigungen auf App-Ebene usw. Das bedeutet, dass die von der API zurückgegebenen Daten nicht zwangsläufig alle auf der Webseite angezeigten Daten beinhalten.

Wenn Beiträge mit „object_story_spec“ der Ads API verfasst wurden, werden sie als Inline-Beiträge kategorisiert. Um solche Beiträge anzuzeigen, musst du die „/{Seiten-ID}/promotable_posts“-Edge sowie den Modifikator „is_inline“ (in Version 2.3) bzw. „include_inline“ (ab Version 2.4) verwenden. Hier erfährst du mehr dazu.

Das „shares“-Feld gibt einen Wert zurück, wenn der Beitrag mehr als 10-mal geteilt wurde. Wenn ein Beitrag weniger als 10-mal geteilt wurde, lassen wir das Feld entweder aus oder versuchen, eine Zahl zurückzugeben.

Weitere Informationen zu diesem Endpunkt findest du hier: https://developers.facebook.com/docs/graph-api/reference/v2.4/post.

Hierbei handelt es sich um einen alten Wert, der in unserer alten Infrastruktur verwendet wurde und den wir beim Wechsel zur neuen Infrastruktur zwecks Abwärtskompatibilität beibehalten haben.

Dieses Verhalten tritt nur bei alten Beiträgen auf, nicht bei neuen.

Das geschieht absichtlich. Es gibt keine Verbindung zwischen dem Beitrag und den darin enthaltenen Fotos. Wir geben nur das erste hochgeladene Bild zurück.

Das „application“-Feld wird nicht zurückgegeben, wenn der Beitrag der Facebook-Webseite oder der mobilen Facebook-App zugeordnet wurde. Dieses Verhalten wurde der Webseite angepasst, auf der die Attribution für solche Arten von Beiträgen nicht angezeigt wird.

Das „privacy“-Feld eines Beitrags enthält Informationen zur Sichtbarkeit des entsprechenden Beitrags auf Facebook. Wenn ein Seitenbeitrag jedoch auf eine Zielgruppe ausgerichtet oder nur für eine bestimmte Zielgruppe sichtbar ist, werden nicht alle ausgewählten Targeting-Optionen im „privacy“-Feld angezeigt.

Um zu ermitteln, ob der Beitrag auf eine Zielgruppe ausgerichtet oder nur beschränkt sichtbar ist, überprüfe das Feld „targeting“ (bei Gating) bzw. „feed_targeting“ (bei News Feed-Targeting). Weitere Informationen zu den verfügbaren Feldern findest du in der Beitragsdokumentation.

Der für einen Beitrag zurückgegebene „comment_count“-Wert kann Kommentare enthalten, die ausgeblendet oder gelöscht wurden. Die Anzahl der sichtbaren Kommentare eines Beitrags kann jedoch nie größer sein als „comment_count“.

Es ist nicht möglich, die Bildunterschrift einer geteilten URL zu überschreiben. Du kannst jedoch Titel und Beschreibung der URL überschreiben.

Weitere Informationen zu den Feldern, die du über die Graph API posten kannst, findest du in der „/feed“-Dokumentation: https://developers.facebook.com/docs/graph-api/reference/v2.3/page/feed#publish.

Hierbei handelt es sich nicht um einen Fehler. Es liegt daran, wie von der Facebook-App (mobil oder Web) generierte Inhalte angezeigt werden (ohne Attribution zu Facebook).

Wir haben einige Änderungen daran vorgenommen, wie Stream- und Beitragsdaten abgerufen und über die API präsentiert werden.

Wenn beim Abrufen von Beiträgen über die API Probleme auftreten und der Vorgang nicht wie dokumentiert funktioniert, überprüfe Folgendes:

• Der verwendete Zugriffsschlüssel muss über die erforderlichen Berechtigungen verfügen, um auf die gewünschten Beiträge zuzugreifen.
• Stelle sicher, dass alle API-Aufrufe, die du zum Abrufen von Beiträgen verwendest, die „id“ verwenden, die dir in einem vorherigen Aufruf zurückgegeben wurde, und dass du nicht manuell IDs basierend auf Seite, Nutzer oder anderen IDs erstellst.

Fotos, die über Instagram hochgeladen werden, werden als Open Graph-Handlungen veröffentlicht und erfordern entsprechende Open Graph-Berechtigungen, die über die Graph API ausgelesen werden.

Bei Instagram-Fotos lautet die erforderliche Berechtigung „user_actions:instapp“, da es sich bei „instapp“ um den Anwendungs-Namespace für Instagram handelt.

Open Graph-Handlungen werden nicht in der „/feed“-Verbindung angezeigt. Wenn jedoch ein Foto als Open Graph-Handlung hochgeladen wird, kannst du mit den entsprechenden Berechtigungen über die „albums“- oder „/photos“-Verbindung darauf zugreifen.

Weitere Informationen zu Open Graph-Berechtigungen findest du hier.

Das ist so vorgesehen. Unser System gibt diese Fehlermeldung bei Objekten zurück, die gelöscht wurden oder für Überprüfungen von Privatsphäre oder Berechtigungen nicht sichtbar sind.

Es handelt sich hierbei nicht um einen Fehler: Diese Form der Paginierung wird für Kommentare nicht unterstützt.

Das Feld „total_count“ für den summary-Parameter des Endpunkts „/{Nutzer-ID}/accounts“ kann eine höhere Zahl zurückgeben als erwartet. Das liegt daran, dass der total_count-Wert alle gelöschten Seiten enthält, für die der entsprechende Nutzer über die Rolle eines Administrators verfügte.

Die vom Endpunkt selbst zurückgegebenen Daten enthalten jedoch nur nicht gelöschte Seiten.

Für den Endpunkt „/user/likes“ wird nicht länger eine zeitbasierte Paginierung (mit den Parametern „since“ und „until“), sondern eine Cursor-basierte Paginierung (mit den Parametern „before“ und „after“) verwendet.

Weitere Informationen zu den Unterschieden findest du unter https://developers.facebook.com/docs/graph-api/using-graph-api/v2.3#paging.

Mit der Einführung App-spezifischer Nutzer-IDs haben wir auch Änderungen daran vorgenommen, wie der Endpunkt Daten zurückgibt.

Da Version 1.0 bereits veraltet ist, konzentrieren wir uns hier auf Version 2.x. „/v2.0/{ID}“ gibt https://www.facebook.com/{ID} oder https://www.facebook.com/app_scoped_user_id/{ID}.

Das ist so vorgesehen. Der Fehler bedeutet, dass der Zugriffsschlüssel, den du verlängern möchtest, nicht auf die App-ID zugreifen kann, über die der Schlüssel verlängert werden soll.

Das liegt wahrscheinlich daran, dass deine App demografische Einschränkungen enthält und wir erkannt haben, dass der Nutzer, dessen Schlüssel du verlängern möchtest, die entsprechenden Bedingungen nicht (mehr) erfüllt (weil er möglicherweise an einen neuen Standort gezogen ist oder der Standort präziser bestimmt werden konnte).

Es kann auch daran liegen, dass wir nicht bestätigen können, ob der Nutzer die Anforderungen erfüllt (beispielsweise weil wir seinen Standort nicht kennen), und deine App-Beschränkungen entsprechenden Nutzern den Zugriff auf die App nicht gestatten.

Seit Juli 2013 ist es nicht mehr möglich, den Suche-Endpunkt mit einer E-Mail im Nutzer-Suchtyp zu verwenden.

Darüber hinaus wurden mit Version 2.0 zahlreiche Änderungen an der Graph API vorgenommen. Die Möglichkeit, öffentliche Beiträge zu durchsuchen und Stichwortsuchen zu nutzen, ist in Version 2.0 nicht verfügbar.

Einzelheiten hierzu findest du im Änderungsprotokoll.

Alle Apps, die nach dem 30. April 2014 erstellt wurden, nutzen mindestens Version 2 der API. Diese Version gibt mit dem /me/friends-Endpunkt nur App-Freunde zurück. Darüber hinaus handelt es sich jetzt bei allen Nutzer-IDs um App-spezifische IDs, die in der spezifischen App eindeutig und permanent sind.

Weitere Informationen zu allen neuen Features und Änderungen in Version 2.0 findest du hier.

In der Dokumentation zum email-Feld des User-Objekts wird das erwartete Verhalten näher beschrieben: Das Feld wird nicht zurückgegeben, wenn keine gültige E-Mail-Adresse verfügbar ist.

Es kann verschiedene Gründe für deine Annahme geben, dass ein Nutzer über eine E-Mail-Adresse verfügt, obwohl das nicht der Fall ist. Aus Datenschutz- und Sicherheitsgründen ist es nicht möglich, den genauen Grund dafür anzugeben, warum die E-Mail-Adresse eines Nutzers nicht zurückgegeben werden kann.

Hier findest du allerdings einige mögliche Gründe:

• Es ist keine E-Mail-Adresse im Konto vorhanden.
• Es ist keine bestätigte E-Mail-Adresse im Konto vorhanden.
• Es ist keine überprüfte E-Mail-Adresse im Konto vorhanden.
• Der Nutzer hätte bei einer Sicherheitsprüfung seine E-Mail-Adresse erneut eingeben müssen, hat das aber bisher noch nicht getan.
• Die E-Mail-Adresse des Nutzers ist nicht erreichbar.

Diese Beiträge können nicht über die API abgerufen werden, da es sich um geteilte Nutzerinhalte auf einer Seite handelt, und der Nutzer die App nicht für den Abruf seiner Inhalte autorisiert hat.

In der Seitenchronik geteilte Nutzerbeiträge sind nicht über die API verfügbar, wenn der Nutzer die Basisberechtigung für den Inhaltstyp des Beitrags deaktiviert hat.

Um die fehlenden Fotobeiträge von Fans dennoch anzuzeigen, kannst du mit dem Seitenzugriffsschlüssel die Alben der entsprechenden Seite abrufen. Die Fotos sollten sich im Album „Chronik-Fotos“ befinden.

Auch wenn ein Beitrag öffentlich ist und die abgefragte Seite enthält, kann deine App ohne die „read_stream“-Berechtigung des Seitenbesitzers nicht auf den Beitrag zugreifen. Das bedeutet, dass der „{Seiten-ID}/tagged“-Endpunkt nicht alle Beiträge zurückgibt.

Weitere Informationen hierzu findest du in der Dokumentation zum Seiten-Feed.

Es gibt Fälle, in denen eine bestimme App (oder eine beliebige App) aufgrund der Privatsphäre-Einstellungen eines Facebook-Nutzers keine Informationen über diesen Nutzer abrufen kann. Das gilt auch für den Zugriff auf Beiträge, die von diesem Nutzer erstellt wurden – selbst in Fällen, in denen deine App erwartet, den Beitrag sehen zu können (wie bei der Seitenverwaltung).

Das gilt beispielsweise, wenn ein Nutzer die App blockiert oder allen Plattform-Apps den Zugriff auf seine Informationen per API entzogen hat.

Mit Veröffentlichung von Version 2.1 der Graph API wurde dieses Feature entfernt. Für Apps, die vor dem 7. August 2014 erstellt wurden, ist dieses Feld in der signed_request nicht länger vorhanden.

Bei entsprechenden Apps gibt die Eigenschaft „liked“ immer „true“ zurück – unabhängig davon, ob die Person die Seite mit „Gefällt mir“ markiert hat oder nicht.

Verwende die in der Antwort zurückgegebenen Links „paging.next“ und „paging.previous“, um direkt zu den anderen Ergebnisseiten zu gelangen. Mithilfe der angegebenen Links stellst du sicher, dass deine App weiterhin funktioniert, wenn das Format der Paginierungs-Links geändert wird.

Wie bei den meisten Elementen der API geht es nicht um eine 1:1-Zuordnung zu Features und Funktionen der Facebook-Hauptseite. Die organische Reichweite der Seiten-Insights-UI unterscheidet sich deutlich (und wird auch anders berechnet) als die organische Reichweite der API.

Der „Organisch“-Wert in der Seiten-Insights-UI entspricht dem „Unbezahlt“-Wert in der Kennzahl „page_impressions_by_paid_non_paid_unique“, die über die Graph API verfügbar ist.

Wir versuchen derzeit, die beiden Werte anzugleichen, allerdings benötigen wir hierfür etwas Zeit.

Dieser Fehler gibt an, dass der mit dem Zugriffsschlüssel verknüpfte Nutzer die Seite aus Privatsphäre-Gründen nicht sehen kann. Möglicherweise wurde die Seite noch nicht veröffentlicht oder der Nutzer ist kein gültiger Administrator der Seite.

Dieser Fehler tritt für gewöhnlich auf, wenn du versuchst, Statistiken für eine sehr aktive Seite abzurufen. Dieses Problem lässt sich beheben, wenn du mithilfe der Felder „since“ und „until“ die Zeitintervalle reduzierst, für die du Statistiken abrufst.

Dieses Verhalten ist für Test-Apps und Apps im Entwicklungsmodus vorgesehen. Das Feature ist verfügbar, sobald die App veröffentlicht wurde.

Den zugehörigen Beitrag zu dieser Einschränkung findest du hier.

Nur Administratoren, Redakteure und Moderatoren können Seitennachrichten lesen und senden. Personen mit anderen Rollen, wie Werbetreibende und Analysten, können Seitenkonversationen nicht lesen.

Weitere Informationen zu den verschiedenen Seitenrollen findest du unter: https://www.facebook.com/help/289207354498410.

Die Gesamtbeträge für „page_fans“ und „page_fans_country“ sind nicht immer gleich. Verschiedene Faktoren können sich auf den „page_fans_country“-Wert auswirken. Manche Seitenfans haben möglicherweise kein Heimatland in ihrem Konto festgelegt und andere haben vielleicht in ihren Privatsphäre-Einstellungen festgelegt, dass ihr Heimatland nicht sichtbar ist.

Weitere Informationen zu den Privatsphäre-Einstellungen von Facebook findest du im Hilfebereich unter: https://www.facebook.com/help/445588775451827.

Bei manchen öffentlichen Seiten handelt es sich um erneut geteilte Nutzerinhalte. Wenn der Nutzer, der den Beitrag erstellt hat, der App nicht die erforderlichen Berechtigungen gewährt hat, kann sie nicht über die Graph API auf seine Beiträge zugreifen und somit auch keine Kommentare zu diesen Beiträgen verfassen.

Beiträge, die inline im Rahmen einer Werbeanzeige erstellt wurden, können nicht separat beworben werden. Deshalb werden entsprechende Beiträge auch nicht in Aufrufen des „/promotable_posts“-Endpunkts einer Seite angezeigt.

Das passiert, wenn du eine App verwendest, die sich noch im Entwicklungsmodus befindet, um Beiträge zu planen. Verwende eine App, die öffentlich verfügbar ist. Dann sollte es funktionieren.

Leider unterstützen wir das Erstellen, Aktualisieren und Löschen von Titelbildern per API derzeit nicht.

Weitere Informationen zur Titelbild-API findest du unter https://developers.facebook.com/docs/graph-api/reference/cover-photo/#Creating.

Nein, es ist nicht möglich, die Breite über die API zu bearbeiten.

Das ist so vorgesehen. Seitenadministratoren können über die Graph API keine Beiträge auf Seiten veröffentlichen. Dieses Feature steht nur auf Facebook.com und in unseren mobilen Apps zur Verfügung.

Nein, es gibt keine Möglichkeit, eine vollständige Liste der Personen abzurufen, die eine Seite mit „Gefällt mir“ markiert haben. Hierbei handelt es sich nicht um einen Fehler.

Vergewissere dich, dass du beim Durchführen von Handlungen im Namen einer Seite einen Seitenzugriffsschlüssel verwendest. Die Fehlermeldung bedeutet, dass du einen Nutzer- anstelle eines Seitenzugriffsschlüssels verwendest.

Informationen zu den unterschiedlichen Arten von Zugriffsschlüsseln findest du hier: https://developers.facebook.com/docs/facebook-login/access-tokens

Das ist nicht möglich. Beiträge zu fixieren und fixierte Beiträge zu lesen, funktioniert nur über Facebook-eigene Produkte.

Wenn zuvor die Spiegelung von Kommentaren für externe URLs aktiviert wurde, werden die Reaktionen auf Beiträge, deren Kommentare gespiegelt werden, mit der URL protokolliert und beim Aufruf von {URL-id}/reactions> zurückgegeben.

Das Abrufen von Daten für mehr als 1000 Aufschlüsselungswerte des /app_insights/app_event-Endpunkts wird derzeit nicht unterstützt. Wenn du die Daten in bestimmte Kategorien aufschlüsseln möchtest, empfehlen wir die Verwendung der Facebook Analytics-UI. Hier kannst du bestimmte Datenpunkte, wie z. B. spezifische Länder, genauer untersuchen.

Wahrscheinlich rufst du den Endpunkt zu schnell auf, bevor die Daten unsere Server erreicht haben.

Die API-Aufrufe sollten nach einer Wartezeit von ein bis zwei Sekunden ausgeführt werden, damit die Informationen auf all unseren Servern vorhanden sind.

Die Kennzahl „page_fans_country“ stellt für gewöhnlich eine Teilmenge der Anzahl von page_fans dar. Diese Kennzahl schlüsselt die Seitenfans nach Land auf, sofern wir das Land der Nutzer präzise bestimmen können.

Die Kennzahl beinhaltet auch die Top-Länder (nach Fan-Anzahl) der Seitenfans, jedoch nicht alle Länder, in denen sich Fans befinden: Bei Seiten mit Fans in vielen verschiedenen Ländern sind die Länder mit den wenigsten Fans nicht in der Kennzahl enthalten.

Die API unterstützt die Verwendung Offset-basierter Paginierung nicht.

Verwende stattdessen entweder die Paginierungs-Links, die am Ende jeder Antwort von der Graph API zurückgegeben werden, oder am besten die Cursor-basierte Paginierung.

Weitere Informationen zur richtigen Paginierung über die Graph API findest du hier: https://developers.facebook.com/docs/graph-api/using-graph-api/v2.3#paging

Es gibt kurz- und langfristige Zugriffsschlüssel. Die kurzfristigen Schlüssel sind für kurze Sitzungen gedacht und laufen in der Regel nach einigen Stunden ab.

Du kannst kurz- gegen langfristige Schlüssel austauschen. Diese bleiben für gewöhnlich ca. 60 Tage lang gültig.

Weitere Informationen hierzu findest du in der Dokumentation zu Zugriffsschlüsseln.

Das ist so vorgesehen: Die Search API berücksichtigt die Privatsphäre-Einstellungen auf Facebook, ist auf den Nutzer ausgerichtet, dessen Zugriffsschlüssel du verwendest, unterstützt keine Hashtag-Suchen und ist nicht darauf ausgelegt, die gleichen Ergebnisse zurückzugeben wie Suchen, die über das Suchfeld auf Facebook.com durchgeführt werden.

Wir wollen ausdrücklich vermeiden, dass die Search API dieselbe Menge an (spezifischen) Ergebnissen zurückgibt wie Suchen auf Facebook.com. Darüber hinaus werden für allgemeine Beiträge, die über die API zurückgegeben werden, strengere Privatsphäre- und Sicherheitsprüfungen durchgeführt als für gleiche Beiträge auf Facebook.com.

In unserem System bestehen Anfrage-Limits für von Apps durchgeführte API-Aufrufe. Weitere Informationen zu den verschiedenen Limits sowie Schritte, mit denen du vermeidest, dass deine App eingeschränkt wird, findest du unter https://developers.facebook.com/docs/marketing-api/api-rate-limiting.

Du kannst animierte GIFs zu deinem Artikel hinzufügen, indem du ein <figure>-Element verwendest, das ein <img>-Element einschließt, das auf die URL des GIF-Bilds verweist. Du kannst GIF-Bildern – wie anderen Bildern auch – Bildunterschriften und Attributionen hinzufügen.

Weitere Details und Beispiele findest du in der Dokumentation hier.

Du kannst eine Feed-URL auf verschiedenen Seiten erneut verwenden. Beachte dabei, dass nur Artikel abgerufen werden, deren kanonische URL den Domains entspricht, die von der Seite beansprucht werden.

Wir empfehlen folgende Vorgehensweise: Verwende separate RSS-Feeds für einzelne Seiten, die nur die Artikel enthalten, die von dieser Seite aufgerufen werden sollen.

Du kannst unterstützte soziale Einbettungen (einschließlich Videos) hinzufügen. Verwende dafür soziale Einbettungen. Weitere Drittanbieter-Videoplayer lassen sich in deinen Artikeln als interaktive Einbettung hinzufügen.

Interaktive Grafiken und Inhalte kannst du in deinen Artikeln mit einem <figure>-Element und der op-interactive-Klasse einbetten. Das figure-Element sollte einen <iframe> enthalten, in dem sich der einzubettende Content befindet.

Hier findest du weitere Details und Beispiele.

Du kannst eine Bildunterschrift mit dem <figcaption>-Element angeben. In der Bildunterschrift kannst du eine Attribution hinzufügen. Verwende dazu das <cite>-Element.

Weitere Details und Beispiele findest du hier in der Dokumentation.

Wenn sich ein Artikel im Entwurfsmodus befindet, ist er nur für Seitenadministratoren als Instant Article sichtbar. Nachdem du deinen Artikel veröffentlicht hast und sich dieser im Live-Modus befindet, kann er von allen Personen auf Facebook geteilt werden und wird für alle Personen als Instant Article dargestellt.

Überprüfe bitte, ob du die Berechtigung pages_manage_instant_articles für die App erteilt hast. Diese Berechtigung ist erforderlich, um API-Methoden aufzurufen, damit diese die Instant Articles deiner Seite lesen und aktualisieren.

Weitere Informationen zur Verwendung der API findest du hier.

Wenn du das dir=„rtl“-Attribut verwendest, um eine Sprache mit der Leserichtung von rechts nach links in deinem Artikel anzuzeigen, kannst du den Artikel in einer App anzeigen, die RTL-Sprachen in Instant Articles nicht unterstützt.

Vergewissere dich, dass du die neueste Version der App verwendest. Die Mindestversionen von Apps, die RTL-Sprachen unterstützen:

• Facebook für iOS: 52.0
• Facebook für Android: 69.0
• Seitenmanager für iOS: 44.0

Überprüfe, ob du das Attribut dir=„rtl“ für den <body>-Tag deines Artikels festgelegt hast. Wenn dein Artikel keine Sprache mit der Leserichtung von rechts nach links verwendet, solltest du dieses Attribut in deinem Artikel nicht festlegen.

Die News Feed-Vorschau für einen Artikel verwendet das Bild, das in der Webversion des Artikels mit dem „og:image“-Meta-Tag angegeben wurde. Du kannst festlegen, dass statt eines Bilds ein Video als Vorschau angezeigt wird. Füge dazu den Videos in deinem Artikel die Klasse „fb-feed-cover“ hinzu. Weitere Informationen zur Vorschaufunktion im News Feed findest du hier.

Wenn die URL eines Artikels geteilt wird, bevor der Instant Article veröffentlicht wurde, erfolgt eine Weiterleitung auf die mobile Webversion des Artikels. Sobald der Instant Article veröffentlicht wurde, wird in allen Link-Teilvorgängen – einschließlich der Teilvorgänge, bevor der Artikel veröffentlicht wurde – automatisch der Instant Article angezeigt, wenn der Inhalt auf einem Mobilgerät angesehen wird.

In der „views“-Kennzahl für Artikel-Aufrufe werden derzeit nur iOS-Nutzer erfasst. Android-Aufrufe werden separat in der Kennzahl „android_views“ gemessen.

Hier findest du weitere Informationen zu diesem Thema.

Bisher erfolgt noch keine Unterstützung für den Entwicklungs-Feed im Seitenmanager für Android. Um deine Artikel auf Android ansehen zu können, kannst du aktuell als Behelfslösung versuchen, die entsprechenden Artikel als Entwürfe in deinem Produktions-Feed hinzuzufügen.

Du kannst deine Instant Articles über die Seiten-Nutzeroberfläche bearbeiten. Rufe dazu in deinem Browser deine Seite auf und gehe zu „Beitragsoptionen“ > „Instant Articles“. Hier kannst du deine Artikel anzeigen und direkt bearbeiten. Weitere Informationen findest du hier: https://developers.facebook.com/docs/instant-articles/publishing.

Der Timeout-Wert für den Feed-Download ist derzeit auf 30 Sekunden festgelegt.

Nein, der freigegebene Link muss die kanonische URL des Artikels sein. Wenn die URL geändert wird, z. B. durch Hinzufügen von Parametern, wird sie als neue URL betrachtet.

Fehler oder Warnungen, die beim Aufrufen deines RSS-Feeds ermittelt werden, werden auf deiner „Einstellungen“-Seite auf dem „Instant Articles“-Tab angezeigt. Du kannst auch Warnungen und Fehler zu einzelnen Artikeln anzeigen, indem du auf dem „Instant Articles“-Tab auf der Seite „Beitragsoptionen“ auf den jeweiligen Artikel klickst.

Stelle sicher, dass dein RSS-Feed das hier dokumentierte Format aufweist.

Die kanonische URL deiner Artikel sollte auch die für deine Seite konfigurierte Domain (oder deren Subdomain) verwenden. Wenn du siehst, dass neue Artikel abgerufen werden, Updates zu vorhandenen Artikeln jedoch nicht angezeigt werden, stelle sicher, dass du den „op-modified“-Zeitstempel inkrementiert hast.

Hier findest du weitere Informationen zu diesem Thema.

Ein häufiger Grund, warum Artikel nicht über den RSS-Feed aktualisiert werden, liegt darin, dass der „op-modified“-Zeitstempel des Artikels im Feed identisch ist mit dem der zuletzt abgerufenen Artikelversion. Ein Artikel wird nur aktualisiert, wenn sich der Zeitstempel gegenüber der letzten Version geändert hat.

Darüber hinaus solltest du sicherstellen, dass in der aktualisierten Version des Artikels dieselbe kanonische URL verwendet wurde.

Weitere Informationen zum Abrufen von Artikeln aus dem RSS-Feed findest du hier in der Dokumentation.

Es wurde 10 Sekunden lang versucht, deinen RSS-Feed vollständig zu laden und zu analysieren. Der Fehler gibt an, dass dieser Vorgang nicht erfolgreich war.

Eine Möglichkeit, diesen Fehler zu beheben, besteht darin, weniger Elemente in deinen RSS-Feed einzubinden, z. B. nur Artikel einzuschließen, die in den letzten 10 Minuten neu hinzugefügt/geändert wurden. Der Feed wird alle 3 Minuten abgerufen, daher ist es unnötig, nicht geänderte Artikel einzubinden.

Es gibt leider keine Liste mit statischen IP-Adressen für den Crawler. Du kannst jedoch den User Agent unseres Crawlers nutzen: facebookexternalhit/1.1

Wenn ein Update eines Instant Articles mehr als 24 Stunden alt ist (ausgehend von der op-modified-Zeit), wird es bei der Abgleichung ignoriert. Das heißt, dass sich die geänderte Zeit auf einen Zeitrahmen von 24 Stunden innerhalb des modified-Zeitstempels des Artikels bezieht, nicht auf die aktuellen Zeit. In Fällen, in denen das Update ignoriert wird, kannst du manuell Änderungen an den Artikeln vornehmen – über das webbasierte Instant Articles-Editor-Tool.

Hier findest du weitere Informationen zu diesem Thema.

Überprüfe bitte, ob die doppelten Artikel andere kanonische URLs verwenden. Wir verwenden die kanonische URL eines Artikels als eindeutigen Kennzeichner, d. h., Artikel mit unterschiedlichen kanonischen URLs werden als separate Artikel behandelt.

Ein häufiges Problem besteht darin, dass dein CMS Updates für Artikel möglicherweise mit einer anderen URL veröffentlicht und diese Updates damit als neue Artikel abgerufen werden.

Ja, jede Seite ist eindeutig einem Domainnamen zugeordnet. Es handelt sich um eine 1:1-Zuordnung. Es ist erforderlich, dass die Instant Articles, die zu einer spezifischen Seite gehören, kanonische URLs aufweisen, die zu einer bestimmten Domain oder einer entsprechenden Subdomain gehören.

Die Domain der RSS-Feed-URL selbst entspricht jedoch nicht der URL, die der Seite zugeordnet wurde. Diese Einschränkung gilt nur für die kanonischen URLs von Artikeln im Feed.

Wenn du Artikel, je nach Sprache, auf unterschiedlichen Seiten veröffentlichen möchtest, solltest du verschiedene RSS-Feeds für die einzelnen Sprachen einrichten und die einzelnen Seiten so konfigurieren, dass sie den entsprechenden RSS-Feed nutzen.

Nein, sobald ein Artikel aus dem RSS-Feed abgerufen wurde, bleibt er als Instant Article gespeichert, bis du ihn aus den Beitragsoptionen deiner Seite entfernst. Du kannst den Artikel dann sicher aus deinem RSS-Feed entfernen, um die nächsten Abrufvorgänge zu beschleunigen.

Derzeit ist keine API verfügbar, über die Artikel veröffentlicht oder gelöscht werden können. Wir arbeiten daran.

Für den „Gefällt mir“-Button wird die Akzentfarbe verwendet, die in den Formateinstellungen konfiguriert wurde. Stelle sicher, dass du eine Farbe konfiguriert hast, die in deiner Überschrift sichtbar ist.

Darüber hinaus wird der „Gefällt mir“-Button nur angezeigt, wenn die Person, die deinen Artikel ansieht, die Seite noch nicht mit „Gefällt mir“ markiert hat, d. h., sie wird beispielsweise nicht für den Seitenadministrator angezeigt, der die Seite bereits zu einem früheren Zeitpunkt mit „Gefällt mir“ markiert hat.

Achte darauf, nicht mehrere <br>-Tags nacheinander zu verwenden. Wenn du deinen Artikel in mehrere Absätze unterteilen möchtest, empfehlen wir dir, statt Zeilenumbrüchen (<p>)-Tags zu verwenden.

Stelle sicher, dass du dem <figure>-Tag, das das Tracking Pixel einschließt, die „op-tracker“-Klasse hinzugefügt hast. Ohne dieses Tag wird das Pixel als Bildeinbettung behandelt.

Überprüfe, ob du eine Videodatei in einem unterstützten Format verwendest. Eine Liste der unterstützten Videoformate findest du hier.

Du solltest darüber hinaus sicherstellen, dass die Video-Einbettung korrekt in einem <figure>-Tag eingeschlossen ist und dass das Video nicht in einem Absatz (<p>-Tag) eingeschlossen ist.

Diese Warnung wird meist angezeigt, wenn du Content in einen Absatz (<p>-Tags) eingeschlossen hast, bei dem es sich nicht um Text handelt, z. B. Bilder oder interaktive Einbettungen. In Absatz-Tags soll nur Haupttext enthalten sein. Andere Inhalte sollten in einem <figure>-Tag oder anderen geeigneten Container-Elementen hinzugefügt werden.

Nein, das Bildunterschrift-Element (<figcaption>) unterstützt nur die Tags <h1>, <h2> und <cite>. Das Absatz-Tag (<p>) wird nicht unterstützt.

Das „muted“-Attribut wird derzeit nicht für <video>-Elemente unterstützt.

Werbeanzeigen werden über das Standard-HTML5-Element <figure> definiert, das ein <iframe>-Element mit dem Markup für deine Werbeanzeige enthält. Du kannst die „op-ad“-Klasse auf ein <figure>-Element anwenden, um eine Werbeanzeige in einem Artikel anzugeben. Es gibt zwei Möglichkeiten, Werbeanzeigen anzugeben: Du kannst die URL der Werbeanzeige direkt mit dem „src“-Attribut im iframe angeben, oder du bettest den nicht escapten HTML-Code und die Scripts im iframe ein.

Hier findest du weitere Informationen zu Werbeanzeigen: https://developers.facebook.com/docs/instant-articles/reference/ad.

Das Standardbildelement unterstützt die Verwendung eines SVG-Bilds nicht. Du kannst stattdessen eine interaktive Einbettung („op-interactive“) verwenden und ein <img>-Element im iframe hinzufügen. Das „src“-Attribut muss dabei auf die URL des SVG-Bilds festgelegt sein.

Du kannst das Kartenelement verwenden, das hier dokumentiert ist: https://developers.facebook.com/docs/instant-articles/reference/map. Dies ist die empfohlene Vorgehensweise, um Instant Articles eine Karte hinzuzufügen.

Wenn du deinem Artikel eine Google Maps-Einbettung als interaktive Einbettung hinzufügst, gibt es ein bekanntes Problem bei der Funktionsweise der Einbettung, die dazu führen kann, dass die Karte nicht angezeigt wird. Um dieses Problem zu umgehen, musst du den iframe, mit dem der Karteninhalt geladen wird ("https://www.google.com/maps/embed?..."), in einen anderen iframe einschließen.

Du kannst interaktive Module mit einem „op-interactive“-<figure>-Element einbetten. Hier findest du weitere Details und Codebeispiele: https://developers.facebook.com/docs/instant-articles/reference/interactive.

Du kannst eine Höhe angeben, indem du dem <iframe>-Element, das deinen Content einschließt, ein „height“-Attribut hinzufügst. Der Wert des Attributs sollte ein Ganzzahlwert sein, der die Höhe in Pixeln angibt. Du kannst maximal 960 Pixel für die Höhe festlegen.

Du kannst ein Titelbild hinzufügen, indem du im Header ein <figure>-Tag einbindest. Du kannst entweder ein Bild oder ein Video als Titelbild verwenden. Fügen einfach ein <img>- oder <video>-Tag im figure-Element hinzu.

Weitere Informationen zu Titelbildern findest du hier.

Um einen Abstand zwischen Bildern hinzuzufügen, kannst du zwischen den Bildern leere Absätze hinzufügen, z. B. mit <p>&nbsp;</p>.

Du kannst eine Attribution hinzufügen, indem du ein <cite>-Element im <figcaption>-Element verwendest.

Für Titelbilder kannst du festlegen, dass die Attribution immer sichtbar sein soll, indem du im <cite>-Element explizit eines der Attribute für die vertikale Ausrichtung festlegst. Ansonsten wird die Zitierung nicht auf dem Bild angezeigt, bis es erweitert wird.

Du kannst sozialen Content einbetten, indem du ein figure-Element mit der Klasse „op-social“ und einen iframe hinzufügst, der den einzubettenden Content enthält.

Weitere Details und Codebeispiele findest du in diesem Dokument.

Du musst einen direkten Link zu einer Videodatei verwenden (z. B. eine mp4-Datei), wenn du ein Titelbild hinzufügen möchtest. Die auf Facebook gehosteten Videos stellen keinen direkten Link zur Verfügung, daher musst du dein Video an anderer Stelle hosten, um es als Titelbild verwenden zu können.

Du kannst einige HTML-Tags für Listenelemente verwenden, beispielsweise Text fett formatieren oder Links hinzufügen. Um die Farbe oder die Schriftart anzupassen, kannst du den Style-Editor auf der Nutzeroberfläche der Facebook-Seite („Einstellungen“ -> „Instant Articles“) verwenden.

Wenn du ein Video mit dem <video>-HTML-Element einbettest, ist dies nicht möglich, da die Wiedergabe mehrerer Videos in einer Sequenz nicht unterstützt wird.

Wenn du einen Videoplayer als soziale Einbettung in einem iframe nutzt, sollte dies möglich sein, sofern diese Funktion vom eingebetteten Player unterstützt wird.

Blockzitate werden nicht unterstützt. Sie müssten außerhalb des Absatz-Tags platziert werden.

Wenn der Titel des Artikels lang genug ist und auf zwei Zeilen verteilt angezeigt wird, ist im News Feed nur der Titel zu sehen. Wenn die Titellänge nur einer Zeile entspricht, wird in der News Feed-Vorschau auch der Anfangstext des Artikels angezeigt.

Stelle sicher, dass du deinen Videos nicht das „data-fb-disable-autoplay“-Attribut hinzugefügt hast.

Wenn die Videos bei einer bestimmten Person nicht automatisch abgespielt werden, überprüfe, ob die automatische Videowiedergabe nicht in den Einstellungen der Facebook-App deaktiviert ist. Eine Anleitung dazu findest du hier.

Du kannst ein Video in der News Feed-Vorschau eines Artikels anzeigen, indem du Videos in deinem Artikel die Klasse „fb-feed-cover“ hinzufügst. Weitere Informationen zur Vorschaufunktion im News Feed findest du hier

Es ist erforderlich, für jeden deiner Artikel ein <time>-Element im HTML-Markup einzubinden (mit der Klasse „op-published“), um das Datum bzw. die Uhrzeit anzugeben, zu dem bzw. zu der der Artikel ursprünglich veröffentlicht wurde.

Die op-modified-Klasse ist nicht erforderlich. Du musst nur ein <time>-Element mit dieser Klasse einbinden, wenn du den Content deines Artikels aktualisierst und möchtest, dass wir die Artikelversion aktualisieren, die wir gespeichert haben.

Stelle sicher, dass dein Text in Absatz-Tags (<p></p>) eingeschlossen ist. Weitere Informationen zum Erstellen des Markups für deinen Artikel findest du hier.

Stelle sicher, dass dein <figure>-Element nicht in Absatz-Tags (<p></p>) eingeschlossen ist. Bilder sollten in figure-Tags enthalten sein, die direkt unter dem article-Tag verschachtelt sind.

Es ist leider nicht möglich, einzelnen Bildern in einer Slideshow Bildunterschriften hinzuzufügen. Du kannst nur eine Bildunterschrift für die gesamte Slideshow hinzufügen.

Weitere Details hierzu findest du in der Dokumentation zu Slideshows.

Du kannst zu allen Bildern „Gefällt mir“-Angaben oder Kommentare hinzufügen, indem du das „data-feedback“-Attribut in dem <figure>-Tag angibst, das das Bild enthält. Durch Hinzufügen des Attributs data-feedback="fb:likes,fb:comments" werden beispielsweise sowohl „Gefällt mir“-Angaben als auch Kommentare für das Bild angezeigt.

Ausführliche Informationen findest du in der Dokumentation zum Feedback-Attribut.

Wenn du die Breite für Elemente definierst, z. B. interaktive Einbettungen, verwende einen Ganzzahlwert, in dem die Breite in Pixeln angegeben ist. Elemente werden standardmäßig in vollständiger Breite angezeigt.

Um eine interaktive Einbettung ohne Ränder anzuzeigen, kannst du dem iframe, der deinen Content enthält, die Klasse „no-margin“ hinzufügen.

Wenn bereits ein RSS-Feed für deine Seite genehmigt wurde, musst du diesen nicht erneut zur Überprüfung einreichen, wenn du die Feed-URL änderst.

Wir ordnen jede Seite einem eindeutigen Domainnamen zu. Die URL des RSS-Feeds selbst muss nicht mit diesem Domainnamen übereinstimmen. Die kanonische URL deiner einzelnen Artikel im Feed muss jedoch zur selben Domain oder Subdomain gehören. Wenn du nur die URL des RSS-Feeds änderst, sollten keine Probleme auftreten.

Wenn du auch die kanonischen URLs der Artikel änderst und diese auf eine neue Domain verweisen, musst du diese Domain-Aktualisierung über deinen Partner Manager beantragen und solltest dann entsprechende Unterstützung beim Update erhalten.

Vergewissere dich, dass in deiner Facebook-App eine echte iPhone-Store- und iPad-Store-ID festgelegt ist (die IDs werden nur zu Testzwecken verwendet, du musst also nicht deine echte ID angeben, sondern kannst die IDs einer beliebigen, im App Store verfügbaren App verwenden) und dass „iOS – iPad“ bei den im App Center aufgeführten Plattformen aktiviert ist.

Hierbei handelt es sich nicht um einen Fehler. Der Feed-Dialog postet Inhalte bereits mit einem Anhang. Deshalb ist es nicht möglich, weitere Anhänge hinzuzufügen.

Best Practices zur Optimierung deiner Bilder und Vorschauen findest du hier.

Antwortdaten sind nur verfügbar, wenn der Benutzer über Facebook bei deiner App angemeldet ist und die Berechtigung „publish_actions“ erteilt hat. Dieses Verhalten ist hier dokumentiert.

Hierbei handelt es sich um eine absichtliche Änderung. Wir haben die Freundesliste gekürzt, damit Spieleanfragen für entsprechende Spieler relevanter sind. Spieler können jedoch weiterhin beliebig viele Freunde auswählen, wenn sie das Suchfeld verwenden.

Und die gute Nachricht ist, dass die Anzahl der Klicks sowie die gesamte CTR seit dieser Änderung gestiegen sind. Wir werden diesen Kanal auch weiterhin optimieren, um dafür zu sorgen, dass Spiele die richtigen Nutzer erreichen.

Der Crawler sucht nach einem AAAA-Datensatz und gibt einen Antwortcode 0 zurück, falls dieser Datensatz nicht gefunden wird. Stelle sicher, dass dein AAAA-Datensatz richtig aktualisiert wird, wenn du deine URL oder den Server änderst.

Weitere Informationen findest du im Abschnitt zum Aktualisieren von URLs.

Das Ändern von og:title, og:image usw. gilt nur für zukünftige Freigaben dieses Links.

Sobald eine Person oder Seite einen Link teilt und mehr als 50 Interaktionen mit dem Beitrag erfolgt sind (Kommentare, „Gefällt mir“-Angaben, geteilte Inhalte usw.), kann der Titel nicht mehr geändert werden. Dies soll verhindern, dass eine Webseite Details eines Links ändert, nachdem du damit interagiert hast und es so aussieht, als ob du mit einem anderem Content interagiert hättest. Alle anderen Eigenschaften können jederzeit geändert werden.

Wenn du einen Link teilst und das Bild aktualisierst, wird die ursprüngliche Freigabe weiterhin zum alten Bild verweisen, bis du es im Beitrag aktualisierst.

1. Öffne den Beitrag in deinem Newsfeed.
2. Klicke oben rechts im Beitrag auf die Punkte.
3. Wähle „Geteilten Anhang aktualisieren“ aus.

Wir frieren Titel nach einer bestimmten Anzahl an Aktionen am Objekt ein (hier beschrieben: Aktualisieren von URLs).

Bei zugeschnittenen Bildern können viele Faktoren eine Rolle spielen. Wir versuchen beispielsweise, das Bild auf Gesichter zu zentrieren, die wir erkennen.

Versuche, bei größeren Bildern so nahe wie möglich an einem Seitenverhältnis von 1,91:1 zu bleiben, um das ganze Bild im Feed anzuzeigen, ohne dass Teile abgeschnitten werden.

Bei Seitenbeiträgen wird immer ein großes Bild im Querformat für geteilte Links verwendet. Beim Feed für Desktop-PCs und Mobilgeräte besteht dabei kein Unterschied. Versuche, so nahe wie möglich an einem Seitenverhältnis von 1.91:1 zu bleiben, um das ganze Bild im Feed anzuzeigen, ohne dass Teile abgeschnitten werden.

Dein Link wurde eventuell von unserem Inhaltsfiltersystem markiert. Wenn du denkst, dass hier ein Fehler vorliegt, schicke uns bitte einen Bericht über die Hilfe-Seite. Vergiss dabei nicht, die relevante URL beizufügen.

Bilder werden asynchron gespeichert, sodass das Bild beim ersten Teilen des Inhalts durch den Nutzer möglicherweise nicht gerendert wird. Dies wird durch folgende Vorgehensweisen vermieden:

• Vorspeichern deines Bildes durch Auslösen einer Auslesung mit dem Sharing Debugger
• Verwenden der og:image:height- und og:image:width-Tags zum expliziten Kennzeichnen des Bildes

Alle geteilten Inhalte sind an eine bestimmte URL gebunden (diese wird als kanonische URL bezeichnet). Wenn du die Webseitenstruktur änderst und neue URLs nutzt, erfolgt die Zuordnung der geteilten Inhalte und „Gefällt mir“-Angaben zu dieser neuen URL.

Weitere Informationen findest du im Abschnitt zum Aktualisieren von URLs.

Alle geteilten Inhalte sind an eine bestimmte URL gebunden (diese wird als kanonische URL bezeichnet). Wenn du die Webseitenstruktur änderst und neue URLs nutzt, erfolgt die Zuordnung der geteilten Inhalte und „Gefällt mir“-Angaben zu dieser neuen URL.

Weitere Informationen findest du im Abschnitt zum Aktualisieren von URLs.

Bilder, die kleiner als 600 x 315 Pixel, aber größer als 200 x 200 Pixel sind, werden als kleines, quadratisches Bild angezeigt.

Alle Bild-URLs sind für uns unveränderbar, da diese für das Laden der Ressourcen auf verschiedenen Ebenen verwendet werden. Wenn du also ein Bild ersetzen musst, musst du dafür auch eine neue URL verwenden. Nach einer Weile rufen wir das neue Bild dann ab und das Problem löst sich von selbst.

Wenn du eine neue URL verwendest, aber immer noch das alte Bild siehst, kannst du die URL auch über den Sharing Debugger auslesen.

Alle URLs müssen absolut sein, da sie den kanonischen Standort einer Ressource (Seite/Bild) darstellen, damit wir geteilte Inhalte und „Gefällt mir“-Angaben der richtigen URL zuordnen und Bilder richtig laden können.

Das Originalbild ist nicht mehr verfügbar oder zu groß oder konnte aufgrund eines temporären Problems nicht abgerufen werden. Stelle sicher, dass unser Crawler Zugriff auf die Bild-URL hat, dass das Bild nicht größer als 8 MB ist und dass es mit wenigen Sekunden Latenz ausgeliefert werden kann.

Wenn du „og:image“ für eine Seite änderst, musst du sicherstellen, dass du das alte Bild nicht von deiner Webseite entfernst, da für zuvor geteilte Inhalte ein weißes Feld angezeigt wird.

Das liegt an einer Replikationsverzögerung in unseren Rechenzentren. Es dauert mehrere Sekunden, bis der Prozess abgeschlossen ist, und die Objekt-ID ist erst nach Abschluss verfügbar.

Wenn du versuchst, die Details einer Werbeanzeige zu lesen, bevor sie vollständig gespeichert wurde, erhältst du möglicherweise eine GraphMethodException mit einer Fehlermeldung wie der folgenden: Unsupported get request. Object with ID 'XXXXXXXXXXXXXXXXXX' does not exist, cannot be loaded due to missing permissions, or does not support this operation..

Warte einen Moment, bevor du die Details der Werbeanzeige abrufst, um das Problem zu beheben.

Manchmal kommt es beim Versuch, eine bestimmte Werbeanzeige innerhalb einer bestimmten Kampagne zu verwenden, zu einem Validierungsfehler. Das kann passieren, wenn die Kampagne über ein Ziel verfügt, das nicht mit der verwendeten Werbeanzeige kompatibel ist. Das wäre beispielsweise der Fall, wenn deine Werbeanzeige auf ein Canvas-Spiel verweist, während das Kampagnenziel jedoch „MOBILE_APP_INSTALLS“ lautet.

Um alle Validierungsfehler zu beseitigen, kannst du die Best Practices zur Marketing API-Validierung nutzen.

Überprüfe, ob bei den Upload-Sitzungen, die die entsprechenden Elemente nicht enthalten, keine Fehler aufgetreten sind.

Wenn „deletion_enabled“ auf „true“ festgelegt ist, werden nur Elemente gelöscht, die nicht mehr im Feed einer erfolgreichen Upload-Sitzung vorhanden sind.

Wenn dieser Fehler auftritt, überprüfe den Status des angegebenen Werbekontos. Der Fehler wird oft zurückgegeben, wenn das Werbekonto einen ungewissen Status aufweist.

Dieses Verhalten wird erwartet, da die Backend-Daten für Seitenstatistiken nur zwei Jahre lang gespeichert werden. Deshalb ist es kein Fehler, dass der Aufruf Nullwerte zurückgibt. Die einzigen Elemente, die keine null zurückgeben, sind inline erstellte „Gefällt mir“-Angaben, Kommentare und geteilte Inhalte von Beiträgen, deren Daten im Beitrag selbst gespeichert sind.

Überprüfe die Syntax der Targeting-Spezifikation und achte dabei besonders darauf, dass die Spezifikation über gültige „geo_locations“-Parameter und -Werte verfügt.

Wenn du eine Werbeanzeige mit bestimmten Zielen erstellst, werden die standardmäßigen Conversion-Spezifikationen festgelegt. Wenn du die Conversion-Spezifikationen änderst, werden die vorhandenen Einstellungen überschrieben.

Beachte hierbei auch, dass bestimmte Ziele nicht über standardmäßige Conversion-Spezifikationen verfügen und manuell konfiguriert werden müssen.

Das kann daran liegen, dass die „work_positions“-Zielgruppe für das Land, das du ansprechen möchtest, so klein ist, dass sie sich nicht auf die geschätzte Reichweite auswirkt. Wir sammeln weiterhin Daten, mit denen wir die Anzahl der Personen in der „work_positions“-Ausschlussgruppe mit der Zeit erhöhen werden. Wenn sie groß genug ist, wird sie auch die geschätzte Reichweite beeinflussen.

Das liegt daran, dass für deine App die Stream-Post-URL-Sicherheit-Migration aktiviert ist.

Wenn für deine App die entsprechende Einstellung festgelegt ist, erlaubt das System nicht die Erstellung irgendeiner Art von Link Post Ads, sofern diese nicht zur in den App-Einstellungen hinterlegten Canvas-URL führen. Die Aktivierung dieser Funktion sollte nur erforderlich sein, wenn es sich bei deiner App um eine Canvas-App handelt, die nur Meldungen veröffentlicht, die zurück zur Canvas-App-Domain führen.

Der Nutzer ist wahrscheinlich über eine Business Manager-Verknüpfung mit dem Konto verbunden, die nicht als explizite Graph API-Verknüpfung angezeigt wird.

Vergewissere dich, dass du die Partnerkategorien im richtigen Targeting-Feld angegeben hast. Partnerkategorien, die vom „/partnercategories“-Endpunkt abgerufen werden, enthalten ein Feld namens „targeting_type“. Es verweist auf das Targeting-Feld, das du bei der Angabe des Targeting-Typs verwenden musst.

Wenn deine Partnerkategorie beispielsweise den „targeting_type“ von „behaviours“ zurückgibt, musst du bei der Targeting-Angabe die Partnerkategorie im „behaviour“-Feld deiner Targeting-Angabe verwenden.

Weitere Informationen zu Targeting-Typen und Partnerkategorien findest du hier: https://developers.facebook.com/docs/marketing-api/partnercategories/v2.3#targeting_types.

Dieser Fehler tritt auf, wenn für eine Custom Audience keine Aus-/Einschlüsse festgelegt sind. Am besten behebst du dieses Problem, indem du eine neue Custom Audience erstellst und dabei Aus- und Einschlüsse angibst.

Weitere Informationen zu Custom Audiences findest du hier: https://developers.facebook.com/docs/marketing-api/custom-audience-targeting/v2.3.

Eine Anzeigengruppe kann sowohl über ein „daily_budget“ als auch ein „lifetime_budget“ verfügen. Der in der Währung deines Kontos definierte „daily_budget“-Wert muss mindestens 100 Cent betragen und die Dauer muss länger als 24 Stunden sein. Wenn du eines dieser Felder abfragst, werden beide zurückgegeben. Wenn ein Feld nicht verwendet wird, wird 0 zurückgegeben.

Weitere Informationen hierzu findest du unter: https://developers.facebook.com/docs/reference/ads-api/adset.

Der „adcampaign_groups“-Endpunkt verwendet Cursor-basierte Paginierung. Deshalb gibt er die Felder „count“, „limit“ und „offset“ nicht zurück. Du solltest die Cursor-basierte Paginierung für alle Endpunkte verwenden, um einheitliche Ergebnisse zu erzielen.

Weitere Informationen zur Verwendung Cursor-basierter Paginierung findest du hier: https://developers.facebook.com/docs/graph-api/using-graph-api/v2.0#paging.

Das kann daran liegen, dass manche Beiträge inline erstellt wurden. Informationen zum Abrufen dieser Inline-Beiträge findest du im Hinweis zum „is_inline“-Feld von /promotable_posts unten in der folgenden Dokumentation: https://developers.facebook.com/docs/reference/ads-api/adcreative/v2.2#object_story_spec

Solange der*die Nutzer*in die erste Frage beantwortet, ist das Messaging-Fenster offen. Wenn die angegebenen Antworten den*die Nutzer*in disqualifizieren oder der*die Nutzer*in nicht antwortet, wird das Werbeerlebnis beendet und die Anzeige übergibt die Threadsteuerung an die Ziel-App. Dabei übermittelt sie die Metadaten „messenger_lead_gen_incomplete“, um dem Unternehmen eine Fallback-Lösung zu bieten, bei der unvollständige/disqualifizierte Leads in Kund*innen umgewandelt werden. Unter HOP-Webhook nach Lead Ad findest du weitere Informationen.

Nur wenn eine App ausgewählt wird, ist die Option zum Senden einer zusammenfassenden Nachricht standardmäßig innerhalb der Anzeige im Dialog „Vorlage erstellen“ aktiviert. Die zusammenfassende Nachricht kann für die Anzeige deaktiviert werden, sobald die verknüpfte App ausgewählt wurde. Auch wenn keine App ausgewählt wurde, überträgt die Lead Generation Ad die Threadsteuerung an den primären Empfänger der Übergabe, sofern dieser festgelegt wurde. Andernfalls wird die Threadsteuerung nur freigegeben. Mögliche Follow-up-Nachrichten nach Übermittlung der Leads werden an die abonnierten Apps gesendet. Apps können die Conversation API abfragen, um den Nachrichtenverlauf abzurufen und die Informationen zu erhalten, die während des Prozesses zur Leadgenerierung geteilt wurden.

Die Send API und Webhooks werden standardmäßig blockiert, während eine Lead Generation Ad verwendet wird. App-ID: 413038776280800 für die App zur Leadgenerierung für Messenger übernimmt die Threadsteuerung. Dieses Verhalten kann innerhalb der Anzeige im Dialog „Vorlage erstellen“ über den Schalter „Send API blockieren“ deaktiviert werden.

Nach dem Ende der Leadübermittlung erhalten Apps Webhooks bei Nutzer*innen-Nachrichten und können diese beantworten. Wenn eine bestimmte App als Teil der Anwendung ausgewählt wurde, kann nur die festgelegte App antworten und Webhooks über den Messaging-Kanal erhalten. Das Messaging-Fenster ist geöffnet und die App kann mithilfe der Send API antworten.

Apps können von der App-Website mithilfe des Facebook Login installiert werden und indem einer bestimmten Seite die Berechtigung „pages_messaging“ erteilt wird. Zugelassene Apps werden in den Seiteneinstellungen unter Erweitertes Messaging angezeigt.

Es werden nur zugelassene Apps für die entsprechende Seite angezeigt. Du kannst die zugelassenen Apps in den Seiteneinstellungen unter Erweitertes Messaging sehen. Apps können von der App-Website mithilfe des Facebook Login installiert werden und indem einer bestimmten Seite die Berechtigung „pages_messaging“ erteilt wird.

Automatisierte Chat-Lösungen (d. h. Bots) sollten ihre Kommunikationspartner zu den folgenden Zeitpunkten über ihr Wesen aufklären:

• zu Beginn jeder Unterhaltung bzw. an Anfang jedes Kommunikations-Threads
• nach einem längeren Zeitraum
• wenn ein Chat von einer Interaktion mit einem Menschen zu einer automatisierten Interaktion wechselt

Weitere Informationen zu dieser Richtlinie findest du hier.

Wenn geltendes Recht eine entsprechende Informationspflicht vorsieht, müssen Bots die Personen, mit denen sie interagieren, darüber aufklären, dass sie mit einem automatisierten Service kommunizieren. Auch ohne gesetzliche Verpflichtung ist die Information der Nutzer eine gute Praxis, um Überraschungen zu vermeiden. Weitere Informationen zu dieser Richtlinie findest du hier.

Ja, eine Facebook-App kann mehrere Seiten abonnieren. Nachdem sie zur App-Überprüfung eingereicht wurde, wie die Berechtigung pages_messaging, kann die App den Erhalt von Webhooks auf mehreren Seiten abonnieren. Es obliegt dir, den Kontext jedes Webhooks anhand des Payloads abzurufen.

Ja, es können auch mehrere Apps eine Seite abonnieren. Wenn mehrere Apps mit derselben Unterhaltung arbeiten, sollte am besten mit dem Übergabeprotokoll verwaltet werden, welcher Bot jeweils gerade die Threadsteuerung übernimmt.

Hier ist eine Problemumgehung zur Verwendung eines Plattform-Testnutzers für deine Messenger-Plattform-Integration:

1. Erstelle über die Seite „Rollen“ in deiner App einen neuen Testnutzer, indem du auf den „Hinzufügen“-Button klickst.
2. Schalte die Option „Testnutzer für diese App autorisieren?“ um und erteile die Berechtigungen "manage_pages" und "page_messaging".
3. Nutze den „Bearbeiten“-Button und rufe einen Zugriffsschlüssel für diesen Nutzer ab (mit v2.6). Speichere diesen für die spätere Verwendung.
4. Melde dich über den „Bearbeiten“-Button als Testnutzer an.
5. Erstelle nach der Anmeldung eine Seite als Testnutzer.
6. Verwende den Nutzer-Zugriffsschlüssel für den Testnutzer, um den Seiten-Zugriffsschlüssel für diesen Nutzer abzurufen. Verwende dazu den folgenden Aufruf:

   https://graph.facebook.com/v2.6/me/accounts?access_token=[TEST_USER_ACCESS_TOKEN]

   (Dokumentation)
7. Nutze diesen Seiten-Zugriffsschlüssel, um deine Facebook-App mit deiner Seite zu verknüpfen:

   https://graph.facebook.com/v2.6/me/subscribed_apps?method=POST&access_token=[TEST_USER_PAGE_ACCESS_TOKEN]
           

   (Dokumentation)
8. Wenn du diese Schritte ausgeführt hast, erhältst du RTU-Updates auf deiner Testseite. Damit kannst du nun von deiner Testseite Nachrichten an deinen Testnutzer senden. Zusätzlich zu diesen Schritten kannst du deinen Zugriffsschlüssel mit einem langlebigen Schlüssel ersetzen, falls der Zugriffsschlüssel für deine Tests zu schnell abläuft. Beachte hierzu die folgende Dokumentation:

   GET /oauth/access_token?  
       grant_type=fb_exchange_token&           
       client_id={app-id}&
       client_secret={app-secret}&
       fb_exchange_token={short-lived-token} 
           

Dafür gibt es verschiedene Gründe:

• Du verwendest eine ID von Facebook Login. Nutzer-IDs von Facebook Login können nicht in Verbindung mit der Send/Receive API verwendet werden. Es können auf der Messenger-Plattform nur Nutzer-IDs verwendet werden, die durch eine entsprechende Authentifizierung mit der Plattform bereitgestellt wurden.
• Du nutzt eine ID mit fehlerhaftem Seiten-Zugriffsschlüssel. Nutzer-IDs für die Messenger-Plattform sind seitenspezifisch, d. h. auf eine bestimmte Seite bezogen. Wenn du eine gültige Nutzer-ID verwendest, der Seiten-Zugriffsschlüssel jedoch einer anderen Seite zugewiesen ist, kann der Aufruf nicht funktionieren. Achte darauf, eine Nutzer-ID und einen Seiten-Zugriffsschlüssel zu verwenden, die beide derselben Seite zugewiesen sind.
• Du sendest die Nachricht an eine Telefonnummer, die noch nicht bestätigt wurde. Wenn du die Send API mit einer Telefonnummer verwendest, werden Nachrichten nur gesendet, wenn die Telefonnummer kürzlich bestätigt wurde. Selbst wenn für die Telefonnummer angegeben ist, dass sie bestätigt ist, schlägt der Senden-Vorgang fehl, wenn keine kürzliche Bestätigung erfolgt ist. Bestätige deine Telefonnummer erneut, warte 24 Stunden und versuche es dann erneut.

Wenn du das Plugin „An Messenger senden“ verwendest, kann der data-ref-Parameter als Passthrough-Parameter genutzt werden, um Informationen zum Klick-Kontext zu übermitteln.

Personen entdecken deine Seite möglicherweise bei der Suche in Messenger. In diesen Fällen ist kein Passthrough-Parameter verfügbar. Du kannst die Kontoverknüpfungsfunktion verwenden, um einen Thread mit einem Nutzerkonto auf deiner Seite zu verknüpfen.

Im App-Dashboard befindet sich unter den Messenger-Einstellungen ein Button zur Anzeige der aktuellen Fehler. Hier kannst du sehen, ob Webhooks Antwort 200 erhalten oder einen Fehler verursachen.

Es gibt ein Tool zur Anzeige aktueller Webhook-Fehler. Wenn Webhooks nicht zugestellt werden, heben die Facebook-Server das Abonnement deiner URL-Adresse auf. So rufst du das Tool auf: Klicke im App-Dashboard auf „Messenger > Einstellungen“ und dann auf der Webhooks-Karte auf den Button Aktuelle Fehler anzeigen.

Stelle sicher, dass dein Webhook immer den Statuscode 200 zurückgibt. Dies ist für uns die Information, dass der Webhook erfolgreich empfangen wurde. Wenn keine Statuscode-200-Antwort zurückgegeben wird, wird der Aufruf wiederholt, bis er erfolgreich ist. Wenn ein Webhook für einen längeren Zeitraum keine 200-Antwort zurückgibt, werden die Entwickler-Benachrichtigungen angezeigt.

Beachte, dass eine erfolgreiche Statuscode-Antwort zeitnah zurückgegeben wird. Nach 20 Sekunden erfolgt beim Webhook-Aufruf eine Zeitüberschreitung. Achte bei der Entwicklung deines Codes darauf, dass Webhooks asynchron verarbeitet werden, damit eine erfolgreiche Statuscode-Antwort umgehend zurückgegeben werden kann und die Verarbeitung separat erfolgt.

Webhook-Aufrufe enthalten in der Überschrift ein Feld mit dem Namen X-Hub-Signature. Damit kann validiert werden, dass die Anfrage von Facebook stammt.

Um einen Rückruf zu erhalten, musst du zwei Schritte ausführen. Stelle zunächst sicher, dass dein Webhook korrekt eingerichtet ist (https://developers.facebook.com/docs/messenger-platform/webhook-reference#setup). Dort findest du Informationen, wann Webhooks korrekt eingerichtet sind.

Zweitens musst du die einzelnen Seiten abonnieren. Alle abonnierten Seiten werden aufgelistet.

Wenn Aufrufe für deinen Webhook für eine längere Zeitdauer fehlschlagen, wird das Abonnement deiner App aufgehoben und du musst deinen Webhook erneut hinzufügen und die Seite erneut abonnieren.

Der Inhalt muss wahrscheinlich erneut abgerufen werden. Das passiert nach einem bestimmten Zeitraum automatisch. Du kannst es mit dem Debug-Tool aber auch manuell auslösen.

Abseits der OG-Tags für deine Seite kannst du nicht steuern, ob ein Beitrag im News Feed oder in der Chronik angezeigt wird, wenn du eine Open Graph-Meldung teilst. Facebook optimiert die Beiträge automatisch, um die maximale Interaktion für deinen Inhalt zu gewährleisten.

Das ist richtig: Handlungs-Links stehen nicht mehr zur Verfügung. Handlungs-Links werden auf Facebook nicht länger unterstützt, weshalb sie von der gesamten Plattform entfernt wurden. Dieses Feature wird künftig vielleicht wieder eingeführt, jedoch nicht im Rahmen der aktuellen Roadmap.

Wenn deine Webseite unsere Open Graph-Meta-Tags verwendet und einen „og:image“-Eintrag enthält, rufen wir dieses Bild ab und verwenden es in der Vorschau. Wenn deine Webseite „og:image“, „og:image:width“ und „og:image:height“ angibt, wird diese Bild verwendet – selbst für den ersten geteilten Beitrag.

Wenn du diese Werte nicht angibst, musst du warten, bis unsere Crawler die Bilder abgerufen und analysiert haben. Ein Beispiel hierfür findest du unter http://ogp.me/#structured.

Hierbei handelt es sich nicht um einen Fehler. Die REST API ist seit geraumer Zeit veraltet und funktioniert daher nicht mehr ordnungsgemäß. Darüber hinaus gilt eine Einschränkung: Seitenzugriffsschlüssel können nicht mit der REST API verwendet werden.

Mit dem „locale“-Parameter des JavaScript-SDK kannst du eine Ländereinstellung für den „Gefällt mir“-Button festlegen. Das funktioniert bei nicht angemeldeten Nutzern. Wenn ein Nutzer angemeldet ist, wird die Spracheinstellung berücksichtigt. Wenn hier eine bestimmte Sprache festgelegt ist, wird der „Gefällt mir“-Button in dieser Sprache angezeigt.

Du kannst dieses Verhalten testen, indem du die Seite besuchst, ohne bei Facebook angemeldet zu sein (oder indem du in deinem Browser eine private Sitzung verwendest).

Es verstößt gegen die Facebook-Richtlinien, das Textfeld beim Teilen auf Facebook auszufüllen. App-Nutzer müssen den Text, den sie teilen möchten, selbst eingeben.

Das Vorausfüllen des Textfelds beim Teilen verstößt gegen Plattform-Richtlinie 2.3 ( https://developers.facebook.com/policy/#control ). Wir setzen diese Richtlinie durch, um zu verhindern, dass Nutzer versehentlich Inhalte teilen, die nicht in ihrem Sinne sind.

Das passiert, wenn du die URL einer Webseite änderst. Jede URL, die das Kommentar-Plugin enthält, wird als separates Open Graph-Objekt behandelt und die Kommentare werden mit diesem Objekt verknüpft. Wenn du die URL änderst, wird dementsprechend ein neues Objekt erstellt, wodurch die vorhandenen Kommentare möglicherweise nicht auf der Seite angezeigt werden.

Nein, das Posten von Kommentaren in einem Kommentar-Plugin mithilfe der API ist nicht gestattet.

Das Plugin erlaubt nicht die Übergabe benutzerdefinierter Parameter, sondern ruft die Meta-Daten direkt aus den Open Graph-Meta-Tags der Seite ab.

Weitere Informationen zu den Best Practices beim Teilen von Inhalten findest du in folgender Dokumentation: https://developers.facebook.com/docs/sharing/best-practices

Yes, Whatsapp Flows can be sent with On-Premises API. You can learn more about Whatsapp Flows here, or learn how to get started with Whatsapp Flows and On-Premises API here.

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.

No, currently we do not support changing the default path to media storage (/usr/local/wamedia/). All media storage needs to be at this default location in order to work properly.

Nein, derzeit müssen wir AWS EFS verwenden, um das Medienvolume zwischen Coreapp und Webapp zu teilen.

No, we don't support KOPS. We do support the AWS solution based on ECS. We also have a general Kubernetes minikube setup.

Die Coreapp prüft die Verzeichnisse /usr/local/waent/data und /usr/local/waent/log im Coreapp-Container und stellt sicher, dass mindestens 10 MB Speicherplatz verfügbar sind. Andernfalls wird dieser kritische Fehler angezeigt.

Prüfe deine Protokolle und dein Datenverzeichnis, um sicherzustellen, dass ausreichend Platz vorhanden ist.

No. There's currently no way to run multiple numbers in the same WhatsApp Business API client setup. We are working on a proper solution that will allow this in the future.

Verwende den services-API-Endpunkt der Datenbankbereinigung, um Nachrichten und dazugehörigen Nachrichtenbelege aus der messageStore.messages- und der messageStore.messages_receipt_log-Tabelle zu löschen.

Überprüfen Sie Ihre pass_through-App-Einstellung. Du erhältst keine Lesestatus-Rückrufe, wenn du pass_through mit dem WhatsApp Business API-Client v2.29.1 oder höher aktiviert hast.

Wenn du den Lesestatus-Rückruf erhalten möchtest, deaktiviere die pass_through-App-Einstellung. Beachte, dass dein Datenbankspeicher durch die Deaktivierung von pass_through schnell wachsen könnte. Weitere Informationen zum Datenbankmanagement findest du in der Dokumentation zum Datenbankmanagement.

Mit der Datenbankbereinigung werden die messages- und die messages_reciept_log-Tabellen regelmäßig bereinigt, um die Datenbankverwaltung zu vereinfachen.

Bei der Datenbankbereinigung werden bestimmte Nachrichten gespeichert, um eine erfolgreiche Auslieferung/Verarbeitung zu ermöglichen. So wird beispielsweise eine eingehende Nachricht für einen bestimmten Zeitraum gespeichert, damit sie von Business-Integrationen als „Gelesen“ markiert werden kann.

Die Coreapp führt in zufälligen Intervallen Bereinigungen durch (z. B. alle paar Stunden) Damit soll ein möglicher Leistungsabfall bei Hochverfügbarkeits-Stacks aufgrund von Datenbankkonflikten vermieden werden.

Die Bereinigung erfolgt unabhängig von der Rückruf-Warteschlange. Ist der Webhook-Server beispielsweise vier Tage lang nicht verfügbar, werden die Rückrufe gespeichert, damit sie nach der Wiederherstellung der Konnektivität des Webhook-Servers ausgeliefert werden können.

Ein Links wird nur dann als klickbar angezeigt, wenn der Empfänger deine Unternehmensnummer bereits als Kontakt gespeichert hat oder wenn du über einen offiziellen Unternehmens-Account verfügst.

Vor v2.29.x konnte die Warteschlange aufgrund eines Bugs für ausgehende Nachrichten im Laufe der Zeit immer länger werden. Mit dem Upgrade auf v2.29.3 wird dieses Problem behoben.

Du bist dafür verantwortlich, dass basierend auf dem erwarteten Standort und der Sprache von Benutzern der entsprechende QR-Code verwendet wird.

QR-Codes können nun direkt in der WhatsApp Business Management API generiert und verwaltet werden. Benutzer können diese dann mit ihrer WhatsApp-, iOS- oder Android-Kamera scannen.

Außerdem gilt für WhatsApp QR-Codes

• Vorausgefüllte Nachrichten können vollständig angepasst und jederzeit geändert oder gelöscht werden.
• Benutzer navigieren immer direkt zur App, ohne eine Interstitial-Seite aufzurufen.
• Das App-interne Erlebnis für einen abgelaufenen Code sendet eine leere Nachricht an den Benutzer.

Wenn ein Benutzer versucht, auf einen QR-Code oder einen Kurzlink zuzugreifen, der bereits gelöscht wurde, erscheint eine Fehlermeldung mit dem Hinweis, dass der QR-Code/Kurzlink nicht mehr gültig ist.

Wenn der Benutzer den WhatsApp-Desktop-Client installiert hat, wird eine Unterhaltung mit deinem Unternehmen gestartet. Hat der Benutzer den Client nicht installiert, wird er aufgefordert, dies zu tun.

Mit den neuen Kurzlinks können mit einem Link verknüpfte automatisch ausgefüllte Nachrichten jederzeit bearbeitet oder gelöscht werden. Außerdem reduzieren sie die Syntax der URL auf einen zufälligen Code. Das bedeutet, dass keine Nachrichten mehr in die URL eingebettet werden müssen und die Telefonnummer verdeckt wird.

Wir empfehlen das .svg-Dateiformat für die beste Qualität in Druckmaterialien.

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).

v2.25.x weist gegenüber früheren Versionen eine bessere Ausgangs- und Eingangsleistung auf. Diese Optimierung basiert auf der Herstellung zusätzlicher Datenbankverbindungen. Bei einigen Implementierungen kann dies zu einer höheren Anzahl an Datenbankverbindungen und damit zu Einschränkungen bei Datenbankverbindungen führen. Um die erhöhte Leistung aufrechtzuerhalten, kannst du die maximale Anzahl an Verbindungen für deinen Datenbankserver erhöhen. Wenn das nicht möglich ist, kannst du den Parameter „axolotl_context_striping_disabled“ ändern, um dieses Verhalten zu deaktivieren. Weitere Informationen dazu findest du in unserer Dokumentation zu Anwendungseinstellungen.

Wenn du oder dein Endkunde ein offizielles WhatsApp-Unternehmenskonto anfordern möchte, findest du die entsprechenden Anweisungen im Dokumentationsabschnitt Anfordern eines offiziellen Unternehmenskontos.

Nein. Derzeit gelten Messaging-Einschränkungen nur für von Unternehmen initiierte Nachrichten (Benachrichtigungen).

Wenn du ein Bild als Album über die WhatsApp Business API senden möchtest, musst du mindestens 4 Bilder nacheinander senden. Wenn die Unterhaltungsansicht des Nutzers beim Empfangen der Bilder aktiv ist, ist die Album-Ansicht erst beim nächsten Aufruf verfügbar.

In folgenden Fällen wird kein Album erstellt:

1. Bilder mit Bildunterschriften
2. Ungelesen-Trennlinie: Nutzer sieht einige, aber nicht alle Bilder
3. Datumsheader: neuer Tag zwischen Zustellungen

Nein. Derzeit kann der WhatsApp Business API-Client nicht auf Docker für Windows ausgeführt werden. Für Entwicklungsanforderungen wird die Ausführung von Docker auf einem virtuellen Linux-Gerät empfohlen. Für Produktions-Workloads empfehlen wir einen Linux-Server, um Kompatibilitäts- und Leistungsprobleme zu vermeiden.

Für WhatsApp Business API-Clients mit v2.21.6: Wenn der Client vom Server getrennt wird, kann er mehrere Minuten (maximal 4 Minuten) getrennt bleiben und dann erneut versuchen, eine Verbindung herzustellen. Durch ein Upgrade auf v2.23.4 ist der Ausfall eines Clients beim Verbindungsversuch mit dem Server kürzer.

Der Fehlercode 471 betrifft Ratenbegrenzungen auf Qualitätsbasis. Weitere Informationen findest du in der Dokumentation zu Ratenbegrenzungen auf Qualitätsbasis.

Alle Unternehmen beginnen mit der niedrigsten Ebene und werden automatisch hochgestuft, wenn sie mehr qualitativ hochwertige Nachrichten senden.

Ja, beim Senden einer Nachrichtenvorlage erhältst du den Status-Rückruf „fehlgeschlagen“ mit der Meldung „Struktur nicht verfügbar“ im Fehlerobjekt, wenn die Nachricht beim Empfänger nicht angezeigt werden konnte. Je nach Empfänger ist denkbar, dass du den Statusrückruf „ausgeliefert“ erhältst. Das bedeutet einfach, dass die Nachricht an den Empfänger ausgeliefert wurde, der Empfänger sie jedoch nicht anzeigen konnte.

Es folgen Validierungsfehler beim Senden von Nachrichtenvorlagen und mögliche Gründe dafür, dass sie angezeigt werden.

• „No message templates exist in language your-language“ oder „No message templates exist in language your-language and locale your-locale“: Das angegebene Sprachpaket ist nicht vorhanden. Prüfe dein Business Manager-Konto.
• „Template your-template-name does not exist in language your-language“ oder „Template your-template-name does not exist in language your-language and locale your-locale“: Du versuchst, eine Vorlage zu verwenden, die nicht vorhanden ist (nicht erstellt wurde oder noch nicht genehmigt wurde). Wenn du versuchst, eine Nachricht mit einer Vorlage zu senden, die gelöscht wurde, wird dir auch dieser Fehler angezeigt.
• „Number of localizable_params num1 does not match the expected number of params num2“: Du versuchst, eine Nachrichtenvorlage mit Parametern zu senden, die nicht mit der Anzahl der erwarteten Parameter übereinstimmen. Prüfe bitte, ob der API-Aufruf korrekt ist.
• „dein-Vorlagenname is a rich template and requires the template message API to be used“: Du versuchst, eine Mediennachrichtenvorlage als Standard-Nachrichtenvorlage zu senden. Stelle sicher, dass der Nachrichtentyp template ist. Weitere Informationen dazu findest du in der Dokumentation zu Mediennachrichtenvorlagen.
• Nachdem Vorlagen im Business Manager genehmigt (oder gelöscht) wurden, kann es bis zu 20 Minuten dauern, bis der WhatsApp Business API-Client die aktualisierten Vorlagen erhält. Wenn du versuchst, eine Nachricht mit einer Vorlage zu senden, die gerade genehmigt wurde, und du die Fehlermeldung erhältst, dass die Vorlage nicht existiert, kannst du versuchen, die Nachricht erneut zu senden, nachdem du die oben angegebene Zeit abgewartet hast.

Doppelte Nachrichten können als die einzige Garantie an einen WhatsApp Webhook gesendet werden, sofern Nachrichten mindestens einmal empfangen werden (anstatt genau einmal). Wenn dies Auswirkungen darauf hat, wie Nachrichten auf deiner Seite verarbeitet werden, schlagen wir vor, Webhook-Nachrichten basierend auf der Nachrichten-ID zu deduplizieren.

Wenn diese Telefonnummer noch nicht in WhatsApp Business API verwendet wurde, kannst du diese Telefonnummer verwenden. Befolge die hier beschriebenen Migrationsschritte, um diese Telefonnummer erneut zu verwenden.

Ab Version v2.18.26 erlaubt der Endpunkt für Anwendungsstatistiken das Exportieren interner Kennzahlen im Prometheus-Textformat. Weitere Informationen findest du in der Dokumentation zur Instanzenüberwachung.

Ein leeres profile-Objekt wird zurückgegeben, wenn das Business-Profil nur teilweise ausgefüllt wurde. Führe ein Upgrade auf v2.21.4, um dieses Problem zu beheben.

Weitere Informationen zum Ausfüllen des Business-Profils findest in der Dokumentation Unternehmensprofil-Einstellungen.

Wenn du bei der Einrichtung deiner AWS-Bereitstellung einen Fehler wie den folgenden erhältst, solltest du versuchen, zu einem Stacknamen zu wechseln, der 8 Zeichen oder weniger verwendet.

Country Name (2 letter code) [AU]:State or Province Name (full name) [Some-State]:Locality Name (eg, city) []:Organization Name (eg, company) [Internet Widgits Pty Ltd]:Organizational Unit Name (eg, section) []:Common Name (e.g. server FQDN or YOUR name) []:string is too long, it needs to be less than 64 bytes long Common Name (e.g. server FQDN or YOUR name) []:Email Address []:error, no objects specified in config file problems making Certificate Request Created device key for internal-wa-inc-name-LB-123456789.ap-southeast-1.elb.amazonaws.com

Die zulässige Anzahl der Parameter in einer Nachrichtenvorlage ist unbegrenzt.

Pro WhatsApp-Unternehmenskonto sind maximal 250 Nachrichtenvorlagen erlaubt.

Wenn ein Webhook-Event aus beliebigem Grund nicht ausgeliefert wird (z. B. weil der Client offline ist) oder die Webhook-Anfrage einen anderen HTTP-Statuscode als 200 zurückgibt, wiederholen wir die Webhook-Auslieferung. Die Auslieferung wird in immer größeren Intervallen bis zu einer bestimmten Zeitüberschreitung (in der Regel 24 Stunden, kann jedoch variieren) oder bis zur erfolgreichen Auslieferung erneut versucht.

Es kann sein, dass du mehr Zeit benötigst, um eine Kundenanfrage zu bearbeiten, und du daher erst später als nach 24 Stunden antworten kannst. Wir empfehlen, Nachrichtenvorlagen zu erstellen, um:

• das Ergebnis an den Nutzer auszuliefern oder
• den Nutzer zu einer Antwort aufzufordern, damit das Kundenservice-Fenster aktiviert wird.

In beiden Fällen solltest du der Nachrichtenvorlage möglichst viel Kontext hinzufügen. Beispiel:

• „Hallo {{1}}, hinsichtlich des kürzlich gemeldeten Problems müssen wir dir leider mitteilen, dass {{2}}. Wir entschuldigen uns für etwaige Unannehmlichkeiten.“
• „Es gibt Neuigkeiten zu deinem Ticket. Bitte antworte auf diese Nachricht, wenn du weiterhin Support wünschst.“

WhatsApp führt Experimente durch, um die Auswirkungen von WhatsApp Business-API-Benachrichtigungen auf die Nutzererfahrung und das Produkt im Allgemeinen zu messen und um genauere Einblicke zu erlangen. Wenn der Nutzer, dem du eine Nachricht senden möchtest, an einem dieser Experimente teilnimmt, erhält er unter Umständen keine Benachrichtigungen von dir, selbst wenn dies eigentlich so eingestellt ist.

Wenn du das aktuelle Setup sicherst und es auf dem neuen Gerät wiederherstellst, sollten die Registrierungsinformationen mit dem Rest deiner Implementierung übernommen werden. Weitere Informationen findest in der Dokumentation Einstellungen zur Sicherung und Wiederherstellung.

Ja, die Protokollrotation erfolgt bei Webapp-Containern und Coreapp-Containern geringfügig anders:

• Webapp: Die letzten 30 Protokolldateien werden beibehalten. Die Protokolldatei wird nur rotiert, wenn die Datei größer als 20 MB ist.
• Coreapp: Die letzten 30 Protokolldateien werden beibehalten. Die Protokolldatei wird nur rotiert, wenn die Datei größer als 15 MB ist. Rotierte Dateien werden komprimiert.

Wende dich bitte mit allen Informationen, die dir zur Verfügung stehen, an den Support. Wir untersuchen den Sachverhalt und schalten falsche Nummern ab.

Alle Builds des WhatsApp Business API-Client laufen sechs Monate nach dem Veröffentlichungsdatum ab. Wenn du diesen Fehler erhältst, aktualisiere schnellstmöglich auf die neueste Version.

Vor dem Senden einer Nachricht musst du zunächst prüfen, ob der Kontakt existiert. Weitere Informationen dazu findest du in unserer Dokumentation zu Kontakten.

Die Ursache für diesen Fehler ist, dass Coreapp noch nicht initialisiert ist. Das bedeutet, dass die Registrierung möglicherweise nicht erfolgreich abgeschlossen wurde. Versuche bitte, die Registrierung abzuschließen, bevor du einen Aufruf an einen anderen Endpunkt durchführst. Der erste Schritt nach der Installation von WhatsApp Business API ist die Anmeldung. Der zweite Schritt ist die Registrierung. Diese beiden Schritte sind erforderlich, bevor du Anfragen an andere Endpunkte stellen kannst.

Hinweis: Die fallback-Sprachrichtlinie ist ab v2.27.8 veraltet und die deterministic-Sprachrichtlinie ist nun die Standardrichtlinie.

Wenn du eine Übersetzung in einer neuen Sprache erstellst, musst du alle Elemente übersetzen, die du verwendest. Andernfalls erhältst du den Fehler „Struktur nicht verfügbar“, denn das Telefon des Empfängers kann ein Element nicht finden, das es für die jeweilige Sprache erwartet. Diese „Struktur nicht verfügbar“-Fehler treten beim Senden von Nachrichtenvorlagen mithilfe der Fallback-Richtlinie auf.

Wenn das Erstellen von Übersetzungen derzeit für dich nicht in Frage kommt, kannst du diese Fehler mit der deterministischen Richtlinie vermeiden.

Ein Nachrichten-Payload von einem Nutzer kann eine Text- oder Mediendatei sein.

Von Textdateien gehen unserer Einschätzung nach keine Gefahren aus.

Für Mediendateien gilt Folgendes:

• Normalerweise wird davon ausgegangen, dass Unternehmen Schutzsoftware (d. h. Antivirensoftware, Software gegen Schadprogramme etc.) einsetzen, um mögliche Bedrohungen zu analysieren.
• WhatsApp kann den Inhalt einer zu übertragenden Datei nicht identifizieren oder überprüfen, da sie End-to-End-verschlüsselt ist (dasselbe gilt auch für reine Textinhalte).
• Es gibt eine Option, um zu verhindern, dass Mediendateien im WhatsApp Business API-Client automatisch heruntergeladen werden. Wenn das Unternehmen von Benutzern keine Dateien erhalten möchte, kann das auto_download-Feld auf einen leeren Bereich festgelegt werden.

Nein, es gibt keine Möglichkeit, mithilfe der WhatsApp Business API mehrere Geräte mit der gleichen Nummer zu erkennen.

„structure unavailable“-Fehler treten auf, wenn die Vorlagennachricht vom Telefon nicht gelesen werden kann.

Vorlagen werden auf dem Server gespeichert. Wenn eine Nachrichtenvorlage mit dem messages -Nodegesendet wird, werden nur Namespace, Sprache, Elementname und lokalisierte Parameter an das Telefon gesendet, aber nicht die gesamte Nachricht. Sobald diese Werte an das Telefon ausgeliefert wurden, versucht es, die Nachricht zu rendern.

Wenn beim Rendern Fehler auftreten, wird der Fehler structure unavailable an die Rückruf-URL gesendet, zusammen mit der Empfänger- und der Nachrichten-ID. Diese Fehler können durch einen falschen Namespace, Unstimmigkeiten bei lokalisierten Parametern, einen falschen Elementnamen usw. bedingt sein.

Navigiere in deinem Facebook Business Manager zum WhatsApp Manager, um die richtige Anzahl der Parameter zu ermitteln. Vergewissere dich, dass der Namespace richtig ist und der Elementname existiert.

Wenn nicht für alle verwendeten Vorlagen Übersetzungen erstellt wurden, ist dies eine häufige Fehlerquelle. Beispiel: Wenn du in der Regel zwei Vorlagen sendest und für eine der Vorlagen eine neue Übersetzung hinzufügst, musst du die neue Übersetzung auch für die andere Vorlage hinzufügen. Wenn Support für mehrere Sprachen angeboten werden soll, müssen für alle Vorlagen Übersetzungen für alle unterstützten Sprachen bereitgestellt werden.

Die gute Nachricht: structure unavailable -Fehler sind normalerweise auf Fehler im messages -API-Aufruf zurückzuführen und können behoben werden, indem die Send-Payload geändert wird.

In deinem WhatsApp-Konto im Facebook Business Manager kannst du neue Telefonnummern registrieren und alte löschen.

1. Rufe in deinem WhatsApp-Konto Einstellungen aus.
2. Klicke auf WhatsApp Manager.
3. Wähle den Tab Telefonnummern. Hier kannst du sämtliche Telefonnummern für dieses Konto verwalten.

Bei Bildern wird die Bildunterschrift als Beschreibung hinzugefügt. Der Bildtext wird bei Bildern auf Android und iPhone in voller Länge angezeigt.

Bei Dokumenten wird der Dateiname durch die Bildunterschrift ersetzt. Die Bildunterschrift sollte nicht als Beschreibungstext auf dem Gerät des Nutzers angezeigt werden, sondern sie soll den Namen der Datei anzeigen. Auf iPhones wird der vollständige Text angezeigt. Auf Android-Telefonen wird der Dateiname dagegen abgekürzt. Dies ist eine technische Einschränkung der aktuellen Implementierung von WhatsApp auf beiden Geräten.

Wenn die Registrierung mit „SMS“ aufgrund zu vieler Versuche fehlschlägt und dir die Meldung „Zugriff verweigert“ angezeigt wird, versuche bitte, die Registrierung per Sprachanruf durchzuführen.

Die Dauer beträgt derzeit 7 Tage. Wenn ein Zwischenspeicher länger als 7 Tage nicht aktualisiert wurde, wird das letzte Sprachpaket vom Server abgerufen, unabhängig davon, ob das Element bereits im Paket vorhanden ist oder nicht.

Das Gerät lädt zuerst aus dem Cache. Wenn ein Element vorhanden ist, wird die Nachricht mithilfe der zugehörigen Nachrichtenvorlage entpackt. Daher ist es sinnvoller, einfach eine neue Nachrichtenvorlage mit einem anderen Elementnamen hinzuzufügen, als eine Nachrichtenvorlage zu ändern. So ist gewährleistet, dass das Sprachpaket erneut heruntergeladen wird, wenn dieses Element nicht gefunden werden kann. Die Speicherkosten für Nachrichtenvorlagen sind vernachlässigbar. Daher ist es nicht unbedingt notwendig, Nachrichtenvorlagen zu löschen.

Weitere Informationen findest du unter Senden von Nachrichtenvorlagen – Sprache.

Um ein qualitativ hochwertiges Erlebnis für Unternehmen und Nutzer sicherzustellen, bieten wir derzeit eine öffentliche Vorschau mit eingeschränkten Funktionen. Wenn du mit uns zusammenarbeiten möchtest, sende uns weitere Informationen, um uns dein Unternehmen vorzustellen, während wir unsere Verfügbarkeit weiter ausbauen. Du kannst dich auch an deinen Ansprechpartner für Facebook wenden, wenn du bereits einen hast.

Wenn ein Nutzer über den users-Endpunkt abgemeldet wird, werden alle Authentifizierungsschlüssel, die diesem Konto zugewiesen sind, ungültig gemacht. Das Löschen eines Benutzers hat den gleichen Effekt, allerdings ist dieser Schritt viel drastischer. Bedenke, dass ein neuer Authentifizierungsschlüssel zurückgegeben wird, wenn ein Nutzer über den users-Endpunkt angemeldet wird. Authentifizierungsschlüssel, die für diesen Nutzer bereits im Umlauf sind, werden dadurch aber nicht ungültig gemacht. Jeder, der im Besitz eines zuvor ausgestellten Schlüssels ist, kann ihn nutzen, bis er abläuft oder durch eine der oben genannten Methoden ungültig gemacht wird.

Wenn du diesen Fehler erhältst, aber der fehlende obligatorische Parameter, auf den sich der Fehler bezieht, im JSON-Body eingerichtet ist, könnte es sich um einen JSON-Parsing-Fehler handeln. Dieser Fehler kann auftreten, wenn die gesamte JSON-Payload aufgrund von JSON-Formatierungsfehlern nicht geparst werden kann. Prüfe die Werte dieser Parameter auf ungültige JSON-Zeichen, beispielsweise einen Zeilenumbruch am Ende. Denkbar ist auch, dass Parameter mit zusätzlichen Leerzeichen hineinkopiert wurden, die JSON beschädigen.

Hierfür kann es diverse Gründe geben. Möglicherweise ist die Coreapp nicht verfügbar oder deine Datenbank wurde nicht ordnungsgemäß eingerichtet. Ist dies nicht der Fall, sieh dir die Coreapp-Protokolle an (bzw. die Master-Coreapp-Protokolle, wenn du Multiconnect verwendest). Bei Fehlern wegen der Datenbankverbindung verfügt die Datenbank wahrscheinlich nicht über genügend Verbindungen. Mehr zu diesem Fehler findest du im MySQL-Dokument oder im PostgreSQL-Dokument.

Wir empfehlen, die Anzahl der Datenbankverbindungen für deine Datenbank zu heraufzusetzen. Mit 1.000 Datenbankverbindungen bist du auf der sicheren Seite, doch du solltest selbst eine fundierte Entscheidung hinsichtlich der Anzahl der Verbindungen treffen. Wenn der Fehler weiterhin besteht, dann öffne ein Support-Ticket.

Reasons a message template might be rejected include:

• Sie enthält potenziell missbräuchliche Inhalte wie missbräuchliche Sprache oder spamähnliche Inhalte.
• Sie enthält Werbeinhalte.
• Sie entspricht nicht dem ausgewählten Tag-Typ.
• Sie ist falsch formatiert.

Der Fehler „Verbindung abgelehnt“ bedeutet wahrscheinlich, dass die Coreapp nicht aktiv ist. Verwende docker ps, um herauszufinden, ob die Coreapp aktiv ist. Ist dies nicht der Fall, sieh dir die Docker-Protokolle an. Möglicherweise kann die Coreapp keine Verbindung mit der Datenbank herstellen. Vergewissere dich, dass die Datenbank ordnungsgemäß eingerichtet ist.

Dies geschieht, wenn die Docker-Bridge beschädigt ist. Um dieses Problem zu beheben, solltest du den Docker-Dienst am besten beenden und neu starten. Du kannst bei deinen Containern auch docker restart ausprobieren.

Von WhatsApp wird streng überprüft, ob eine angegebene Nummer tatsächlich zu einem Telefon gehört. Die Tatsache, dass ein Nutzer ein WhatsApp-Konto hat, ist ein Beweis dafür, dass er die Nummer bestätigt hat und niemand sonst diese Nummer verwendet hat, um sich später bei WhatsApp zu registrieren. Dies ist jedoch keine Garantie für den physischen Standort der SIM-Karte.

Andererseits kann ein Nutzer bei Verlust oder Diebstahl seines Telefons sein WhatsApp-Konto deaktivieren. Weitere Informationen dazu, wie Nutzer ihr Konto deaktivieren können, findest du unter Telefon verloren oder gestohlen – FAQ.

Wenn die Telefonnummer eines Kunden nicht mehr aktiv ist, der Kunde aber WhatsApp weiterhin verwendet, hat der Kunde weiterhin Zugang zu WhatsApp, bis/wenn die Telefonnummer neu zugewiesen oder registriert wird.

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.

Dieser Fehler tritt auch, wenn die Datenbank nicht richtig eingerichtet wurde.

• Achte darauf, entweder MySQL 5.7 oder höher oder PostgreSQL 9.5.x, 9.6.x, 10.x zu verwenden.
• Dein Datenbankpasswort sollte keines der folgenden Zeichen enthalten: ?{}&~!()^.
• Wenn du AWS verwendest, achte darauf, dass dein Stack einen kurzen Namen hat. Weitere Informationen findest du in der Dokumentation zur Installation.

Ja, die TCP-Verbindung ist erforderlich. Wenn dein Unternehmen keine zusätzlichen Ports öffnen kann, kannst du Terminated SSL verwenden.

Weitere Informationen findest du in der Dokumentation zu Netzwerkanforderungen.

Hierbei handelt es sich um ein bekanntes Problem. Manchmal ist bei einem Upgrade des WhatsApp Business API-Client mit den CloudFormation-Skripts auch ein Update des RDS-DB-Stacks erforderlich. Der neue RDS-Stack hat nicht den gleichen Hostnamen wie der ursprüngliche Stack und die Docker-Container können keine Verbindung zur Datenbank herstellen. Die Lösung besteht darin, sich per SSK mit der EC2-Instanz zu verbinden, die von CloudFormation erstellt wurde, die Datei whatsapp.conf mit dem neuen Hostnamen zu aktualisieren und dann die Docker-Container neu zu starten, damit sie die neuen Einstellungen übernehmen.

Ja, du solltest einen API-Aufruf an den contacts-Node senden, bevor du eine Nachricht sendest. Die Informationen zur Prüfung von contacts werden im Container zwischengespeichert und wenn dies nicht geschieht, kann dies zum Fehler Unkown Contact führen. Weitere Informationen findest du in der Dokumentation Kontakte prüfen.

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.

Wenn ein Webhook einen Rückruf nicht senden kann, wird der Rückruf in eine Warteschlange für Wiederholungsversuche gestellt. Rückrufe, die nach dem Fehlschlagen des ursprünglichen Rückrufs gesendet werden, werden nicht empfangen. Die restlichen Rückrufe werden erst empfangen, wenn der ursprünglich fehlgeschlagene Rückruf erfolgreich war.

Der WhatsApp Business API-Client sendet die Webhook-Rückrufe über den Coreapp-Container an dich. Daher muss dein Webhook-Endpunkt so konfiguriert sein, dass er eingehende Anfragen von der Coreapp akzeptiert.

Du solltest eine zweite Telefonnummer registrieren und einen zweiten CloudFormation-Stack oder eine zweite Docker-Instanz zum Testen hochfahren. Wenn du zwei aktive WhatsApp Business API-Clients mit derselben Telefonnummer hast, wirst du vom Server abgemeldet, weil ein Konflikt zwischen den Verschlüsselungsschlüsseln auftritt. Wir empfehlen, eine zweite Umgebung zu haben, mit der du deine Nicht-Produktionsinstanz testen kannst, bevor du eine Migration auf deinem Produktionsmandanten durchführst.

MySQL 5.7.x, PostgreSQL 9.5.x, 9.6.x, 10.x sind erforderlich. Mit einer älteren Version erhältst du den Fehler Unable to initialize config store.

Wenn du eine Nachricht sendest und eine Nachrichten-ID erhältst, bedeutet das, dass die Nachrichtenanforderung in der Datenbank gespeichert wurde. Der WhatsApp Business API-Client versucht weiterhin, diese Nachricht zu senden, bis der Vorgang vom WhatsApp-Server bestätigt wird. Dieser Prozess ist nicht zeitlich begrenzt. Der WhatsApp-Server versucht dann, diese Nachricht an das Telefon des Nutzers zu übermitteln. Wenn das Telefon des Benutzers nicht online ist, wird die Nachricht 30 Tage lang gespeichert, bevor sie vom WhatsApp-Server entfernt wird.

In den Datenbanktabellen werden Informationen zu App-Einstellungen, Chat-Threads, Nachrichten, Medien usw. gespeichert, die alle für den Betrieb der App erforderlich sind.

Dein Unternehmen wird nicht benachrichtigt, wenn ein Kunde seine WhatsApp-Telefonnummer ändert. Wenn du den contacts-Node verwendest, lautet der Status für diese Nummer invalid.

Nein, du kannst nur ein Konto pro Instanz ausführen. Wenn du ein zweites Testkonto benötigst, verwende für diese zweite Instanz eine andere Nummer.

Eine Systemdiagnose ist kostenlos und kann so oft wie nötig durchgeführt werden.

In der Dokumentation zu Statistiken findest du weitere Informationen zu den Statistiken zu Anwendungen und Datenbanken, die du abrufen kannst. Anwendungsstatistiken werden im Arbeitsspeicher abgelegt und die Abfrage erfordert wenig Ressourcen. Das Abrufen von Datenbankstatistiken ist ressourcenintensiver und sollte nur bei Bedarf erfolgen.

Bei Verwendung des messages-Node musst du den Content-Type-Header auf application/json festlegen, damit der Nachrichtentext von WhatsApp Business API-Client richtig geparst wird. Es gibt auch einen Authorization-Header, der festgelegt werden und einen nicht abgelaufenen Zugriffsschlüssel enthalten muss. Informationen dazu, wie du den Zugriffsschlüssel abrufen kannst und wann er abläuft, findest du in der Dokumentation zu Anmeldung und Authentifizierung

Es kann sein, dass sich das System verlangsamt, wenn der Speicherplatz knapp wird. Die Ursache kann eine hohe Anzahl von Mediendateien, Nachrichten und großen Protokolldateien sein. Protokolldateien werden automatisch rotiert. Wenn sie groß werden, sollten sie aber zur Sicherheit trotzdem gelöscht werden.

Nachrichten werden in der Datenbank gespeichert. Du kannst Nachrichten bei Bedarf löschen. Wenn der pass_through in den Anwendungseinstellungen auf „false“ festgelegt ist, werden außerdem alle Nachrichten in der Datenbank gespeichert, bis sie explizit gelöscht werden.

Mediendateien, die Nutzer an dich senden, werden in die Medienvolumes heruntergeladen. Es ist Sache des Unternehmens, zu entscheiden, welche Mediendateien gelöscht werden sollen, aber es ist generell ratsam, alle Mediendateien zu löschen. Du kannst anhand von docker inspect your-container-id prüfen, wo sich der Ordner mit den Medienvolumes befindet.

Befolge diesen Leitfaden zu Docker MySQL, um MySQL lokal unter Verwendung von Docker einzurichten.

Befolge diesen Leitfaden zu Docker PostgreSQL, um PostgreSQL lokal unter Verwendung von Docker einzurichten.

In den meisten Fällen solltest du die Datenbank auf einem physischen Server ausführen, der von den Core- und Web-Containern getrennt ist. Die Latenzzeit zwischen dem Datenbankserver und anderen Rechnern sollte nur wenige Millisekunden betragen.

Es liegt an dir zu entscheiden, wann Medien gelöscht werden.

Nach dem Hochladen von Medien erhältst du eine Medien-ID, mit der du eine Nachricht senden kannst, die das hochgeladene Medienelement enthält. Beim Senden der Mediennachricht verschlüsselt die WhatsApp Business API die Medien und lädt sie auf die WhatsApp-Server hoch, wo sie 14 Tage lang verbleiben. Danach kannst du entscheiden, ob du die Medien unter Angabe der Medien-ID löschen oder für die spätere Verwendung aufbewahren möchtest. Wir empfehlen zwar, die Medien 30 Tage lang aufzubewahren, aber es liegt an dir, die Aufbewahrungsrichtlinie entsprechend den Richtlinien deines Unternehmens oder dem Anwendungsfall festzulegen.

Ja, die Datenbank kann auf andere Weise verwendet werden, ohne dass dies Auswirkungen auf die mit WhatsApp zusammenhängenden Tabellen hat.

Prüfe zunächst die Rückrufe auf kritische Fehler, um das Problem zu diagnostizieren.

Wenn du die Fehlermeldung „Konflikt: Mehrere Instanzen mit derselben Nummer erkannt“ erhältst, musst du deine Container prüfen. Die wahrscheinlichste Ursache ist, dass mehrere Docker-Container versuchen, über dasselbe WhatsApp-Konto eine Verbindung zu den WhatsApp-Servern herzustellen. Vergewissere dich, dass nur ein Container aktiv ist. Wenn du alte Container hast, deaktiviere sie. Der Fehler wird dadurch behoben.

Wenn du unsere komplexeren Hochverfügbarkeitslösungen testen möchtest, nutze die Dokumentation Hochverfügbarkeit.

Eine Whitelist kann mit Hostnamen oder IP-Adressen erstellt werden.

Weitere Informationen findest du im Abschnitt Hostnamen der Dokumentation mit Netzwerkanforderungen.

Ja. Mit WhatsApp kannst du ausgewählten Text in deinen Nachrichten mit Fett, Kursiv, Durchgestrichen und Monospace formatieren.

Yes, message templates support all WhatsApp messaging characters and formatting including emojis, bolding, italics, etc. Bei Emojis musst du das Emoji-Zeichen (Kopieren/Einfügen) verwenden und nicht den entsprechenden Unicode.

Gebührenfreie Nummern sind erlaubt, solange die Landesvorwahl enthalten ist. Der Grund dafür ist, dass gebührenfreie Nummern ohne Landesvorwahl nicht eindeutig identifiziert werden können, sodass die gleiche Nummer für zwei verschiedene Länder gelten kann.

Außerdem ist zu beachten, dass mit den gebührenfreien Nummern zusätzliche Schwierigkeiten verbunden sind. In der Regel schlägt der Anruf einer gebührenfreien Nummer mit der Landesvorwahl fehl, wenn sich der Anrufer innerhalb des Landes befindet. Es kann also sein, dass deine Kunden aus deinem Land versuchen, die im Geschäftskontakt angezeigte Nummer (einschließlich der Landesvorwahl) zu wählen, und sie dich nicht erreichen können. Wenn dies ein Problem darstellt, musst du es ihnen explizit mitteilen.

Hier erfährst du mehr über gebührenfreie Nummern.

NEIN! Mit einer bestimmten Telefonnummer kann immer nur eine Instanz des WhatsApp Business API-Client ausgeführt werden. Sobald du eine zweite Instanz registrierst, wird die erste Instanz abgemeldet und schlägt fehl. Wir arbeiten an einer Lösung, mit der dies möglich ist. Neuigkeiten dazu wirst du zeitnah erfahren.

WhatsApp betrachtet Kommunikation mit Business API-Benutzern, die den API-Endpunkt auf von ihnen kontrollierten Servern verwalten, als vollständig verschlüsselt, da kein Drittanbieter-Zugriff auf Inhalte zwischen Endpunkten besteht.

Einige Organisationen entscheiden sich evtl., die Verwaltung ihres WhatsApp Business API-Endpunkts an einen Drittanbieter von Unternehmenslösungen zu delegieren. In diesen Fällen verwendet die Kommunikation weiterhin dieselbe Signal-Protokollverschlüsselung. Da der WhatsApp Business API-Benutzer jedoch einen Drittanbieter für die Verwaltung des Endpunkts gewählt hat, betrachtet WhatsApp diese Nachrichten nicht als vollständig verschlüsselt. In der Zukunft, also ab 2021, gilt dies auch für Unternehmen, die die cloudbasierte Version der API von Facebook nutzen.

Wenn du bei Aufrufen an den WhatsApp Business API-Client HTTPS verwendest, werden diese Daten darüber hinaus mit SSL verschlüsselt (vom deinem Backend-Client zum WhatsApp Business API-Client).

Weitere Informationen findest du im technischen Whitepaper mit einem Überblick über die Verschlüsselung bei WhatsApp.

Diese Meldung wird durch einen Fehler in einer alten Version des iOS-Client verursacht. Wir gehen davon aus, dass diese Fehlermeldungen im Laufe der Zeit abnehmen, wenn die Allgemeinheit Upgrades vornimmt.

Nein. Es wird nicht garantiert, dass Nachrichten in der Reihenfolge ankommen, in der sie gesendet wurden. Wenn die richtige Reihenfolge für deinen Anwendungsfall wichtig ist, schlagen wir vor, den „Zugestellt“-Rückruf abzuwarten, bevor du die zweite Nachricht sendest.

Es gibt ein Skript, das extern ausgelöst werden kann, um alte Protokolle eines Containers zu bereinigen.

docker exec CONTAINER_NAME /opt/whatsapp/bin/cleanup.sh

Das Skript kann sowohl mit Webapp- als auch mit Coreapp-Containern verwendet werden. Durch die Ausführung des Skripts werden alte Protokolldateien entfernt und es bleiben nur noch 30 Protokolldateien des Containers übrig.

Hinweis: Bitte sende eine Nachricht nicht mehrmals über die WhatsApp Business API an denselben*dieselbe Empfänger*in.

Es kann mehrere Ursachen haben, wenn die Auslieferungsrate nicht 100 % beträgt. Beispielsweise kann es sein, dass Benutzer*innen nur sporadisch Zugriff auf das Netzwerk haben, für einen längeren Zeitraum nicht aktiv sind oder dass ein hochwertiges Nutzungserlebnis gewährleistet werden soll.

Nachrichten, die mit WhatsApp ausgeliefert werden können, haben eine sehr hohe Auslieferungsrate. Es gibt jedoch viele Gründe, warum eine Nachricht nicht ausgeliefert wird. Durch Verfolgen deiner Rückrufe hast du Zugriff auf den genauen Status einer Nachricht. Darin liegt beispielsweise der Unterschied zum Senden von Nachrichten per SMS, wo du keinen Zugriff auf den endgültigen Auslieferungsstatus hast und durch erneutes Senden der Nachricht möglicherweise tatsächlich ein anderes Ergebnis entsteht.

Nachrichten gelten womöglich weiterhin als „nicht ausgeliefert“, weil das Telefon eines*einer Benutzer*in außer Betrieb ist, der Akku leer ist oder der*die Benutzer*in es verloren hat, sich daraufhin ein neues Telefon gekauft und die SIM-Karte deaktiviert hat. Denkbar ist auch, dass der Unternehmenskunde beim Herstellen der Verbindung mit dem Netzwerk Fehlermeldungen erhalten hat. Es ist außerdem möglich, dass Rückrufe (Webhooks) nicht ausgeliefert werden. Diese Fälle kannst du mit dem Node health überwachen. Durch Aktivieren von Server-Empfangsrückrufen hast du die Gewissheit, dass die Nachricht in der WhatsApp-Server-Cloud angekommen ist.

Wenn ein*e Benutzer*in erneut eine Verbindung mit dem Netzwerk herstellt, werden alle von dir gesendeten Nachrichten ausgeliefert. Bei dem*der Benutzer*in kommt es nicht gut an, wenn er mehrere Nachrichten mit demselben Inhalt erhält. Die Wahrscheinlichkeit steigt, dass der*die Benutzer*in dich blockiert oder sich über dich beschwert. Auch eine Sperrung wird wahrscheinlicher.

Wenn du eine Nachricht sendest und von der API eine Nachrichten-ID erhältst, hast du alles Nötige getan, um diese Nachricht zu senden. Du solltest denselben Inhalt nicht erneut an denselben Empfänger senden.

Wenn die Auslieferungsrate über einen längeren Zeitraum niedrig ist, öffne ein Support-Ticket beim Direct Support.

Der WhatsApp Business On-Premises API-Client erfordert eine Datenbank zum Speichern von Schlüsseln, die für die Entschlüsselung von zwischen einem Unternehmen und Kunden gesendeten Nachrichten verwendet werden. Alle Nachrichten auf WhatsApp werden mit Sender- und Empfängerschlüsseln verschlüsselt. Kundenschlüssel werden auf dem Mobilgerät des Kunden gespeichert und Unternehmensschlüssel in der Datenbank des Unternehmens. Hier erfährst du mehr über die Sicherheit bei WhatsApp.

Die WhatsApp Business Cloud API stellt eine Alternative dar, bei der Meta die Datenbank eines Unternehmens hostet. Mit der Cloud API kannst du WhatsApp Business APIs implementieren, wobei keine Kosten für das Hosten deiner eigenen Server anfallen. Mehr erfahren.

Nein. Der WhatsApp Business API-Client öffnet eine ausgehende TCP-Verbindung zum Verbindungspunkt 5222 oder 443 auf den WhatsApp-Servern. TCP-Traffic läuft über diese langlebige Verbindung. Von Firewalls wird dieser normalerweise als „ausgehender Traffic und der etablierte Traffic“ klassifiziert. Natürlich werden Pakete übertragen, sobald die Verbindung hergestellt ist, aber der Verbindungsstart erfolgt über den WhatsApp Business API-Client, sodass keine Regel für eingehende Verbindungen erforderlich ist.

MySQL und PostgreSQL werden unterstützt. Wenn du Docker selbst ausführst, musst du eine MySQL-/PostgreSQL-Datenbank angeben, mit der die Container eine Verbindung herstellen können. Durch Verwendung der AWS-Vorlage wird standardmäßig eine MySQL-Datenbank eingerichtet.

Die Anforderungen hängen von deiner Auslastung und Situation ab. Die Lösung kann auf jedem mit dem Internet verbundenen Gerät ausgeführt werden, auf dem Docker läuft. Auf einem Laptop können beispielsweise ganz einfache Tests durchgeführt werden.

Für einen Produktionsserver mit einer Instanz empfehlen wir mindestens 250 GB SSD, 16 GB RAM und Quad-Core-CPU. HDD wird nicht empfohlen, da die I/O-Geschwindigkeiten bei Auslastung zu Engpässen führen.

Für einen Multiconnect-Produktionsserver empfehlen wir mindestens 50 GB SSD, 4 GB RAM und Dual-Core-CPU für jeden Coreapp-/Master-/Webapp-Container.

In den meisten Fällen solltest du die Datenbank auf einem physischen Server ausführen, der von den Core- und Web-Containern getrennt ist. Die Latenzzeit zwischen dem Datenbankserver und anderen Rechnern sollte nur wenige Millisekunden betragen.

Diese Konfiguration unterstützt das Senden von etwa 20 Nachrichten pro Sekunde.

Auf jeden Fall! Sende diese Anforderung an deinen WhatsApp-Vertreter.

Dies ist derzeit nicht möglich. Wenn du nicht in der Lage bist, eingehende Antworten deiner Nutzer über WhatsApp zu verarbeiten, empfehlen wir, eine Nachricht mit automatischer Antwort zu senden, um sie an deine richtigen Supportkanäle weiterzuleiten.

In der Consumer-Variante ist dies das Standardverhalten, wenn sich der Absender nicht in deinem Adressbuch befindet und du bislang noch keine Nachricht an diesen Absender gesendet hast. In der Enterprise-Variante sollte ein Unternehmen Nachrichtenvorlagen verwenden, wenn es zum ersten Mal Kontakt zu einem Nutzer aufnimmt, um „Vertrauen“ herzustellen. Dadurch kann der WhatsApp Business API-Client dann den Link rendern und dafür sorgen, dass er klickbar ist.

In der Consumer-Variante ist dies das Standardverhalten, wenn sich der Absender nicht in deinem Adressbuch befindet und du bislang noch keine Nachricht an diesen Absender gesendet hast. In der Enterprise-Variante sollte ein Unternehmen Nachrichtenvorlagen verwenden, wenn es zum ersten Mal Kontakt zu einem Nutzer aufnimmt, um „Vertrauen“ herzustellen. Dadurch befolgt der WhatsApp Business API-Client dann die Einstellung für den automatischen Download in der App.

Du musst leider eine andere Telefonnummer wählen, die SMS oder Sprachanrufe empfangen kann, damit wir den Registrierungscode senden können. In der Vergangenheit haben wir manuelle Registrierungscodes erlaubt, aber diese werden nicht mehr unterstützt. Telefonnummern, für die zuvor manuelle Registrierungscodes verwendet wurden, werden bei Bedarf weiterhin unterstützt. Bei neuen Telefonnummern übermitteln wir Registrierungscodes nur per SMS oder Sprachanruf.

Wenn du deine 1800-Nummer oder gebührenfreie Nummer verwenden möchtest, lies bitte diesen Leitfaden.

Es gibt derzeit keine Möglichkeit zu sehen, wie viele oder welche Benutzer dein Unternehmen blockieren. Eine gute Möglichkeit, dies herauszufinden, ist, auf Status-Rückrufe zu warten. Wenn du den Status delivered nicht erhältst, hat der Nutzer dein Unternehmen entweder blockiert oder er hat keine Verbindung zum Netzwerk. Weitere Informationen findest du in der Dokumentation zu Webhooks.

Wenn ein Nutzer dein Unternehmen gesperrt hat, wird diese Telefonnummer von der Kontakte-API weiterhin als ein gültiger WhatsApp-Nutzer zurückgegeben. Wenn du die Nachricht sendest, wird sie allerdings niemals zugestellt. Handelt es sich dabei um eine bezahlte Nachricht, fallen keine Kosten an.

Ja, wir können eine neue Telefonnummer einrichten oder den Verified Name ändern, sobald du für die Live-Übertragung bereit bist.

Die maximale Größe für Datei-Uploads beträgt 64 MB. Das heißt, diese Beschränkung gilt auch für Bilder, Dokumente oder Videos, die du mit einer Nachricht sendest.

Nein. Für die WhatsApp Business API-Lösung muss eine zuvor nicht verwendete Nummer genutzt werden.

Um den Bereitstellungspunkt deines Medienvolume zu finden, kannst du einen Docker-Befehl ausführen.

Anfrage

docker volume inspect whatsappMedia

Antwort

[
    {
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "/var/lib/docker/volumes/whatsappMedia/_data",
        "Name": "whatsappMedia",
        "Options": {},
        "Scope": "local"
    }
]

Um alle eingehenden Mediendateien anzuzeigen, kannst du dann den Befehl ls mit dem erhaltenen Mountpoint-Dateipfad ausführen:

ls /var/lib/docker/volumes/whatsappMedia/_data/

In einer AWS-Umgebung wird das Medienvolume auf dem Host unter dem Pfad /mnt/wa/media bereitgestellt.

Es gibt keinen Bereinigungsmechanismus für ausgehende oder eingehende Mediendateien. Du kannst deine Mediendateien manuell löschen, indem du sie in deinem Dateisystem suchst.

Du kannst die Docker-Container neu starten, indem du den folgenden Code ausführst:

Coreapp-Docker-Container

docker restart wacore<Current_WABA_Version>

Webapp-Docker-Container

docker restart webapp<Current_WABA_Version>

Mit

docker ps

kannst du prüfen, welche Version auf deinem Gerät ausgeführt wird.

Ja. Der WhatsApp Business API-Client versucht standardmäßig, mithilfe von chatd über Port 5222 zu kommunizieren. Für optimale Ergebnisse solltest du für den gesamten ausgehenden Traffic den Port 5222 öffnen. Dies stellt kein Sicherheitsrisiko dar, da der Traffic nur ausgehender Traffic von deinem Rechenzentrum ist.

Wenn du den Port 5222 nicht öffnen kannst, versucht der WhatsApp Business API-Client, den Port 443 zu verwenden. Wenn deine Firewall oder dein Proxy immer noch Verbindungen beendet, wende dich bitte an das WhatsApp-Team: Sende zum Debuggen eine Frage über Direct Support.

• 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

• Spieleanfragen von der App an den Nutzer werden über den API-Endpunkt „/apprequests“ gesendet. Sie erstellen die Anfrage im Spieleaktivitäten-Feed, aber keine Benachrichtigung auf der Website. https://developers.facebook.com/docs/graph-api/reference/app-request#Creating
• Spieleanfragen von Nutzer zu Nutzer werden über den Anfragedialog gesendet. Sie erstellen die Anfrage im Spieleaktivitäten-Feed und die Benachrichtigung auf der Website. https://developers.facebook.com/docs/games/services/gamerequests
• Darüber hinaus gibt es auch App-zu-Nutzer-Benachrichtigungen, die über den API-Endpunkt „/notifications“ gesendet werden. Sie erstellen eine Benachrichtigung, aber keine Anfrage im Spieleaktivitäten-Feed. https://developers.facebook.com/docs/games/services/appnotifications