Die AWS Partner Central API-Referenz wurde neu strukturiert. Weitere Informationen zu den unterstützten API-Vorgängen finden Sie in der [AWS Partner Central API-Referenz.](https://docs.aws.amazon.com/partner-central/latest/APIReference/Welcome.html)
Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Mit Leistungsanträgen arbeiten
Ein Leistungsantrag modelliert die Anfrage eines Partners nach einer bestimmten Leistung. Darin werden alle Informationen erfasst, die für die Bewertung und Bearbeitung des Antrags gemäß den leistungsspezifischen Bedingungen erforderlich sind. Der Lebenszyklus des Leistungsantrags durchläuft mehrere Phasen, von der Erstellung des Entwurfs bis zur endgültigen Genehmigung oder Ablehnung.
## Leistungsanträge erstellen
Partner initiieren den Prozess zur Beantragung von Leistungen, indem sie mithilfe der `CreateBenefitApplication` API-Aktion einen Leistungsantrag erstellen. Bei der Erstellung geht der Antrag in den `PENDING_SUBMISSION` Status über, sodass die Partner vollständige Informationen vorbereiten können, bevor sie ihn zur Prüfung einreichen.
Bei der Erstellung eines Leistungsantrags müssen die Partner Folgendes angeben:
+ **Leistungs-ID** — Die ID oder ARN der beantragten Leistung
+ **Erfüllungsarten** — Wie der Partner die Leistung voraussichtlich erhalten wird (`CREDITS``CASH`,,`DISCOUNT`,`ACCESS`,`RECOGNITION`, oder`RESOURCE`)
+ **Einzelheiten des Leistungsantrags** — Ein JSON-Dokument mit leistungsspezifischen Informationen, wie sie im Antragsschema der Leistung definiert sind
+ **Kunden-Token** — Ein einzigartiges Idempotenz-Token, um doppelte Einreichungen zu verhindern
Partner können optional Folgendes bereitstellen:
+ **Name und Beschreibung** — Human-readable Identifikatoren für die Anwendung
+ **Partnerkontakte** — Kontaktinformationen der Person, die diesen Leistungsantrag bearbeitet (maximal 1 Ansprechpartner)
+ **Dateianhänge** — Unterstützende Unterlagen wie Projektpläne, Leistungsbescheinigungen, Kostennachweise oder Umfragen zur Kundenzufriedenheit (maximal 10 Dateien)
+ **Assoziierte Ressourcen** — Links zu verwandten Möglichkeiten oder bestehenden Leistungszuweisungen (maximal 10 Ressourcen)
+ **Stichwörter** — Key-value Paare für die Organisation und Nachverfolgung von Ressourcen (maximal 200 Stichwörter)
Die `CreateBenefitApplication` API führt eine sanfte Validierung durch und überprüft nur grundlegende Feldtypen und Muster. Während der Einreichung erfolgt eine vollständige Validierung der Geschäftslogik, sodass Partner unvollständige Anträge speichern und später zurückkehren können, um sie auszufüllen.
**Bewährtes Verfahren:** Partner sollten das Schema für Leistungsanträge von verwenden`GetBenefit`, um genau zu verstehen, welche Informationen vor der Erstellung eines Antrags erforderlich sind. Dadurch wird die Wahrscheinlichkeit verringert, dass die Einreichung aufgrund fehlender oder ungültiger Daten fehlschlägt.
## Aktualisierung der Leistungsanträge
Partner können Entwürfe von Leistungsanträgen mithilfe der `UpdateBenefitApplication` API-Aktion ändern. Auf diese Weise können Partner Informationen verfeinern, Unterlagen hinzufügen oder Fehler vor der Einreichung korrigieren.
Bei der Aktualisierung eines Leistungsantrags müssen die Partner Folgendes angeben:
+ **Kennung** — Die ID oder ARN des Leistungsantrags, der aktualisiert werden soll
+ **Revision** — Die aktuelle Revisionsnummer für optimistisches Sperren
+ **Einzelheiten zum Antrag auf Leistungen** — Das vollständige, aktualisierte JSON-Dokument
Partner müssen den vollständigen Leistungsantrag einreichen, auch wenn sich nur bestimmte Felder ändern. Es empfiehlt sich, zunächst die neuesten Antragsdetails abzurufen`GetBenefitApplication`, indem Sie die erforderlichen Felder ändern und dann die vollständige aktualisierte Payload an `UpdateBenefitApplication` senden.
**Optimistisches Sperren:** Das Revisionsfeld stellt sicher, dass Aktualisierungen nur angewendet werden, wenn sich die Anwendung seit dem letzten Abruf nicht geändert hat. Wenn die Revision nicht mit dem aktuellen Datenbankwert übereinstimmt, wird das Update mit einem Konfliktfehler abgelehnt. Dadurch wird verhindert, dass Partner versehentlich Änderungen überschreiben, die von anderen Prozessen oder Systemen vorgenommen wurden.
Aktualisierungen können nur durchgeführt werden, solange sich die Anwendung im `PENDING_SUBMISSION` Status befindet. Sobald die Anträge eingereicht wurden, werden sie geprüft und können nicht mehr über diese API aktualisiert werden.
## Ressourcen mit Leistungsanträgen verknüpfen
Partner können mithilfe der `AssociateBenefitApplicationResource` API-Aktion Leistungsanträge mit verwandten Ressourcen verknüpfen. Dadurch entstehen wertvolle Verbindungen zwischen Leistungen und dem Geschäftskontext, in dem sie genutzt werden.
Unterstützte Ressourcentypen sind u. a.:
+ **GESCHÄFTSMÖGLICHKEIT** — Verknüpfen Sie den Antrag auf Leistungen mit einer bestimmten Kundenchance in. Dies ist besonders nützlich bei chancenspezifischen Leistungen wie MAP-Finanzierung oder POC-Gutschriften, die an Kundeninteraktionen gebunden sind.
+ **BENEFIT\_ALLOCATION** — Link zu bestehenden Leistungszuweisungen, sodass Partner Leistungen miteinander verknüpfen oder nachweisen können, wie frühere Leistungen genutzt werden
Eine Zuordnung der Ressourcen kann nur vor der Einreichung erfolgen. Sobald ein Leistungsantrag eingereicht wurde (der Status ändert sich auf`IN_REVIEW`), sind keine weiteren Verknüpfungen mehr zulässig. Partner können jedem Leistungsantrag bis zu 10 Ressourcen zuordnen.
Um die Zuordnung einer Ressource aufzuheben, verwenden Partner die `DisassociateBenefitApplicationResource` API-Aktion. Wie die Zuordnung kann auch die Trennung nur im `PENDING_SUBMISSION` Status erfolgen.
**Wichtig**
Partner müssen über die entsprechenden Berechtigungen verfügen, um sowohl auf den Leistungsantrag zugreifen als auch die spezifische Ressource lesen zu können, der sie zugeordnet sind. Die API validiert diese Berechtigungen während des Zuordnungsvorgangs.
## Einreichung von Leistungsanträgen
Wenn ein Antrag auf Leistungen vollständig und zur AWS Prüfung bereit ist, reichen die Partner ihn über die `SubmitBenefitApplication` API-Aktion ein. Die Einreichung löst einen Statusübergang von `PENDING_SUBMISSION` zu aus `IN_REVIEW` und leitet den leistungsspezifischen Genehmigungsworkflow ein.
Nach der Einreichung führt die API eine umfassende Validierung durch, die Folgendes umfasst:
+ **Überprüfung der erforderlichen Felder** — Stellt sicher, dass alle Pflichtfelder im Leistungsantrag vorhanden sind
+ **Überprüfung des Feldformats** — Überprüft, ob die Feldwerte den erwarteten Mustern und Datentypen entsprechen
+ **Validierung von Geschäftsregeln** — Wendet nutzenspezifische Geschäftslogik und Einschränkungen an
+ **Ressourcenvalidierung** — Bestätigt, dass alle zugehörigen Ressourcen gültig und zugänglich sind
+ **Dateiüberprüfung** — Überprüft, ob die Verarbeitung aller Dateianhänge erfolgreich abgeschlossen wurde
Schlägt die Überprüfung fehl, gibt die API eine ValidationException mit detaillierten Fehlercodes und Meldungen zurück, die angeben, welche Felder korrigiert werden müssen. Partner müssen diese Probleme mithilfe von Internet lösen, `UpdateBenefitApplication` bevor sie erneut versuchen, die Daten einzureichen.
**Anforderung zur Dateiverarbeitung:** Leistungsanträge können nicht eingereicht werden, wenn angehängte Dateien noch im `PENDING` Status sind. Partner müssen warten, bis die Dateiverarbeitung abgeschlossen ist (der Status ändert sich auf`SUCCEEDED`), bevor sie sie einreichen. Wenn Dateien nicht verarbeitet werden können (Status`FAILED`), sollten Partner die korrigierten Versionen hochladen.
Nach erfolgreicher Einreichung:
+ Der Status der Bewerbung ändert sich auf `IN_REVIEW`
+ Das Team des Leistungsempfängers wird über die neue Einreichung informiert
+ Partner können Anwendungsdetails nicht mehr über Standard-Update-APIs ändern
+ Für die Anwendung gilt ein definierter Genehmigungsablauf, der die Phasen der Geschäftsgenehmigung, der technischen Genehmigung und der finanziellen Genehmigung umfassen kann
Partner können den Fortschritt der Einreichung verfolgen, indem sie den Antrag aufrufen und das Feld Phase überwachen, das die aktuelle Genehmigungsphase angibt (z. B. „Geschäftsgenehmigung“, „Technische Genehmigung“, „Finanzielle Genehmigung“).
## Verwaltung der eingereichten Anträge
Nach der Einreichung haben Partner nur begrenzte Möglichkeiten, Leistungsanträge zu verwalten. Die API bietet jedoch spezifische Aktionen für gängige Szenarien.
### Rückruf von Leistungsanträgen
Wenn ein Partner nach der Einreichung einen Fehler entdeckt oder Änderungen vornehmen muss, kann er den Antrag mithilfe der `RecallBenefitApplication` API-Aktion zurückrufen. Durch Rückruf wird der Antrag wieder in den `PENDING_SUBMISSION` Status versetzt, sodass Aktualisierungen und eine erneute Einreichung möglich sind.
Beim Rückruf einer Bewerbung sollten die Partner Folgendes angeben:
+ **Kennung** — Die ID oder ARN des Leistungsantrags, der zurückgerufen werden soll
+ **Grund** — Eine optionale Erklärung für den Rückruf (maximal 1000 Zeichen)
Das Feld „Grund“ ermöglicht eine bessere Rückverfolgbarkeit und hilft dabei, häufig auftretende Probleme zu AWS verstehen, die zu Rückrufen führen, sodass future Verbesserungen des Verfahrens zur Beantragung von Leistungen berücksichtigt werden können.
Nach dem Rückruf können die Partner die erforderlichen `UpdateBenefitApplication` Änderungen vornehmen und sie dann erneut einreichen, wenn sie bereit sind. `SubmitBenefitApplication`
**Wichtig**
Der Rückruf ist in der Regel nur in frühen Überprüfungsphasen möglich. Anträge, die sich in einer späteren Genehmigungsphase befinden oder genehmigt wurden, können möglicherweise nicht zurückgerufen werden.
### Änderung von Leistungsanträgen
Bei geringfügigen Korrekturen nach der Einreichung können Partner die `AmendBenefitApplication` API-Aktion verwenden, um bestimmte Felder zu aktualisieren, ohne die gesamte Anwendung erneut aufrufen zu müssen. Dies ist besonders nützlich, wenn AWS Gutachter während des Überprüfungsprozesses Klarstellungen oder Korrekturen anfordern.
Änderungsanträge verwenden einen Patch-style JSON-Ansatz, bei dem die Partner Folgendes angeben:
+ **Path** — Ein JsonPath-Ausdruck, der das zu aktualisierende Feld identifiziert (z. B. `$.CreditDisbursementDetails.AwsAccountIdForCredits`
+ **Wert** — Der neue Wert für das Feld
+ **Operation** — Der auszuführende Vorgang (`REPLACE`wird derzeit nur unterstützt)
Partner können in einem einzigen API-Aufruf bis zu 10 Änderungen einreichen. Für optimistisches Sperren muss jede Änderung eine aktualisierte Revisionsnummer enthalten.
Änderungsanträge sollten für geringfügige Korrekturen verwendet werden. Bei wesentlichen Änderungen sollten die Partner den Antrag `RecallBenefitApplication` in den Entwurfsstatus zurückversetzen, um ihn umfassend zu aktualisieren.
### Stornierung von Leistungsanträgen
Wenn ein Partner eine Leistung nicht mehr benötigt oder seinen Antrag zurückziehen möchte, kann er ihn mithilfe der `CancelBenefitApplication` API-Aktion stornieren. Durch die Stornierung wird der Antrag in den `CANCELED` Status versetzt, wodurch der Bewerbungsprozess dauerhaft beendet wird.
Bei der Stornierung einer Bewerbung sollten die Partner Folgendes angeben:
+ **Kennung** — Die ID oder ARN des zu stornierenden Leistungsantrags
+ **Grund** — Eine optionale Erklärung für die Kündigung (maximal 1000 Zeichen)
Einmal stornierte Anwendungen können nicht reaktiviert werden. Wenn der Partner später entscheidet, dass er die Leistung benötigt, muss er einen neuen Leistungsantrag stellen.
Zu den häufigsten Kündigungsgründen gehören:
+ Die Kundenchance wurde verpasst oder verspätet
+ Die Kapazitätsbeschränkungen der Partner haben sich geändert
+ Die Prioritäten der Unternehmen haben sich verschoben
+ Die Leistung wird für den vorgesehenen Zweck nicht mehr benötigt
## Einzelheiten zum Leistungsantrag anzeigen
Partner können mithilfe der `GetBenefitApplication` API-Aktion vollständige Informationen zu einem Leistungsantrag abrufen. Dies bietet einen umfassenden Überblick über die Anwendung, einschließlich:
**Metadaten der Anwendung:**
+ Eindeutige Kennung (ID) und Amazon-Ressourcenname (ARN)
+ Kennung der zugehörigen Leistung
+ Name und Beschreibung der Anwendung
+ Aktueller Status (`PENDING_SUBMISSION``IN_REVIEW`,`ACTION_REQUIRED`,`APPROVED`,`REJECTED`, oder`CANCELED`)
+ Aktuelle Verarbeitungsphase
**Informationen zum Status:**
+ Statusgrund — Human-readable Erläuterung des aktuellen Status
+ Status-Ursachencodes — Strukturierte Codes, die auf bestimmte Probleme oder Anforderungen hinweisen (z. B. „Checkliste unvollständig“, „Projektplan fehlt“, „Design Win fehlt“)
**Inhalt der Bewerbung:**
+ Vollständige Angaben zum Leistungsantrag (JSON-Dokument)
+ Kontaktinformationen des Partners
+ Dateianhänge mit Bearbeitungsstatus
+ Dazugehörige Ressourcen (Opportunities oder Allokationen)
+ Ressourcen-Tags
**Informationen zur Prüfung:**
+ Zeitstempel der Erstellung
+ Zeitstempel der letzten Änderung
+ Aktuelle Revisionsnummer
Die Codes für die Statusursache sind besonders nützlich, wenn sich eine Anwendung im `ACTION_REQUIRED` Status befindet. Diese Codes bieten konkrete, umsetzbare Hinweise darauf, was Partner beachten müssen, damit der Antrag bearbeitet werden kann.
## Auflistung von Leistungsanträgen
Partner können mithilfe der `ListBenefitApplications` API-Aktion alle ihre Leistungsanträge einsehen. Dadurch wird eine paginierte Liste von Anwendungsübersichten mit leistungsstarken Filterfunktionen zurückgegeben.
Partner können Anwendungen nach folgenden Kriterien filtern:
+ **Programm** — Anwendungen für bestimmte Programme anzeigen (MAP, MDF, Sandbox, POC usw.)
+ **Versandart** — Nach Versandart filtern (`CREDITS`, `CASH``ACCESS`, usw.)
+ **Benefit Identifier** — Anträge für eine bestimmte Leistung anzeigen
+ **Status** — Nach Antragsstatus filtern (`PENDING_SUBMISSION`,`IN_REVIEW`,`APPROVED`,`REJECTED`,`CANCELED`)
+ **Phase** — Nach Genehmigungsphase filtern (Geschäftsgenehmigung, technische Genehmigung, Finanzgenehmigung)
+ **ARNs für zugehörige Ressourcen** — Suchen Sie nach Bewerbungen, die mit bestimmten Stellenangeboten oder Zuweisungen verknüpft sind
Die Antwort auf die Liste enthält wichtige zusammenfassende Informationen wie:
+ Anwendungs-ID, ARN und Name
+ ID der zugehörigen Leistung
+ Programme und Arten der Auftragsabwicklung
+ Aktueller Status und Stand
+ Zeitstempel für Erstellung und Änderung
+ Zugeordnete Ressourcen
+ Aktuelle Revisionsnummer
+ Ausgewählte Felder aus den Angaben zum Leistungsantrag (wie vom Leistungsempfänger definiert)
Partner können die Ergebnissortierung mithilfe des Sortierparameters konfigurieren. Dabei stehen Optionen zur Verfügung, um die Ergebnisse nach Erstellungsdatum, Status, Programm oder Leistungs-ID in aufsteigender oder absteigender Reihenfolge zu sortieren.
**Erstellung von Dashboards:** Die `ListBenefitApplications` API wurde entwickelt, um die Erstellung von Partner-Dashboards zu unterstützen. Durch das Filtern und Sortieren von Anwendungen können Partner Ansichten wie die folgenden erstellen:
+ Anwendungen, für die Maßnahmen erforderlich sind (`ACTION_REQUIRED`Status)
+ Kürzlich eingereichte Bewerbungen (sortiert nach Erstellungsdatum, `IN_REVIEW` Status)
+ Genehmigte Anträge, deren Zuteilung noch aussteht (`APPROVED`Status)
+ Bewerbungen nach Programmen (nach bestimmten Programmen gefiltert)