How to Validate API Responses Before Saving Processed Files in C#

Cloudmersive

3 min read

·

Oct 11, 2026

--

Listen

Share

Press enter or click to view image in full size

When we call a file-processing API, a successful HTTP request doesn’t imply a usable file came back from the endpoint.

We can get empty byte arrays, giant error pages of plain text, or payloads that aren’t in the format we asked for. Obviously, we can’t just write those straight to disk; we’ll end up creating files with valid-looking extensions that no readers will actually open.

To fix, that, let’s implement a short checkpoint between the API call and the file saving operation (whatever that might look like). In this walkthrough, we’ll convert a document to PDF with the Cloudmersive Convert API, and we’ll vet the response in plain C# code before it ever reaches our filesystem.

Note that the file save destination is incidental here; this isn’t a tutorial on saving files. Be sure to replace our risk writes with whatever cloud/object storage or DB blob/stream operations your production workflow uses.

Installing the client

Let’s begin by installing the latest Convert API client:

Install-Package Cloudmersive.APIClient.NETCore.DocumentAndDataConvert

Configuring the client

We only have one package to work with here, so setup is pretty easy:

using Cloudmersive.APIClient.NETCore.DocumentAndDataConvert.Api;
using Cloudmersive.APIClient.NETCore.DocumentAndDataConvert.Client;

Configuration.Default.AddApiKey(
    "Apikey", Environment.GetEnvironmentVariable("CLOUDMERSIVE_API_KEY"));

var convertApi = new ConvertDocumentApi();

Requesting a processed file

The autodetect conversion method we’ll be using returns our PDF as a raw byte array. We’re not trusting those bytes yet; we’re just capturing them initially:

byte[] ConvertToPdf(string inputPath)
{
    using var input = File.OpenRead(inputPath);
    return convertApi.ConvertDocumentAutodetectToPdf(input);
}

Validating the response

Now we’ll implement our checkpoint. Our goal here is to gather every problem into one list instead of stopping at the first problem we encounter — that way, we can return a small record that the caller can act on.

A real PDF always begins with the bytes %PDF, which gives us a cheap and reliable way to confirm we actually got one of those:

record ResponseCheck(bool IsValid, List<string> Errors);

ResponseCheck ValidatePdfResponse(byte[] data)
{
    var errors = new List<string>();

    if (data is null || data.Length == 0)
    {
        errors.Add("Response was empty.");
    }
    else
    {
        if (data.Length < 100)
            errors.Add("Response is too small to be a real PDF.");

        if (!HasPdfSignature(data))
            errors.Add("Response is missing the %PDF header.");
    }

    return new ResponseCheck(errors.Count == 0, errors);
}

bool HasPdfSignature(byte[] data) =>
    data.Length >= 4 &&
    data[0] == 0x25 && data[1] == 0x50 &&
    data[2] == 0x44 && data[3] == 0x46; // "%PDF"

Saving only what passes

Now that we’ve implemented our check, persistence is just a single branch. Valid responses get written, while everything else is reported with its reasons so nothing fails silently:

void SaveIfValid(byte[] data, string outputPath)
{
    var check = ValidatePdfResponse(data);

    if (!check.IsValid)
    {
        Console.WriteLine($"Not saving. {string.Join(" ", check.Errors)}");
        return;
    }

    File.WriteAllBytes(outputPath, data);
    Console.WriteLine($"Saved {data.Length} bytes to {outputPath}.");
}

var pdf = ConvertToPdf("input.docx");
SaveIfValid(pdf, "output.pdf");

If, for example, we get an HTML error page masquerading as a PDF, we’ll learn about both reasons at once:

Not saving. Response is too small to be a real PDF. 
Response is missing the %PDF header.

Conclusion

We now have a checkpoint in our code that decides whether converted documents are actually work keeping. It’s acting directly on what the API declares it returned, so can easily harden our response rules anytime without disturbing the call that produces the file.