SYMFONY INTEGRATION

Build screenshot workflows as testable Symfony services

Wrap Snapshot Site in a focused HttpClient service, inject the API key through secrets, and move slow or high-volume captures into Messenger when the request lifecycle should stay fast.

HttpClient

Native request layer

Messenger

Async-ready jobs

Secrets

Private credentials

Install:composer require symfony/http-client

Auth:SNAPSHOT_SITE_API_KEY

Get started for free

Symfony screenshot service

Snapshot Site themed Symfony screenshot API integration illustration

Good fits

Symfony applications generating page previews

Messenger workers that archive visual states

Back-office tools exporting pages to images

Teams wanting framework-native error handling

A Symfony service with clear responsibilities

Keep transport details in one client and business rules in the calling application or message handler.

Configuration

Inject endpoint and credential from environment-backed secrets rather than controller input.

Destination rule

Resolve a domain object to a URL or validate an explicitly supplied target.

Transport contract

Use HttpClient status checks, timeouts, and structured response handling.

Asynchronous option

Dispatch repeatable jobs to Messenger when capture should survive a web request.

Implementation workflow

Create a reusable Symfony capture client

Bind the API key through Symfony secrets or deployment configuration

Inject HttpClientInterface into a dedicated service

Validate destination and request options before transport

Persist the asset and capture context in a handler

Symfony screenshot API example

PHP

Call Snapshot Site with HttpClient

The service sends the documented authentication header and fails explicitly on a non-success response.

use Symfony\Contracts\HttpClient\HttpClientInterface;

final class SnapshotClient
{
    public function __construct(
        private HttpClientInterface $http,
        private string $apiKey,
    ) {}

    public function capture(string $url): array
    {
        $response = $this->http->request('POST',
            'https://api.prod.ss.snapshot-site.com/api/v1/screenshot',
            [
                'headers' => [
                    'x-snapshotsiteapi-key' => $this->apiKey,
                ],
                'json' => [
                    'url' => $url,
                    'format' => 'webp',
                    'width' => 1440,
                    'height' => 900,
                    'fullSize' => true,
                ],
            ]
        );

        return $response->toArray();
    }
}

Keep controllers free of rendering infrastructure

A controller should authorize the user and hand work to an application service. The Snapshot Site client can then own request serialization, provider authentication, response validation, and normalized exceptions. This keeps capture behavior testable and prevents options from drifting across controllers.

Use value objects or domain identifiers when possible. A capture request for a known invoice or campaign is easier to authorize than an unrestricted URL submitted from the browser.

When Messenger improves reliability

Browser rendering is external work with variable latency. Messenger gives you retry policy, failure transport, worker concurrency, and job observability without holding an HTTP connection open. Make the message contain a stable target identifier and the capture specification, not a secret.

Ensure handlers are idempotent. A redelivered message should either reuse an existing artifact or create a clearly versioned result rather than silently overwriting a valid record.

Security and storage

Validate schemes and destinations before transport. Avoid putting signed URLs or API keys in broadly accessible logs. Download returned artifacts into storage that follows the source document's access and retention rules.

Use the PHP SDK page for a package-oriented workflow, or the cURL guide when debugging the raw HTTP contract.

Snapshot API for Symfony FAQ

Is there a dedicated Symfony package?

You can integrate the REST contract cleanly with Symfony HttpClient. Keep the wrapper small so endpoint changes and error mapping remain centralized.

Where should the API key live in Symfony?

Use Symfony secrets or protected deployment environment configuration and inject it into the service container. Never accept it from a form or controller request.

Should I use Messenger for screenshots?

Use Messenger when captures are slow, retryable, scheduled, or high-volume. A direct controller call can suit a small synchronous action.

How should HttpClient errors be handled?

Differentiate transport failures, non-success HTTP status, invalid response data, and application storage failures. Retry only transient categories.

Can a Symfony command run batch captures?

Yes. A console command can dispatch messages or call the service, but add bounded concurrency and explicit progress reporting for large batches.

How do I test the integration?

Mock HttpClient responses for service tests, then keep a small authorized end-to-end fixture for validating the live rendering contract.

Can it capture a Symfony page behind login?

The renderer needs an accessible authorized state. Use a short-lived signed preview where appropriate; interactive login automation requires a browser automation tool.

What metadata belongs in the database?

Store source entity, target URL policy outcome, viewport, format, timing settings, capture time, result location, and normalized status.

Related resources

Snapshot Site Home Website Screenshot API JavaScript Rendering TypeScript SDK Playwright Screenshot Guide API Documentation Pricing PHP SDK Laravel Screenshot API Error Handling

Create a Symfony capture service

Start with a thin HttpClient wrapper and one authorized target, then add Messenger, storage, and retries as the workload grows.

Get started for free Read the API docs