Vor 3 Monaten hatte ich nicht die geringste Ahnung von Anwendungsprogrammierung, ich bin seit 8 Monaten in Spanien und bin mit einer Idee im Kopf hergekommen. Mit der Unterstützung von Gemini AI von Antigravity habe ich angefangen, meine Idee einer Sprachenübersetzungs-Anwendung umzusetzen, um mit ein paar Freunden aus Deutschland zu kommunizieren. Mein Workflow besteht aus 4 Knoten (Webhook1 + HTTP REQUEST + JavaScript + Respond to Webhook). Wenn ich auf „Workflow ausführen
Dein Workflow, der in unter 3 Sekunden läuft, bedeutet, dass die Automation ausgeführt wird, aber es beweist nicht, dass die Übersetzungsausgabe korrekt weitergeleitet wird. Das Problem liegt wahrscheinlich nicht in der „Übersetzung
Es ist beeindruckend, vom absoluten Anfänger zu einer funktionierenden Webhook-Pipeline zu gelangen, also gib nicht auf – du bist näher dran, als du denkst.
Die obige Antwort deckt alle Debugging-Schritte gut ab, aber es lohnt sich, noch eines hinzuzufügen: Die häufigste Ursache für „gibt die ursprüngliche Nachricht zurück
„Vielen Dank @pratham_gupta und @AnthonyAtXRay, dass ihr euch die Zeit genommen habt zu antworten! Eure Debug-Punkte sind ausgezeichnet.
Um euch etwas mehr Kontext zu geben: Anfangs, als ich erste Tests durchführte, schien der gesamte Ablauf gut zu reagieren. Allerdings wurden die echten Probleme im Browser erst vor kurzem deutlicher bemerkbar. Nach gründlicher Analyse vermuten wir, dass die interne Logik von n8n in Ordnung ist, aber der Fehler bei der finalen Kommunikation auftritt: Ich führe die Webanwendung lokal aus, indem ich die Datei index.html direkt von meinem Computer öffne (file://). Alles deutet darauf hin, dass Google Chrome oder lokale Netzwerkrichtlinien die Antwort von der n8n-IP wegen CORS blockieren.
Um das Ganze noch schlimmer zu machen, sind mir auch noch genau jetzt die Prepaid-Guthaben der Google-API aufgebraucht, sodass der Ablauf unterbrochen wurde.
Um zu überprüfen, ob die Variablenzuordnung so präzise ist, wie ihr vorschlagt, teile ich euch weiter unten die Struktur meines JavaScript-Knotens und den allgemeinen Ablauf (ohne Anmeldedaten). Haltet ihr meine Theorie, dass das Format file:// und CORS für die Blockierung im Browser verantwortlich sind, für sinnvoll, oder seht ihr einen Fehler in der Logik der Variablen?
{
“nodes”: [
{
“parameters”: {
“respondWith”: “json”,
“responseBody”: “={{ $json }}”,
“options”: {
“responseCode”: 200,
“responseHeaders”: {
“entries”: [
{
“name”: “Content-Type”,
“value”: “application/json”
},
{
“name”: “Access-Control-Allow-Origin”,
“value”: “"
},
{
“name”: “Access-Control-Allow-Headers”,
“value”: "”
}
]
}
}
},
“type”: “n8n-nodes-base.respondToWebhook”,
“typeVersion”: 1.5,
“position”: [
752,
112
],
“id”: “7eb0364c-e218-47a7-ba7e-f9d8fe8bb8f8”,
“name”: “Auf Webhook antworten”
},
{
“parameters”: {
“httpMethod”: “POST”,
“path”: “98bd0d2c-fcf4-49b7-b501-72c81c5d9d44”,
“responseMode”: “responseNode”,
“options”: {
“allowedOrigins”: “*”
}
},
“type”: “n8n-nodes-base.webhook”,
“typeVersion”: 2.1,
“position”: [
80,
112
],
“id”: “0af6f18b-0e1a-4d5c-bca6-7573f4a31cb9”,
“name”: “Webhook1”,
“webhookId”: “c1603781-563f-4655-9b6d-1170e847c6f0”
},
{
“parameters”: {
“method”: “POST”,
“url”: “https://generativelanguage.googleapis.com/v1/models/gemini-2.5-flash:generateContent?key=TU_API_KEY_AQUÍ”,
“sendBody”: true,
“specifyBody”: “json”,
“jsonBody”: “={{ { “contents”: [{ “parts”: [{ “text”: $json.body.text + " - Übersetze dies in " + $json.body.target_lang }] }] } }}”,
“options”: {}
},
“id”: “06da87ea-d639-41fa-a859-50ae26c35224”,
“name”: “HTTP-Anfrage”,
“type”: “n8n-nodes-base.httpRequest”,
“typeVersion”: 4.4,
“position”: [
304,
112
]
},
{
“parameters”: {
“jsCode”: “const geminiResponse = $input.first().json;\nconst translatedText = geminiResponse.candidates[0].content.parts[0].text.trim();\n\nreturn [\n {\n json: {\n status: “success”,\n original_text: $(‘Webhook1’).item.json.body.text,\n translated_text: translatedText,\n audio_base64: “”\n }\n }\n];”
},
“id”: “576fa8a4-896f-4d33-ad1a-8cfe5d204ec8”,
“name”: “Code in JavaScript”,
“type”: “n8n-nodes-base.code”,
“typeVersion”: 2,
“position”: [
528,
112
]
}
],
“connections”: {
“Webhook1”: {
“main”: [
[
{
“node”: “HTTP-Anfrage”,
“type”: “main”,
“index”: 0
}
]
]
},
“HTTP-Anfrage”: {
“main”: [
[
{
“node”: “Code in JavaScript”,
“type”: “main”,
“index”: 0
}
]
]
},
“Code in JavaScript”: {
“main”: [
[
{
“node”: “Auf Webhook antworten”,
“type”: “main”,
“index”: 0
}
]
]
}
],
“pinData”: {},
“meta”: {
“templateCredsSetupCompleted”: true,
“instanceId”: “ANONYMOUS_INSTANCE_ID”
}
}
Freddy, die Screenshots würden helfen, aber basierend auf deiner Beschreibung würde ich mich auf eine ganz spezifische Frage konzentrieren:
An welchem Punkt verschwindet der übersetzte Text?
Dein n8n-Workflow läuft möglicherweise korrekt, aber die Web-App liest möglicherweise immer noch das falsche Feld.
Ich würde es in dieser Reihenfolge testen:
- Webhook-Node
Bestätige, dass die eingehenden Daten etwa so aussehen:
{
"text": "hello",
"targetLanguage": "German"
}
- HTTP-Request-Node
Öffne die Node-Ausführungsausgabe und prüfe, ob die Übersetzungs-API den übersetzten Text zurückgibt.
Zum Beispiel etwa so:
{
"translatedText": "Hallo"
}
oder manchmal ist es tiefer verschachtelt, wie:
{
"data": {
"translation": "Hallo"
}
}
- JavaScript-Node
Das ist ein häufiger Fehlerpunkt. Der Code liest möglicherweise das falsche Feld.
Zum Debugging solltest du nicht die ursprüngliche Nachricht als Fallback zurückgeben. Gib stattdessen einen offensichtlichen Fehler zurück:
const output = $json.translatedText;
if (!output) {
throw new Error("No translated text found. Check HTTP Request output field name.");
}
return [
{
json: {
translatedText: output
}
}
];
Wenn der übersetzte Text verschachtelt ist, musst du den Feldpfad basierend auf der tatsächlichen HTTP-Request-Ausgabe anpassen.
- Respond to Webhook-Node
Stelle sicher, dass er den übersetzten Wert zurückgibt, nicht die ursprüngliche Eingabe.
Beispiel-Response:
{
"translatedText": "={{$json.translatedText}}"
}
- Frontend-Fetch-Code
Deine lokale Web-Seite macht möglicherweise etwas wie:
resultBox.innerText = data.text;
obwohl es sein sollte:
resultBox.innerText = data.translatedText;
Da deine App immer die ursprüngliche Nachricht zurückgibt, ist meine stärkste Vermutung eine von diesen:
-
Die JavaScript-Node fällt auf den ursprünglichen Text zurück
-
Die Respond to Webhook-Node ist auf das ursprüngliche Feld gemappt
-
Das Frontend zeigt das ursprüngliche Feld statt des übersetzten Feldes an
-
Die HTTP-Request-Node gibt die Übersetzung in einem verschachtelten JSON-Pfad zurück, aber die JS-Node liest den falschen Pfad
Bester Debug-Schachzug: Gib vorübergehend die gesamte HTTP-Request-Ausgabe direkt von Respond to Webhook zurück. Teste dann von der Web-App aus und prüfe, was dein Browser tatsächlich erhält. Sobald du die echte JSON-Struktur siehst, sollte das Mappen des übersetzten Feldes einfach sein.
Deine Theorie zu CORS ist genau richtig, und dein Workflow-JSON zeigt das spezifische Problem.
Dein Webhook-Node hat „allowedOrigins