JAVA REST INTEGRATION

Call the screenshot API from Java without a fictional SDK

Snapshot Site does not currently publish an official Java SDK. Use java.net.http.HttpClient for HTTPS requests and the JSON library already standardized in your application for typed payloads. Keep authentication, timeouts, retries, and asset storage explicit.

Java 11+
Built-in HttpClient
Direct REST
No official wrapper claimed
JSON over HTTPS
Capture, analyze, compare
Install:Use java.net.http from the JDK
Auth:SNAPSHOT_SITE_API_KEY
Get started for free
Java HTTP workflow
Java backend building a secure JSON HTTP request and receiving a rendered website screenshot
Good fits
Spring Boot services and scheduled jobs
JVM workers and internal tooling
Report, documentation, and QA pipelines
Teams with an established JSON stack

The JDK already provides the transport

Java's built-in HttpClient can send synchronous or asynchronous requests, reuse connections, apply timeouts, and return bodies as strings, byte arrays, or files. Add the JSON mapping conventions your service already uses.

1

Build one reusable client

Configure connection behavior once and inject the client into the service responsible for capture operations.

2

Serialize explicit request records

Create operation-specific payload types with the JSON library already approved by the project.

3

Check transport and API outcomes

Validate the HTTP response and the documented JSON error fields before accepting a generated asset.

4

Stream assets into owned storage

Download the returned link with an appropriate body handler and retain the request context alongside the file.

Quick start

Send one screenshot request

1

Read SNAPSHOT_SITE_API_KEY from secure runtime configuration

2

Create a JSON payload for one documented endpoint

3

Send it with HttpClient and explicit request and connection timeouts

4

Parse the response with your application JSON library and verify errors before using link

Java screenshot API example

Java 17+

POST a screenshot request with the JDK client

The fixed text block keeps this transport example dependency-free. Production code should serialize a typed record with the JSON library already used by the service.

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.time.Duration;

public final class CapturePage {
  public static void main(String[] args) throws Exception {
    String apiKey = System.getenv("SNAPSHOT_SITE_API_KEY");
    if (apiKey == null || apiKey.isBlank()) {
      throw new IllegalStateException("SNAPSHOT_SITE_API_KEY is required");
    }

    String payload = """
      {
        "url": "https://example.com",
        "format": "webp",
        "width": 1440,
        "fullSize": true,
        "hideCookie": true
      }
      """;

    HttpClient client = HttpClient.newBuilder()
      .connectTimeout(Duration.ofSeconds(10))
      .build();

    HttpRequest request = HttpRequest.newBuilder()
      .uri(URI.create("https://api.prod.ss.snapshot-site.com/api/v1/screenshot"))
      .timeout(Duration.ofSeconds(45))
      .header("Content-Type", "application/json")
      .header("x-snapshotsiteapi-key", apiKey)
      .POST(HttpRequest.BodyPublishers.ofString(payload))
      .build();

    HttpResponse<String> response = client.send(
      request,
      HttpResponse.BodyHandlers.ofString()
    );

    if (response.statusCode() / 100 != 2) {
      throw new IllegalStateException("Unexpected HTTP status: " + response.statusCode());
    }

    // Parse and validate the documented JSON response here.
    System.out.println(response.body());
  }
}

Why this page does not install a Java package

Snapshot Site has no official Java SDK today. Publishing package coordinates, generated methods, or support claims would mislead developers and create a maintenance contract that does not exist. The reliable integration is the documented REST API.

Java 11 and later include java.net.http.HttpClient, so applications can call the API without a third-party transport. Most production Java services already use a JSON mapper through their framework. Combine those existing pieces in a small adapter and keep its behavior visible.

Design the adapter around operations

Use one reusable HttpClient

Build the client once with the connection policy required by the service. Reuse it across calls so connections and resources are shared. Inject it into an application service rather than constructing it inside a controller method.

Set a connection timeout on the client and a request timeout appropriate to browser work. Timeouts should be bounded but not copied blindly from a normal low-latency internal API.

Define typed request and response models

Create a screenshot request record with fields such as URL, format, width, height, full-page behavior, timing, and cleanup only when the workflow needs them. Define separate models for analyze and compare because their payloads and outputs are different.

Use the JSON naming configuration already adopted by the project. Confirm that fields such as fullSize and hideCookie serialize with the exact documented names rather than a framework-specific naming convention.

Model response fields the application consumes and preserve error, message, and retry information needed for operations. Ignoring unknown fields can help compatibility, but missing required fields such as a successful asset link should still fail the job.

