I’m working on a Zapier workflow that needs to make two API calls. First, I get a CSRF token from the server, then I use that token in a second request to submit data.
The problem is that when I try to use the token in my second request, I get a 403 error. I think this happens because Zapier doesn’t keep the same session between different HTTP requests.
My workflow looks like this:
Make a GET call to the API with header ‘X-CSRF-Token’: ‘Fetch’
Save the token that comes back
Make a POST call with header ‘X-CSRF-Token’: saved_token
Submit the POST request
Can I use a JavaScript code step or build a custom app to keep the HTTP session alive between these requests? I need both calls to use the same session so the CSRF validation works properly.
Had the exact same issue with APIs that need session continuity. Zapier doesn’t keep cookies between separate HTTP steps, which is annoying but pretty common. Here’s what worked for me: use a Code by Zapier step to handle both requests in one go. You capture the Set-Cookie headers from your first response and manually add them to the second request. So you’d do your GET for the CSRF token AND your POST request all within a single code step using fetch or axios. The session cookies from the first call stick around and get passed to the second call automatically. Takes more coding than using separate HTTP steps, but you get full control over the session stuff. I’ve used this for several APIs that need both CSRF tokens and session cookies - works like a charm.
Hit this exact problem last month building workflows that needed session persistence. Most automation tools treat each HTTP request as totally separate.
Your approach is solid, but you’re spot on about session cookies not carrying over between calls. Even with JavaScript, you’d have to manually extract and pass session cookies - gets messy quick.
Switching to Latenode solved this perfectly. It’s got proper session management built in, so when you make that first GET request for the CSRF token, it automatically keeps the session cookies for later requests.
Flow becomes super clean:
HTTP GET with X-CSRF-Token: Fetch header
Extract token from response
HTTP POST with token - session stays alive automatically
Done
No custom code, no cookie juggling. Just works. I’ve used this for several APIs requiring CSRF validation - rock solid every time.
Yeah, this is a pretty common issue with workflow automation platforms. Zapier treats each HTTP step as separate requests - it doesn’t keep the TCP connection or session state alive between them. I hit this exact problem when working with a Django REST API that needed CSRF tokens. What worked for me was building a custom Zapier app with their CLI platform. You can set up proper authentication methods that handle sessions correctly. It’ll grab the initial token and keep that session context for all the follow-up requests. Way better than trying to jury-rig it with code steps. You define the auth flow once in the app config, then every HTTP operation automatically gets the right session handling. Takes more work upfront to build the app, but once it’s live you get solid session management across your whole workflow.
been there with CSRF APIs - total nightmare. use zapier’s webhooks by zapier action instead of the regular HTTP step. it’s way better at maintaining sessions and keeps connections alive so your cookies don’t get dropped between calls.
Just dealt with this exact nightmare a few weeks ago with a super picky API that demanded perfect session continuity.
The problem isn’t just manually passing cookies. Even if you nail that in a code step, you’re still fighting how most platforms handle HTTP connections.
Switching to Latenode fixed it for me. The platform actually gets session state and keeps everything connected between requests.
Your flow works perfectly there:
First request grabs the CSRF token
Session cookies store automatically
Second request uses the token AND keeps the session alive
API sees one continuous session and accepts the token
No wrestling with Set-Cookie headers or manually parsing/injecting cookies. Sessions just persist.
I banged my head against this for days before switching. Now these workflows just work without the session gymnastics.
Hit this same nightmare about six months ago with a super picky CSRF validation API. The problem is Zapier creates new HTTP contexts for each step, so your session dies between requests even when you’re passing the token correctly. Fixed it by cramming everything into one Code by Zapier step with node-fetch. You’ve got to build a cookie jar in that code block - grab the session cookies from your first GET, then manually stick them in your POST headers with the CSRF token. The annoying part is parsing those Set-Cookie headers and getting the format right for the Cookie header. Took some messing around to nail the cookie stuff, but it’s been bulletproof since. The API thinks it’s one continuous session for both calls, so CSRF validation works perfectly.