DRUPAL INTEGRATION

Add rendered-page evidence to Drupal publishing workflows

Call Snapshot Site from a custom module, queue worker, Drush command, or external job. Keep the key out of themes, resolve canonical content URLs, and preserve revision context with every artifact.

PHP server
Private request
Revisions
Content context
Queues
Scalable capture
Install:Drupal HTTP client + Queue API
Auth:SNAPSHOT_SITE_API_KEY
Get started for free
Drupal publishing capture
Snapshot Site themed Drupal screenshot API illustration
Good fits
Editorial QA after content publication
Visual archives tied to node revisions
Responsive review of media-heavy templates
Migration verification across Drupal sites

Connect the screenshot to the content revision

A Drupal capture is most useful when it records which node, translation, revision, theme, and viewport produced the rendered evidence.

1

Canonical URL

Resolve the public route through Drupal rather than accepting an unrestricted target from a form.

2

Cache awareness

Capture only after render, page, and edge caches expose the intended revision.

3

Responsive media

Wait for image styles, lazy media, fonts, and client behaviors used by the active theme.

4

Queue execution

Use Queue API or another worker for batches and work that should survive a web request.

Implementation workflow

Add a Drupal capture service

1

Inject the API key from protected Drupal or deployment configuration

2

Resolve a published entity and language to its canonical absolute URL

3

Dispatch a queue item after the desired revision is available

4

Store the artifact with entity, revision, locale, viewport, and capture time

Drupal screenshot API example

PHP

Call Snapshot Site with Drupal's HTTP client

A custom service can wrap transport while a queue worker owns authorization, entity resolution, and storage.

$response = $this->httpClient->post(
  'https://api.prod.ss.snapshot-site.com/api/v1/screenshot',
  [
    'headers' => [
      'Content-Type' => 'application/json',
      'x-snapshotsiteapi-key' => $this->apiKey,
    ],
    'json' => [
      'url' => $canonicalUrl,
      'format' => 'webp',
      'width' => 1440,
      'height' => 900,
      'fullSize' => TRUE,
      'hideCookie' => TRUE,
      'delay' => 1,
    ],
    'timeout' => 45,
  ],
);

$result = json_decode((string) $response->getBody(), TRUE);

Rendered evidence belongs to a revision

Drupal already models content entities, revisions, translations, workflows, and canonical routes. A screenshot job should carry those identifiers rather than receiving only a URL. This lets an editor connect the artifact to the content state that was approved or published.

Resolve the absolute public URL on the server. It is easier to authorize and audit than an unrestricted destination submitted from a browser form.

Respect the cache path

A successful save does not mean every visitor-facing cache contains the new revision. Coordinate capture with render cache, page cache, reverse proxy, CDN, and image-style generation. The correct trigger may be a queue item created after publication and released only when the intended route is observable.

Responsive media also depends on viewport. Store width and language because they can change the selected image and layout.

Use queues for editorial reliability

Queue workers survive the page request and provide a place for retry, concurrency, and status. Make the handler idempotent so redelivery does not silently overwrite the approved artifact. Record terminal failures where editors or operators can act.

Unpublished pages need an authorized preview design. A persistent bypass link is not an acceptable substitute for access control. Apply the same permissions and retention to screenshots as to the content they represent.

Use the PHP SDK for package-oriented server integration and compliance archiving for provenance, retention, and review policy.

Screenshot API for Drupal FAQ

Where should Drupal call the screenshot API?

Use a custom service invoked by a queue worker, Drush command, event subscriber, or another trusted server-side path.

Should a theme contain the API key?

No. Themes and browser JavaScript are not secret storage. Inject the key into a server-side service from protected configuration.

How do I connect a screenshot to a revision?

Store entity type, entity ID, revision ID, language, canonical URL, theme context, viewport, and capture time with the result.

When should capture run after publishing?

Wait until Drupal and any reverse-proxy or CDN caches serve the intended revision, then dispatch the job through a dependable queue.

Can it capture unpublished content?

Use a narrowly scoped, short-lived preview that the renderer can reach and that follows editorial authorization. Avoid durable access tokens.

How are responsive images handled?

The browser selects sources from the rendered viewport. Set width deliberately and wait for image styles and lazy media to complete.

Should every node be captured?

Start with high-value content types and representative templates. Expand based on publishing risk and archive requirements.

How should failures be retried?

Retry only transient network, rate, or provider conditions with backoff and a cap. Do not retry invalid targets or authentication errors unchanged.

Capture one Drupal content type end to end

Tie the artifact to a published revision and verify cache, media, locale, and access behavior before expanding coverage.