Keep controller and worker concerns separate

Browser rendering can take longer than ordinary service calls. For interactive product requests, decide whether the user waits for the result or receives a job identifier. For batches and schedules, execute work in a queue or dedicated job runner rather than tying up application request threads.

Propagate cancellation when a job is abandoned. With asynchronous flows, make sure exceptions are observed and the application does not leave failed futures without monitoring.

Response and error handling

Check the transport response, then parse the JSON body and inspect the API-level outcome. A valid HTTP exchange can still describe an invalid target or rendering failure. Convert those results into a domain-specific exception or job status with enough context to act.

Do not copy full response bodies, secret headers, or URLs with private query parameters into unrestricted logs. Log the target identifier, operation, sanitized host, attempt, error code where available, and correlation or job identifier.

Retry only outcomes the application classifies as transient. Use bounded exponential backoff with jitter and stop when the request is invalid. Scheduled batches should continue or stop according to an explicit policy, not because an exception happened to escape a loop.

Download generated assets

The screenshot response returns a link. If the asset is part of a durable report, QA record, or documentation set, download it into storage owned by the application. Validate response status and content type, then stream into a file or object-store upload rather than accumulating large images in heap memory unnecessarily.

Store the capture options and source metadata with the object. This supports reproduction and prevents a future reviewer from guessing which viewport or delay created the file.

Java integration patterns

Spring Boot service

Register the Snapshot Site adapter as a service and inject the API key through the framework's externalized secret configuration. Keep endpoint payload construction inside the adapter and call it from jobs or application use cases.

Do not expose a generic “capture any URL with any script” controller unless the product has a reviewed target and authorization policy. A narrow service method is safer and easier to operate.

Scheduled report job

Use the application's existing scheduler to create report URLs, request PDF or image outputs, validate responses, and store results under a deterministic report key. See the Screenshot Scheduler page for overlap and retention patterns.

Visual release checks

Call the compare endpoint with staging and production or a stored baseline. Persist the diff and summary with the release identifier. A mismatch is a review signal; do not automatically fail every release until the team has tuned stable inputs and ownership.

Security and performance

Read the API key from a secret manager or environment injected at runtime. Never commit it, embed it in a frontend bundle, or place it in a target URL. Restrict which application components can call the adapter.

Validate user-controlled target URLs according to the product's destination policy. Bound batch concurrency with an executor sized for the plan and service resources. Cache unchanged outputs and avoid generating a fresh image for every request when a stored asset is valid.

Java integration checklist

  1. Reuse a configured HttpClient.
  2. Use the project's existing JSON mapper.
  3. Create separate types for screenshot, analyze, and compare.
  4. Set connection and request timeouts deliberately.
  5. Check transport and API-level errors.
  6. Stream durable assets into owned storage.
  7. Bound concurrency and retry only transient failures.
  8. Keep secrets and sensitive target data out of logs.

Java screenshot API FAQ

Is there an official Snapshot Site Java SDK?

No. Snapshot Site currently provides official TypeScript, Python, and PHP SDKs. Java applications should call the documented REST endpoints directly.

Which Java version can use the built-in HttpClient?

java.net.http.HttpClient has been part of the standard JDK since Java 11. The example uses Java text blocks, which require a newer Java release.

Which JSON library should I use?

Use the JSON mapper already standardized in your application, such as the one configured by your framework. Avoid adding a second mapper only for one API call.

Can I use this from Spring Boot?

Yes. Register a reusable client or adapter as a service, inject secure configuration, and execute long-running or batch capture work outside request threads when appropriate.

Can Java call visual comparison and analysis?

Yes. Both are REST operations. Define operation-specific request and response types from the API documentation.

Should I use send or sendAsync?

Use the style that matches the service architecture. Synchronous calls are simple in dedicated workers; sendAsync can fit non-blocking orchestration when its lifecycle is handled correctly.

How should Java retry capture requests?

Retry only transient outcomes with bounded exponential backoff and jitter. Do not retry invalid requests or authentication failures.

How should generated files be downloaded?

Validate the API response, then use a suitable body handler or streaming request for the returned link and store the file under the workflow's access and retention policy.

Related resources

Snapshot Site HomeWebsite Screenshot APIJavaScript RenderingGo IntegrationC# IntegrationPHP SDKScreenshot SchedulerPlaywright Screenshot GuideAPI DocumentationPricing

Add one explicit Java API adapter

Prove a typed capture request with your existing HTTP and JSON conventions, then extend the adapter only for operations the application uses.

Get started for freeRead the API docs