Stable data contracts for
dynamic content
Generate customized social cards, email headers, and personalized documents from live application data, with global CDN caching and edge delivery.
Free account, no credit card
Dynamic content use cases
Open Graph Images
Render page-specific preview images from approved titles, author assets, branding, and a stable public content version.
Personalized Email Graphics
Create recipient-specific headers or product cards through a private server-side path with controlled storage and delivery.
Dashboard Snapshots
Capture a dashboard state as an image or PDF, then deliver that static snapshot under its own access rules.
User-Generated PDFs
Generate resumes, tickets, receipts, or portfolios from validated application records and return them through the authenticated app.
Localized Content
Supply locale, translated copy, date rules, and currency values per request, then test text expansion and font coverage.
Real-Time Data Visuals
Render charts and data cards from a validated metric snapshot with the time and source version recorded.
How dynamic content works
Define the template and field contract
Create the HTML and Nunjucks layout, name required values, and test conditions, loops, long content, missing assets, and locales.
Validate data and choose execution
Load approved public or private values on your server, then choose synchronous, asynchronous, or pre-rendered generation.
Apply delivery, cache, and privacy rules
Return bytes, retrieve a stored asset, or handle a job result. Cache only where the key and audience make reuse safe.
Choose execution from the caller's deadline
Use a synchronous response only when the caller can wait for a representative cold render. Use an async job when the application can show progress, continue other work, or deliver the file later.
Choose managed storage, own-storage delivery, or a non-persistent mode from the documented request behavior and plan. Verify retention and purge timing before using those settings for private content.
For repeatable public images, place your own delivery endpoint and CDN policy in front of the stored result. Normalize cache keys, version content changes, and prevent private responses from entering a shared cache.
Synchronous Response
Receive the finished output in the request path when measured render time fits the caller's timeout.
Asynchronous Job
Store the job id, consume its webhook, and use the Jobs API to recover missed status.
Managed Storage
Retrieve eligible stored output through the Assets API within plan allowance and configured retention.
Application-Owned Caching
Define cache keys, headers, expiry, invalidation, audience, and fallback behavior at your delivery layer.
Dynamic content examples
Dynamic OG image endpoint
- Your app builds a public URL from an opaque content id and version.
- Your server validates the key and loads approved title, author, image, and brand data.
- It calls cloudlayer.io and receives or retrieves the rendered image.
- Your delivery layer applies fallback, cache, and response rules for social crawlers.
Personalized email header
- Your private workflow selects the recipient and approved offer.
- Your server validates the data and calls cloudlayer.io without exposing it in a public URL.
- The workflow receives the supported response form and builds the email asset.
- Delivery and persistence follow the campaign's privacy and retention rules.
Choose cache and access rules from the audience
“Dynamic” describes how values enter the render, not who may see the result. Classify the asset before choosing a URL, cache, storage, and expiry policy. Reusing one public delivery pattern across all four cases below can expose private content or erase most cache value.
Public and shared
A page preview may be identical for every reader. Give each approved content version a stable public key, render it ahead when practical, and let the CDN reuse the stored result.
Public but frequently versioned
A price card or campaign image can remain public while changing on a schedule. Put the approved version in the cache key and define how old objects expire or are invalidated.
Private per recipient
An account statement or personalized offer must not enter a shared public cache. Generate behind authentication and use private storage, short-lived access, or direct server delivery.
Internal snapshot
A dashboard capture freezes data at a point in time. Record that time and source version, then apply the same access and retention rules as the underlying report or audience.
Add one automated test that requests the same public key twice and another that attempts to cross recipient boundaries. Cache efficiency matters, but isolation is the requirement that must never be traded away to get it.
Does rendering on demand mean a render per page view?
Not when your delivery cache serves a valid stored response before the request reaches the renderer. A view can still reach the origin after a miss, expiry, invalidation, bypass, or new cache key. Measure render requests and cache behavior separately from page traffic.
Each distinct image is rendered once. Traffic past that point costs nothing.
- Renders a month
- 800
- Served from cache
- 99% of views
- Views per render
- 125
Starter at 1,000 renders covers this, at $9 a month.
Move the traffic control and watch the render count stay where it is. Move the variety control and watch it climb. In short: you are billed for how many different documents exist, not for how many people look at them.
What does an Open Graph image endpoint need to get right?
The destination crawler fetches, crops, and caches the image according to rules outside your application. Treat size, format, timeout, cache key, fallback, and content version as part of the endpoint contract, then verify previews on the destinations you support.
- Size
- Use a named profile based on the dimensions published for each supported destination
- Safe area
- Test where each destination crops, overlays controls, or displays the card at smaller sizes
- Type size
- Choose a minimum from the final preview size and test long titles rather than one mock headline
- Response
- Measure crawler-facing latency and serve a stable fallback when the cold path can exceed its timeout
- Format
- Choose a supported image format after comparing text clarity, photographs, and file size
- Stability
- Keep a URL stable for one content version and change its version key when the approved image changes
Avoid placing live timestamps, view counts, or other changing values behind an unchanged public cache key. Either exclude them from the card or include an intentional content version in the key. Then define how old versions expire and how crawlers receive a fallback during regeneration.
How should the endpoint be shaped?
Give each public image an address that identifies its content version without exposing the underlying private record. Normalize the key and define which request values affect the response rather than allowing arbitrary query combinations to fragment the cache.
Why the URL carries a public key
A CDN commonly includes the URL in its cache key. Use a stable content id, template or profile version, and other normalized public variants needed to identify the output.
An addressable image is easier to inspect and re-fetch. Keep the server-side mapping from that key to approved title, author, image, and brand data under your control.
What to keep out of the URL
Keep names, emails, order values, secrets, access tokens, and other private values out of URLs. Use an opaque identifier only when the endpoint can safely expose the result to anyone who obtains that address.
Do not add random cache-busting parameters to normal requests. Change the version only when the approved output changes, and retire older versions according to policy.
How fast does the first request have to be?
It must fit the timeout of the caller you support, including your own network and delivery overhead. Do not assume only the first request renders: expiry, invalidation, concurrent misses, failures, and new versions can all reach the cold path.
Render public assets when content is approved
If the public content set is known, render and store the image during the publish workflow. The crawler then fetches a prepared asset rather than starting generation. Track failures before marking the page ready for sharing.
For a catalog or release set, batch the known versions and verify both render and cache population. A CDN serves later requests only while its key, policy, and object remain valid.
Define a stable fallback
When on-demand rendering may miss the caller's timeout, decide which approved static image to return and how long it can be cached. Log the fallback so the failed dynamic version remains visible to operators.
An async job can prepare the final image outside the crawler request. Store the job id, recover missed status through the Jobs API, publish the completed asset, and invalidate or version the fallback according to your cache design.
Should the endpoint return a URL or the bytes?
Choose the response form from the next consumer. Crawlers and CDNs need an addressable image. Application code may need bytes or base64 for composition. Private outputs also need access, expiry, and storage rules independent of their encoding.
- Share cards
- An addressable public image at the tested destination profile because the crawler fetches it separately
- Use the delivery form your email platform and target clients support, with recipient privacy preserved
- PDF assembly
- Bytes or base64 when your server immediately composes the image into another controlled document
- Server-side composition
- Use the supported binary response that avoids an unnecessary public fetch and matches your library
- Anything cached
- An addressable stored object with a normalized cache key, explicit headers, expiry, and invalidation
- Your own archive
- Route to supported own storage with the business id, path, access, and delivery status recorded
- Retina output
- Use device scale only when the displayed size, clarity requirement, and file budget call for it
- Format
- Compare supported formats with the actual mix of text, graphics, photographs, transparency, and file size
A share-card metadata field needs an address the crawler can fetch. Keep base64 or raw bytes inside server-side workflows that consume them directly, and avoid placing private assets at public URLs merely to make them addressable.
Questions, answered
How do I build a dynamic Open Graph image endpoint?
Have your server validate a public cache key or opaque content identifier, load the approved content, and call the image API with the selected template. Apply your own access, cache, fallback, and response policy before serving crawlers.
Can I personalize images per recipient?
Yes, but keep private recipient data out of public URLs and shared caches. Generate from server-side data, choose the required persistence mode, and make sure the delivery path cannot expose one recipient’s result to another.
Is it fast enough to render on demand?
Measure the cold render with representative templates and assets. For repeatable public content, render ahead of demand or cache the result behind an application-owned CDN policy. Use a fallback where the caller has a strict timeout.
How many renders does an on-demand endpoint use?
Each finished image uses 1 render. A correctly configured cache can serve repeat requests without another render while the cached object remains valid, but misses, expiry, invalidation, changed keys, or bypasses can render again. Measure origin requests rather than assuming views equal renders.
What size should an Open Graph image be?
Use the dimensions and format published by the destinations you support, and test their crop and preview behavior. Store the chosen size as a named profile so it can change without rewriting page content or endpoint logic.
Why should the parameters go in the URL?
A CDN commonly uses the URL as part of its cache key, but you control the exact policy. Put only public, normalized cache-key values or an opaque identifier in the URL. Never expose private recipient or order data in query parameters.
What breaks caching without anybody noticing?
A cache key that omits a value affecting the output can serve stale or incorrect content. Unnormalized parameters can create needless variants. Define the full public key, version it when content changes, and test expiry, invalidation, and concurrent misses.
Can I return images as base64?
Yes. Choose the response form supported by the endpoint and next consumer. Use bytes or base64 for server-side composition, and an addressable stored asset when a browser, crawler, or CDN must fetch and cache the image.
Test one dynamic asset path
from data to delivery
Verify the template, field contract, privacy boundary, cold render, cache key, fallback, response, and storage behavior.
No credit card required.