Thanks for the quick help earlier! I switched to Set Variables as suggested and removed the Code block, but the issue persists. Context
Agent: Orchestration Agent (68fa7f2035fab4aa6a063b2c)
Webhook: 8c0bd5fe-6cd6-4f23-ab34-20c09edb10cd (format /webhooks/lindy/<id>)
Trigger shows incoming headers as content-type: text/plain; charset=UTF-8, so body is a string.
What I did
parsed_body (Set Variables, Use expression): parses webhook_received.request.body via JSON.parse.
contact_id (Set Variables, Use expression): picks from parsed_body.contact_id || parsed_body.leads[0].contact_id || query || header.
contact_id_final (Set Variables, Use expression): validates UUID (regex), falls back to first UUID in raw body.
Problem Downstream HTTP request sometimes receives the literal expression/regex instead of the evaluated UUID string, which ends up in the URL and my DB returns:
400 PGRST100 … "failed to parse filter ( /^[0-9a-f]{8}-...-...$/i )"
or previously
22P02 invalid input syntax for type uuid: "steps.parsed_body.output.value?.contact_id || …"
Even though node previews show the correct UUID, the built URL occasionally contains the unevaluated text. What I tried
Recreated all three Set Variables from scratch (fx mode only).
Tested URL building both with value chips and with fx returning the full URL.
Minimal payload { "contact_id": "<uuid>" } → 200. Full payload also 200 at webhook level.
Regenerated webhook URL. Same behavior.
Hypothesis Two possible issues on Lindy side:
Webhook request header handling: even with Content-Type: application/json from the client, Lindy often records it as text/plain, forcing manual JSON.parse. This may be expected, but please confirm whether the public webhook should accept and mark JSON as application/json in request.headers.
Expression evaluation propagation: Set Variables preview shows the correct evaluated value, but some downstream consumers receive the unevaluated expression (or a regex literal that was only meant for validation). This looks like a binding/serialization bug—value chips or fx-strings should both resolve to the primitive at execution time.
Requests
Can you check why the evaluated value from Set Variables sometimes propagates as expression/regex text to the next node? Any known binding/serialization quirk or required reference format?
Should the public webhook treat Content-Type: application/json as JSON (so request.body is parsed), or is text/plain expected?
Happy to share a task link/run ID if helpful. Thanks!
Hi Lindy Support, I'm experiencing an several issues with my Agent Agent Definition ID: 68fa7f2035fab4aa6a063b2c Agent Name: Orchestration Agent First problem - Webhook trigger 'body' output not accessible in downstream Code node Error: "Failed to find output reference 'body' because no-source-block-found" Configuration: - Webhook trigger node ID: 68fa7f2035fab4aa6a063b2a - Code node trying to access it: 690af2fcf08b20b64f59dd8c - Reference path: webhook_received.body - Reference type: "output" The webhook trigger clearly outputs a 'body' field (I can see it in the UI: method, headers, query, body, etc.), but when the Code node tries to reference it, I get the "no-source-block-found" error. I've verified: The reference uses "type": "output" The path is "body" (not "request.body") The nodeId is correct The nodes are connected via edges All nodes are on the same layer This appears to be a bug in how webhook trigger outputs are exposed to downstream nodes. What We've Tried:
Changed from "type": "message" to "type": "output"
Verified the correct path is body (not request.body)
Confirmed the nodeId is correct (68fa7f2035fab4aa6a063b2a)
Verified the nodes are properly connected with edges
Confirmed all nodes are on the same layer
Webhook ID: 8c0bd5fe-6cd6-4f23-ab34-20c09edb10cd
Trigger ID: 6908ec3861376f959daac84d
Second problem Supabase connectivity: native nodes + HTTP requests failing with new keys Context New Supabase projects now use Secret API keys (legacy anon / service_role are disabled). Your native Supabase nodes appear not to support the new Secret keys yet. What I’m seeing
The native Supabase connector doesn’t authenticate with the new keys.
Even when I try the legacy key for testing, runtime egress seems to fail.
Plain HTTP Request nodes to Supabase also fail the same way
How should I authenticate Supabase calls from Lindy with the new Secret API keys? Is there a known issue with egress to *.supabase.co from the runtime? Do the native Supabase nodes plan to support the new key model? If yes, is there a workaround in the meantime? Can you please investigate? Thank you! -- Best regards, Svitlana Medvedyk
Hi! Where can I read the whole infornmation about your Lead Outreacher prebuild Agent? I want to see if it fully meets all my requirements before I start setting it up.
