How to Capture a .NET/C# Web App with a Screenshot API

ASP.NET and Blazor applications tend to live in enterprise environments where the screenshot needs are less about marketing pages and more about internal dashboards, admin panels, and reporting screens — exactly the kind of authenticated, data-heavy views that are tedious to capture reliably with a manual process or a maintained browser script.

Why .NET Apps Need Their Own Approach

• Server-side rendering timing. Blazor Server and older ASP.NET MVC views can render an initial shell before data-bound content populates.
• Enterprise auth flows. Windows auth, Azure AD, and custom SSO layers mean the "interesting" screens are almost always behind a login.
• Dense data grids. Reporting and admin screens in .NET shops are frequently full of tables and charts that benefit from a full-page capture rather than a cropped viewport.

C# Example

using System.Net.Http;
using System.Net.Http.Headers;
using System.Text;
using System.Text.Json;

var payload = new
{
    url = "https://internal.example.com/reports/quarterly",
    format = "png",
    width = 1440,
    height = 900,
    fullSize = true,
    hideCookie = true,
    delay = 2
};

using var client = new HttpClient();
client.DefaultRequestHeaders.Add("x-snapshotsiteapi-key", "YOUR_API_KEY");

var content = new StringContent(
    JsonSerializer.Serialize(payload),
    Encoding.UTF8,
    "application/json"
);

var response = await client.PostAsync(
    "https://api.prod.ss.snapshot-site.com/api/v1/screenshot",
    content
);

var body = await response.Content.ReadAsStringAsync();
Console.WriteLine(body);

Practical Recommendations

• Use delay for Blazor Server views. The SignalR round-trip that populates a dashboard after the initial page load is often a second or two — a short delay avoids capturing the shell before data arrives.
• Capture the authenticated URL directly. As with any authenticated screen, the practical pattern is pointing the capture at a session-valid URL rather than trying to replicate a login flow inside the request itself.
• Default to fullSize: true for reporting screens. .NET admin and reporting views are usually longer than a single viewport, especially with expandable table rows or multi-section dashboards.
• Strip environment banners with a CSS selector. Staging ribbons and build-version footers common in enterprise .NET deployments can be removed before capture with the hide field on the v2 endpoint.

Common .NET Use Cases

• Weekly or monthly report screenshots for stakeholders who do not have dashboard access
• QA evidence for internal tooling releases
• Documentation screenshots for internal admin panels and knowledge bases
• Change monitoring on internal status or ops dashboards

Why This Beats a Maintained Selenium/Playwright Setup

Enterprise .NET teams often already have a Selenium or Playwright rig lying around from UI test suites, and the instinct is to reuse it for screenshots too. That works, but it means owning browser versions, driver updates, and flaky waits as a side project. A single HTTP call from the same C# codebase handles the rendering concern externally, which is one less piece of infrastructure to keep green.

If you're not sure whether a plain capture or v2's cleanup options fit these enterprise dashboards better, see Snapshot API v1 vs v2 vs v3: Which Endpoint Should You Use?.

Snapshot Site fits into a .NET stack the same way any other HTTP-based dependency does — no browser binaries to manage on your own servers.