GO REST INTEGRATION

Use Go's standard HTTP client for screenshot workflows

Snapshot Site does not currently publish an official Go SDK. Use net/http and encoding/json to call the REST endpoints directly, keep the API key in server-side configuration, model only the response fields your service needs, and wrap the client with timeouts and bounded retries.

No wrapper

Direct REST integration

net/http

Standard library client

Typed JSON

Explicit request and response

Install:go mod init example.com/snapshot-client

Auth:SNAPSHOT_SITE_API_KEY

Get started for free

Go HTTP workflow

Go backend sending concurrent HTTP requests to screenshot, analysis, and visual comparison outputs

Good fits

Go services, workers, and command-line tools

Concurrent but bounded screenshot queues

Scheduled monitoring and evidence capture

Teams that prefer a small explicit REST client

A small Go client is enough

The API uses JSON over HTTPS and header authentication. The standard library already provides request construction, context cancellation, connection reuse, JSON encoding, and response handling.

Reuse one http.Client

Create a client with a timeout and reuse it across requests so transports and connections are not recreated for every capture.

Model the payload

Use structs with JSON tags for the capture options and response fields your application consumes.

Propagate context

Build requests with context so worker cancellation and deadlines stop in-flight calls cleanly.

Download deliberately

Validate the API response before downloading the returned asset and stream it into controlled storage.

Quick start

Capture a page from Go

Read SNAPSHOT_SITE_API_KEY from the process environment

Marshal a typed request payload with encoding/json

POST it with Content-Type and x-snapshotsiteapi-key headers

Check both HTTP handling and the JSON error field before using the returned link

Go screenshot API example

Typed capture request with context

This standard-library example has no third-party client dependency and does not imply an official Go package.

package main

import (
  "bytes"
  "context"
  "encoding/json"
  "fmt"
  "net/http"
  "os"
  "time"
)

type CaptureRequest struct {
  URL        string `json:"url"`
  Format     string `json:"format"`
  Width      int    `json:"width"`
  FullSize   bool   `json:"fullSize"`
  HideCookie bool   `json:"hideCookie"`
}

type CaptureResponse struct {
  Status  string `json:"status"`
  Error   bool   `json:"error"`
  Message string `json:"message"`
  Link    string `json:"link"`
}

func main() {
  key := os.Getenv("SNAPSHOT_SITE_API_KEY")
  if key == "" { panic("SNAPSHOT_SITE_API_KEY is required") }

  payload, err := json.Marshal(CaptureRequest{
    URL: "https://example.com",
    Format: "webp",
    Width: 1440,
    FullSize: true,
    HideCookie: true,
  })
  if err != nil { panic(err) }

  ctx, cancel := context.WithTimeout(context.Background(), 45*time.Second)
  defer cancel()

  req, err := http.NewRequestWithContext(ctx, http.MethodPost,
    "https://api.prod.ss.snapshot-site.com/api/v1/screenshot",
    bytes.NewReader(payload))
  if err != nil { panic(err) }

  req.Header.Set("Content-Type", "application/json")
  req.Header.Set("x-snapshotsiteapi-key", key)

  client := &http.Client{Timeout: 50 * time.Second}
  res, err := client.Do(req)
  if err != nil { panic(err) }
  defer res.Body.Close()

  var result CaptureResponse
  if err := json.NewDecoder(res.Body).Decode(&result); err != nil { panic(err) }
  if result.Error { panic(result.Message) }
  fmt.Println(result.Link)
}

Why direct REST is the honest Go integration

An SDK page should not imply that a maintained package exists when it does not. Snapshot Site currently has no official Go module. The API is still straightforward to use from Go because requests are JSON over HTTPS and authentication is one header.

Using net/http keeps the dependency surface small and makes every option visible. The tradeoff is that your application owns request types, response types, retry policy, and asset download behavior. Keep that wrapper focused rather than recreating the entire API spec by hand.

Structure a production client

Reuse transport resources

Go's HTTP clients and transports are safe for concurrent use and should be reused. Create one client for the service or worker, set explicit timeouts, and inject it into the capture component. Avoid constructing a fresh client inside every job.

For services with specific proxy, connection-pool, or TLS requirements, configure a dedicated transport once. Leave defaults alone unless measurements or infrastructure policy justify a change.

Keep operation types separate

