POST /Roles/Sellers/{CompanyId}/Offers/FullImports liefert 401 Unauthorized in Synesty – unklar, wie Session korrekt übergeben werden muss

Fragen und Antworten
1

Hallo zusammen,

ich versuche aktuell, über Synesty einen Angebots-Export zur AERA V2 Seller API aufzubauen und komme an einem Punkt nicht weiter.

Vielleicht kann jemand sagen, wie die Session bei diesem Endpoint in Synesty korrekt übergeben werden muss.

Ausgangssituation

Ich habe einen mehrstufigen Flow:

  1. APICall AERA Login
    Der Login funktioniert und liefert einen Response mit UserSessionForInfo.Id.

  2. TextHTMLWriter
    Daraus extrahiere ich die Session-ID erfolgreich mit:

${responses@APICall_135[0]?eval_json["Data"]["UserSessionForInfo"]["Id"]}

Die Session-ID wird im TextHTMLWriter korrekt ausgegeben.

  1. APICall AERA Angebotsexport

    Hier möchte ich den AERA Full Import aufrufen.

Was bereits geklärt ist

Zuerst hatte ich versucht, die Session-ID direkt im Host/Pfad zu verwenden. Das führte aber zu falschen URLs und u. a. zu einem 404 Not Found.

Nach erneuter Prüfung der AERA-Doku ist klar:

Der korrekte V2-Endpoint ist:

POST /Roles/Sellers/{CompanyId}/Offers/FullImports

Also ohne Session-ID im URL-Pfad.

Für meine CompanyId ## sieht der Host in Synesty aktuell so aus:

/Roles/Sellers/##/Offers/FullImports?processingdate=${current_timestamp?string("yyyy-MM-dd")}&currency=EUR&validateonly=true

Mit diesem Pfad bekomme ich keinen 404 mehr, sondern jetzt:

HTTP Status: 401 (Unauthorized)
Message: "unauthorized"

Das ist aus meiner Sicht ein Hinweis darauf, dass der Endpoint jetzt stimmt, aber die Authentifizierung / Session-Übergabe noch nicht korrekt ist.

Header-Test

Aktuell teste ich im requestHeaders u. a. mit:

Content-Type: application/json
Accept: application/json
SessionId: ${TEMPLATE_OUTPUT_STRING@TextHTMLWriter_139!}

Die Session-ID aus dem TextHTMLWriter wird also als eigener Header mitgegeben.

Trotzdem bleibt die Antwort:

401 Unauthorized

Meine Frage

Hat jemand Erfahrung damit, wie die Session bei diesem AERA V2 Seller Endpoint in Synesty korrekt übergeben werden muss?

Insbesondere interessiert mich:

  • Wird die Session wirklich über einen Header erwartet?

  • Falls ja: wie heißt der Header exakt?

    • SessionId

    • sessionId

    • X-SessionId

    • etwas anderes?

  • Oder erwartet AERA hier statt Header eher ein Cookie?

  • Oder ist der Login-Response aus dem vorherigen Step für diesen V2-Seller-Endpoint in Synesty grundsätzlich nicht ausreichend?

Wichtigste Erkenntnisse bisher

  • Login funktioniert

  • Session-ID wird sauber extrahiert

  • Falscher Pfad führte zu 404

  • Korrigierter V2-Pfad führt jetzt reproduzierbar zu 401

  • Das Problem scheint also nicht mehr der Endpoint, sondern die Session-/Auth-Übergabe zu sein

Falls jemand ein funktionierendes Beispiel in Synesty für AERA V2 Seller API hat, wäre das extrem hilfreich.

Danke euch!

2

Hallo @Zepf-werk38,

ich bin mir nicht sicher, aber laut AERA Dokumentation(https://www.aera-online.de/Download/Docs/Api/V2/seller.yml) sollte die Session ID in den Header mit Key = Ao-SessionId.

image
image816×294 57.4 KB

Wichtig ist noch, das du statt des Doppelpunkts eine = im Feld requestHeaders verwendest, da der APICall Step das in dieser Form erwartet.

Content-Type=application/json
Accept=application/json
Ao-SessionId=${TEMPLATE_OUTPUT_STRING@TextHTMLWriter_139!}

VG Torsten

3

Hi Torsten. Danke nochmal für Deine Rückmeldung. Ich habe hier nochmal einiges angepasst. Allerdings mit selben Ergebenis

Content-Type:application/json
Accept:application/json
Ao-SessionId:${responses@APICall_135[0]?eval_json[„Data“][„UserSessionForInfo“][„Id“]}

Es heißt immer

62d13b64-bb73-4045-bad1-6cb0442fbd2d
62d13b64-bb73-4045-bad1-6cb0442fbd2d2048×1100 301 KB

Also die Session ID wird hier wohl nicht übergeben. In der Vorschau kann ich in dem zwischengeschalteten TextHTMLWriter (ist in diesem Screenshot kurz ausgeblendet) die SessionID konkret sehen.

Irgendwie liegt es an dieser Übergabe der Session-ID. Die Verbindung an sich wird ja sauber aufgebaut.

Hier noch der letzte Debug.

###
2026-03-11 09:58:06,711 Cancelling request execution
2026-03-11 09:58:06,712 Connection manager is shutting down
2026-03-11 09:58:06,712 http-outgoing-269379: Close connection
2026-03-11 09:58:06,712 Connection manager shut down
2026-03-11 09:58:06,712 [Start Step]: DCV Artikel Import#TextHTMLWriter 1.0
2026-03-11 09:58:06,716 [Start Step]: DCV Artikel Import#APICall AERA Angebotsexport 1.0
2026-03-11 09:58:08,443 Connection manager is shutting down
2026-03-11 09:58:08,443 Connection manager shut down

4

image
image1920×1032 166 KB
jetzt habe ich den kompletten Flow nochmal durchlaufen lassen. Jetzt bricht er an der Stelle ab, wo er im HTMLWriter die SessionID abfragen möchte. Die aber eindeutig in der Vorschau angezeigt wird.

5

Hallo @Zepf-werk38,

der Fehler tritt bei der Ausführung des Flows auf, weil der responses output des APICall Step während der Vorschau vorhanden ist. Dieser Output ist nur als „debugging“ Information der Vorschau verfügbar.

image
image742×306 27 KB

Kannst du im 1. API Call Step (Login) folgendes parsingTemplate hinterlegen:

<#assign row = target.addRow()>
<#list json["Data"]["UserSessionForInfo"] as j >
 <#assign row = target.addRow()>
 ${addColumns(row, j)}
</#list>

Dann kannst du auf die Session-ID mit ${output@APICall_1.firstRow("Id")} ( der _1 muss entsprechend deines Steps angepasst werde, siehe Wie finde ich die Variablen-Namen von Step Outputs heraus, um diese in Freemarker-Skripts zu benutzen?) im TextWriter oder im requestHeader Input des 2. APICall Steps zugreifen.
Bitte beachte auch den Kommentar von oben für das requestHeader Feld. Der Step erwartet ein = (nicht :) als Trennzeichen, z.B. Ao-SessionId=${TEMPLATE_OUTPUT_STRING@TextHTMLWriter_139!}

6

Hey Torsten, super. Danke. Das hat im ersten Schritt wohl schon geholfen. Ich lasse gerade den Flow nochmal komplett durchlaufen und gebe Rückmeldung.

Gruß Markus