Add an optional Latchshot public-page screenshot block

[BaiqingL]

Add an optional Latchshot public-page screenshot block

Duplicates

• I searched the existing issues for Latchshot, ScreenshotOne, and screenshot provider and did not find this proposal.

Summary 💡

Disclosure: I directly maintain Latchshot, the service proposed below.

Would you accept a separate provider-specific block for bounded public-page screenshots through Latchshot?

The current ScreenshotWebPageBlock should remain unchanged. The proposed block would:

• keep the API key in AutoGPT's existing API-key credential field;
• call only the fixed POST https://latchshot.fly.dev/v1/render origin with Bearer authentication;
• accept a public HTTP/HTTPS URL, 320–2560 × 240–1440 viewport, PNG/JPEG output, full-page mode, JPEG quality, and the service's bounded cleanup controls;
• require an image/png or image/jpeg response and reject artifacts above 15 MB;
• pass the direct response bytes into AutoGPT's existing store_media_file(..., return_format="for_block_output") path; and
• expose no checkout, plan-changing action, arbitrary endpoint, or key in the URL.

This would not be a drop-in replacement for the existing ScreenshotOne block. Latchshot does not support WebP, provider caching, cookies or login state, arbitrary scripts/actions, proxies, private-network pages, CAPTCHA bypass, or anti-bot behavior. The block and its description would keep those stop conditions explicit.

The service currently provides 100 successful renders per UTC calendar month without a card, followed by fixed plans; only successful renders consume quota. Payment and plan activation remain outside the block and are handled by the service owner.

I have not opened an implementation PR because changes under autogpt_platform accept Determinist Ltd's CLA. I am asking for block/design fit first; no CLA-bound PR should be created until the Latchshot owner separately reviews and authorizes that legal gate.

Examples 🌈

• Public OpenAPI 3.1 contract: https://latchshot.fly.dev/openapi.json
• Data handling and retention: https://latchshot.fly.dev/data-handling.html
• Bounded implementation/pilot contract: https://latchshot.fly.dev/implementation-pilot.html

The transport shape would be:

response = await api.post(
    "https://latchshot.fly.dev/v1/render",
    json={
        "url": url,
        "format": format.value,
        "width": viewport_width,
        "height": viewport_height,
        "fullPage": full_page,
    },
    headers={"Authorization": f"Bearer {credentials.api_key.get_secret_value()}"},
)

The implementation would validate the response media type and size before creating the existing MediaFileType output. Tests would mock the fixed request and assert the exact body, protected Authorization header, response validation, and stored media output.

Motivation 🔦

AutoGPT already proves the screenshot-to-MediaFileType workflow through its ScreenshotOne block. A separate Latchshot block would give builders an explicitly public-page-only option with a fixed origin, direct artifact bytes, bounded inputs, and no browser runtime to operate inside their graph.

The narrower contract is the reason to keep this separate rather than add a provider switch to the existing block. If maintainers prefer no additional screenshot provider, or want a different provider abstraction first, that answer would avoid an unnecessary implementation and CLA-bound pull request.