Skip to main content
If you build presentation software, image retrieval becomes a recurring workflow: turn each slide’s topic into a visual brief, collect candidates, and keep enough source information to review and credit the chosen image. The runnable presentation-image-search example implements the retrieval step with Python 3.10+ and the standard library. It makes three sequential POST /v1/search requests, one per slide topic. It returns existing stock-image candidates for review; it does not render slides or generate images. Save search_slides.py from the linked example directory. These commands match example version 1.0.0 at commit 8bb34d4. Run from the directory containing the script:
Dry-run prints three request bodies without a key or network calls. Each requests five landscape candidates with commercial: true. That filter uses source-declared license permissions. It does not clear every right needed for your intended use. Other API defaults still apply; see search controls. Give each slide its own brief. Describe the subject and useful composition, such as room for a headline. Composition is a search preference, not a guaranteed layout. A search may return fewer than five candidates or none. There is no batch endpoint involved in this example.

​
Run from your backend when ready

Create a Lightdrift account and API key, then supply LIGHTDRIFT_API_KEY through your backend environment or secret manager. Keep it out of source control, browser code and exported presentations. The script reads the environment variable and sends it to the API in the X-API-Key header; see authentication. Check your account’s balance, limits and current pricing before removing --dry-run. This command makes real searches and consumes search entitlement:
The script runs each request after the previous one succeeds. It stops on the first HTTP, transport or response-shape error and does not retry automatically. Earlier successful output lines remain in the file. After an uncertain outcome, inspect account usage before rerunning; rerunning all three topics can repeat earlier successful searches.

​
Turn results into a review queue

candidates.jsonl contains one JSON object per successful slide search: Do not use the first result as automatic approval. Review subject accuracy, dimensions, composition and suitability with the presentation author. A result’s score is not a calibrated probability that it fits the slide. Before using a candidate, open rights.provenance_url and inspect the source’s declaration and license conditions. Review license, license_verbatim, commercial, derivatives, share_alike, attribution_required, attribution and basis. Unknown permissions remain unresolved. Keep required credit and source information with the selected asset and include it in the exported presentation where required. Source declarations do not settle every question about people, logos or artworks; see rights answers. The example does not download source images. If your application later fetches file or thumb, the documented URLs redirect to signed downloads valid for one hour. Follow those download redirects without forwarding your API key to the destination. Preserve the asset ID and source metadata instead of treating an expiring signed link as your permanent selection record.

​
Evaluate one real presentation workflow

After reviewing the dry-run, try the example with three topics from an actual presentation when your account is ready. Record whether a reviewer finds a usable candidate, whether required credit survives export, and what prevents a selection. Measure first successful search, useful selection, repeat workflow use and payment separately from page or repository visits. The guide signup campaign is lig100_presentation_guide_v1. The source example retains its separate lig103_presentation_search_v1 campaign in requests and its README signup link; a random client_session groups its three calls. Keep those identifiers distinct when interpreting the path from guide to example to search. Guide version 1.0.0, September 26, 2026. Request fields and response handling were checked against the current OpenAPI, official docs and the pinned example. Verification used dry-run only, with no paid product calls. No live example execution, retrieval-quality result or customer outcome is claimed.