Debugging Binary API Responses: How Postman's 'Send and Download' Solves ZIP File Debugging

If you've ever tried to debug an API endpoint that returns a binary file — a ZIP, a PDF, an exported report — using the regular Send button in Postman, you've probably hit this: Postman tries to render the response in the preview pane, the bytes get garbled, and you have no way to actually open the file and look inside. I run into this almost daily.

I'm a backend developer working on the routing layer of a logistics product, and one of the things we ship is a bundle of route data as a ZIP — multiple files inside, generated server-side, downloaded by clients. When something looks off in production (wrong file count, corrupted entries, missing manifest), the fastest way for me to triage is to hit the endpoint myself in Postman, get the ZIP onto my machine, and unpack it.

This post covers the workflow I've landed on. It's nothing exotic, but it took me longer to discover than it should have, so writing it down in case it saves someone else a couple of hours.

The problem with regular Send

When you hit Send on a request whose response has a binary Content-Type like application/zip, application/octet-stream, or application/pdf, Postman buffers the bytes into its response viewer. You can technically scroll through hex output, but you can't double-click and open the file. Worse, if you try to copy the response into a .zip file manually, Postman's text encoding silently corrupts non-UTF-8 bytes — the file you save won't unzip.

For a while I was working around this with curl --output route.zip from the terminal. That works, but loses everything Postman gives me: request history, environment variables for staging vs. prod tokens, collection runners, and the ability to share the exact request with a teammate.

The fix: Send and Download

Postman has a separate option next to the Send button. Click the dropdown arrow and you'll see Send and Download. This sends the request, receives the response, and instead of trying to render it, prompts you for a file location and writes the raw response body to disk. Filename, extension, location — your choice. The bytes hit the file system exactly as the server sent them.

For my routing ZIPs that means:

1. POST to the route-bundle endpoint with the right auth headers and body
2. Click the dropdown arrow next to Send → Send and Download
3. Save as route-bundle-prod.zip in a scratch folder
4. Open the file with my OS's archive tool, or unzip -l route-bundle-prod.zip to list contents

If the file count is wrong or one of the inner files is empty, I know it before the client team has to file a ticket.

A few things I've learned

1. Status codes still matter. Send and Download doesn't surface the status code as obviously as Send does — you have to glance at the response status bar. If the server returned a 500 with an HTML error page but the Content-Type was still application/zip, you'll save a 4 KB "ZIP" that's actually an HTML error. Always check the status first.

2. Authorization headers carry over. This caught me out early. I'd switched environments to staging but the request still had a prod bearer token. The file downloaded successfully but unzipped to the wrong tenant's data. Now I double-check the {{baseUrl}} and {{token}} variables in the request URL before hitting Send and Download, especially after switching environments.

3. Save into a scratch directory, not Downloads. If you do this often, your Downloads folder fills up with download.zip (3).zip files. I have a ~/postman-downloads/ folder I clear out weekly.

4. Pair it with the Scripts tab for assertions. You can write a quick pm.test in the Scripts tab that asserts the response Content-Length is above some minimum threshold — useful to catch empty-ZIP regressions automatically when you're running a collection.

Wrap-up

Send and Download isn't a flashy feature. It's a small option two clicks deep. But if your API surface includes any kind of file export endpoint, it removes the only real reason to drop out of Postman and into curl. I haven't touched curl for downloading API responses since I found it.

If you're working on a similar binary-response endpoint and Postman feels like it's fighting you, give it a try.