I’m building an n8n workflow to convert PDF files to HTML using Adobe PDF Services API but keep running into timing problems.
My Setup:
n8n version 1.92.2 running on Windows (self-hosted)
The Process I’m Following:
Create new asset and get upload URL
Upload PDF file to that URL
Start the conversion job
Check status until complete
Download the converted HTML
The Issue:
Step 3 always fails with 404 error. I think the upload hasn’t finished processing on Adobe’s side when I try to start the conversion.
What I’ve Tried:
Basic sequential nodes (data doesn’t pass through correctly)
Using “Include Input Data” option (breaks the binary file)
Parallel processing with merge (causes n8n internal errors)
Code node to combine data streams (creates race condition)
Wait timers up to 30 seconds (still get 404)
Retry logic with multiple attempts (all fail)
New API credentials (no change)
My Questions:
How do you properly handle APIs that need time to process between steps in n8n? What’s the right workflow structure to keep both file data and API responses moving through the nodes without losing either one?
Any examples of similar async API workflows would be really helpful. Thanks!
Had this exact problem with another async API recently. Skip the synchronous polling headache - use n8n’s webhook approach instead. Set up a webhook node that Adobe can ping when processing finishes, then use that webhook URL in your initial conversion request (if their API supports callbacks). If callbacks aren’t available, implement exponential backoff for polling - start at 5 seconds, then 10, 20, etc. Most important: enable ‘Continue on Fail’ in your status check node and route failures back to a wait node before retrying. This keeps the workflow alive during temporary 404s. Also check if Adobe’s API gives processing time estimates in the initial response - you can use those for smarter wait intervals.
Add a manual ‘Execute Workflow’ trigger between your upload and conversion steps. I know it sounds weird, but it forces n8n to wait for the upload response to finish before moving to the next step. Also double-check your asset ID format - Adobe often returns multiple IDs and you need the conversion-specific one, not just the upload confirmation ID. Fixed the same issue I had with their extract API.
I hit this exact issue with Azure’s document processing APIs. You need to split this into two separate workflows connected by a queue - don’t try chaining everything together. Break it at the conversion step. After uploading your PDF, save the asset ID and job details in a database or use n8n’s execution data storage. Then set up a second workflow that runs every 2-3 minutes to poll pending jobs and check their status. This kills the race condition since each workflow handles its own thing. For passing data around, use the HTTP Request node’s response to build a clean JSON object with your file reference and Adobe response data. Store it in a simple table that your polling workflow can read. The 404s will stop happening because you’re not assuming files are ready right after upload.