Screenshot, analyze, and compare payloads have different shapes. Define a request type for each operation and response structs containing the fields the application actually consumes. This keeps compile-time help useful and makes API changes easier to review.

Do not hide the raw response entirely. Preserve the API message and error information in your application error type so logs and alerts contain enough context to diagnose a failed job.

Handle application errors in JSON

Some API validation or rendering outcomes are represented in the JSON response. Do not rely only on res.StatusCode. Decode the body, check the documented error indicator, and validate required fields such as link before starting a download.

Bound how much error body you retain in logs. A response or target URL can contain information that should not be copied into a shared logging system.

Download and store outputs

The capture response provides a link to the generated asset. If your application needs durable ownership, download it promptly into the storage system that owns the workflow. Use a streaming copy, validate status and content type, and set a maximum size appropriate to the output.

Store the target identifier, source URL, capture options, API fetch time, resulting dimensions, and storage key together. A bare image file cannot explain how it was produced.

For high-volume queues, avoid two workers downloading or storing the same job. Use an idempotency key based on the target, capture configuration, and intended schedule or content revision.

Concurrency and retries

Go makes concurrency easy, which also makes it easy to create an unbounded request burst. Use a fixed worker pool or buffered semaphore and size it according to the plan and surrounding system. A goroutine per URL without a limit is not a production queue.

Retry network interruptions and errors known to be transient. Use exponential backoff with jitter, honor cancellation, and stop after a small maximum attempt count. Invalid payloads and missing API keys need correction, not another request.

Propagate context.Context from the job runner through request creation and any asset download. When a deployment shuts down or a scheduled run is canceled, in-flight work should stop rather than continue without an owner.

Go workflow examples

Scheduled page capture

A worker can read targets from a database, build one typed request per target, and store the result under a daily or hourly job key. The Screenshot Scheduler page covers locking, overlap, and retention.

Visual monitoring

Model the compare request separately and send a stored baseline image plus a live URL. Route the returned before, after, diff, and summary fields into an alert or review record. Keep viewport and cleanup settings with the baseline.

Batch documentation assets

Use a bounded pool to capture approved routes and write a manifest mapping each document page to its asset. Fail the batch clearly when required pages are missing rather than silently publishing incomplete documentation.

Security checklist for Go services

Read the API key from a secret manager or environment supplied by the runtime. Never compile it into the binary, commit it, include it in a target URL, or expose it through an HTTP handler response.

If users can submit target URLs, validate them against the product's destination policy before passing them to the API. Sanitize query parameters in logs and restrict any optional page-preparation code to trusted configurations.

Go integration checklist

Reuse one configured http.Client.
Create requests with context and deadlines.
Model each API operation separately.
Check HTTP handling and JSON application errors.
Validate links and stream downloads into controlled storage.
Bound worker concurrency and retry attempts.
Keep credentials and sensitive URLs out of logs.
Test cancellation, timeouts, invalid input, and partial batches.

Go screenshot API FAQ

Is there an official Snapshot Site Go SDK?

No. Snapshot Site currently publishes official TypeScript, Python, and PHP SDKs, but not a Go package. This page documents a direct REST integration.

Which Go packages are required?

The example uses standard-library packages including net/http, encoding/json, context, bytes, time, and os.

Should I create a new http.Client for every screenshot?

No. Reuse a configured client so its transport and connections can be reused safely across requests.

How should Go workers handle timeouts?

Set a client timeout and pass a context deadline for each job. Make the limits large enough for the expected browser work but always bounded.

Can Go call the analyze and compare endpoints?

Yes. They are JSON REST endpoints. Define separate request and response structs from the documented payloads rather than forcing every operation into one type.

How do I retry failed requests?

Retry only transient failures, use bounded exponential backoff with jitter, and stop on invalid requests or authentication errors.

How should I download the returned image?

Issue a separate GET for the returned link, validate status and content type, and stream the body into storage without loading an unnecessarily large asset into memory.

How can I limit concurrent captures in Go?

Use a worker pool or semaphore with a fixed limit. Reuse the HTTP client and propagate cancellation through contexts.

Related resources

Snapshot Site Home Website Screenshot API Visual Diff API Java Integration C# Integration Python SDK Screenshot Scheduler Playwright Screenshot Guide API Documentation Pricing

Start with a small explicit Go client

Implement one typed capture call, add timeout and error handling, then extract a reusable client only after the application requirements are clear.

Get started for free Read the API docs