Well, this was a transient error and I have no way of generating this on command that I can think of, so I can't tell you what the headers looked like. I just had a file that downloaded correctly, wouldn't import, and it had json in it. I can put in a check for the file length (wasn't in there because if the file downloaded correctly with no errors and a 200 status code I'd assume that was a success). Ideally a REST API would set the HTTP result code so you can logic accordingly (i.e. 5xx is a server side problem, you can try that one again later, 4xx is a client problem so you can log that and figure out what you (the client) did wrong, etc) before getting into results / file contents.
They return a 4xx code when you try to get something without credentials, so this type of code would work for instance (we have something like it in production), however the last bit doesn't catch the error in question because they return a success HTTP code:
```
if (response.IsSuccessStatusCode)
{
// read file
return true;
}
else
{
if (response.StatusCode == HttpStatusCode.Forbidden)
throw new AuthenticationException("Invalid username/password combination.");
else
throw new Exception($"Bulk download error, API returned http status {response.StatusCode}");
}
```
I could check json and content types sure but this is the correct way for a REST API to report errors, and the Marketo API does return a forbidden when you haven't authenticated or your token has expired, so I think they should continue that through to the rest of the API error codes, particularly on this url where we aren't needing/wanting to parse the result at the time of download.
.png)