When images flow into your pages through an API, your integration must keep the source license with them. The compliance risk with automated retrieval isn't usually that you set out to break the rules. It's that a pipeline quietly drops the license data on its way to the page, and an automated flow ends up implying rights the license never granted.
This guide shows how to normalize license data from an approved source, preserve it through a pipeline, handle AI-generation disclosure, and block publishing when rights are unclear. It is a vendor-neutral design guide, not documentation for a live Picdrome API. For Picdrome images, the current Picdrome Image License are the authority.
This is general information to help you build responsibly, not legal advice. For anything specific to your project, read the full Picdrome Image License and talk to a qualified professional.
What the license actually covers (and the honest words for it)
Pulling an image through an API does not change what you're allowed to do with it. The delivery method is different; the rights come only from the current source license. For Picdrome images, do not publish unless the Picdrome Image License clearly authorize the intended use and state any attribution requirement.
It's worth being precise about what that does and does not mean, because automation has a way of encoding loose assumptions into code that then runs thousands of times.
API-delivered images are not any of the following:
- Not public domain. They remain covered by the Picdrome license, not released into the public domain.
- Not CC0. They are not dedicated under a Creative Commons CC0 waiver.
- Not "royalty-free" in the paid-licensing sense. You don't buy a separate license, but that's not the same as the royalty-free model some stock sites use.
- Not "unrestricted." The terms include conditions, such as not reselling the images as a competing library and not implying a real person's endorsement.
The reason this matters for an API integration: if your code, your internal docs, or a comment in your pipeline says "these are free, do whatever," that assumption can propagate into how images get used. Treat the API as a delivery mechanism for licensed images, not as a source of rights-free assets. If you want the background on why these labels differ, the post on using free and AI-generated images safely covers it for the general case.
The license field in every API response
Every API response includes a license field for the image. This is the part automation most often loses, because it's easy to map only the fields you immediately need (the image URL, maybe dimensions) and discard the rest.
Don't strip it. The license field is how the terms travel with the image. When you carry it through your pipeline, you keep a record of what governs each asset, and you make it possible to honor those terms downstream instead of guessing later.
Concretely, that means:
- Read the license field, don't ignore it. When you parse a response, keep the license reference alongside the image, not just the binary or the URL.
- Persist it with the image. If you cache or store images, store the license reference too, so the terms stay attached when the image is reused or re-served. Note that this is separate from technical fields like alt text and dimensions; for those, see what image metadata matters when building pages programmatically.
- Point your team at the source. The license field references the full Picdrome Image License. Make sure your integration docs link there rather than restating the terms in your own words, which can drift out of date.
- Don't let a transform discard it. Resizing, recoloring, or re-encoding an image is allowed, but the license still applies to the result. Make sure your processing step carries the license reference forward rather than emitting a "clean" asset with no record of where it came from.
The rule of thumb: the license is data, and like any data your pipeline depends on, dropping it silently is a bug.
Disclosing AI generation when images arrive through code
Picdrome images are AI-generated, and that fact doesn't disappear because the image arrived over HTTP instead of a download button. Honest disclosure is part of using the images responsibly, and automation makes it easy to forget.
The hard line is this: never present an AI-generated person as a real customer, team member, founder, reviewer, or endorser. An AI-generated face is a synthetic likeness, not an actual individual. When images are placed automatically, this risk shows up in templated sections such as testimonial blocks, "our team" grids, or review cards where a face slots in next to a name and a quote. If your automation drops AI-generated portraits into those slots, it can imply a real person stands behind a statement that no real person made.
A few practical habits for code-driven placement:
- Keep AI faces out of identity-claiming slots. Don't let automation route AI-generated people into testimonials, staff bios, or "real customer" sections. Reserve those for images of actual people you have the rights to use.
- Carry a disclosure-ready signal. Where your context calls for labeling synthetic imagery, make sure your pipeline can surface that an image is AI-generated rather than burying it. The full explanation lives on the AI image disclosure page.
- Decide disclosure by context, not by default. A decorative hero or section background usually doesn't need a label. Editorial, news, or any context where the realness of an image carries weight is where disclosure matters most.
For the deeper reasoning on responsible use, the AI image disclosure page covers how the images are made and screened.
What automation must not do
Automation scales whatever rule you encode, including the wrong ones. A single bad assumption in a placement function becomes a pattern across every page it touches. These are the uses to keep out of your pipeline entirely.
| Automation pattern | Why it's a problem | Safer approach |
|---|---|---|
| Routing AI-generated faces into testimonials or reviews | Implies a real person endorses your product | Use only images of people you have rights to in endorsement slots |
| Dropping AI portraits into "our team" or founder bios | Presents a synthetic likeness as a real team member | Use real staff photos for identity sections |
| Re-serving images stripped of their license reference | Loses the terms that govern reuse | Persist the license field with every stored image |
| Labeling images "royalty-free" or "public domain" in your UI or alt text | States rights the license doesn't grant | Use the honest line: free for personal and commercial website projects, subject to the license terms |
| Offering the raw images for others to download | Reselling or redistributing as a competing library isn't permitted | Use images inside your own (or your client's) finished site |
The thread running through all of these: automation must not imply rights, endorsements, or relationships the license never granted. The API grants no broader rights than the standard website license, no matter how the image is delivered.
A pre-ship compliance checklist for API-delivered images
Run this before you ship an integration that places images automatically. It's short on purpose, so it's easy to keep in a code review.
- The pipeline reads the license field from each response and keeps it attached to the image, including through any resize or transform step.
- Stored or cached images keep a reference to the Picdrome Image License, not just the binary.
- No automated flow routes AI-generated people into testimonials, reviews, team bios, or any slot that implies a real individual.
- Your UI, alt text, and internal docs use honest licensing language and never call the images public domain, CC0, royalty-free, or unrestricted.
- Where your context requires it, the integration can surface AI-generation disclosure (see the disclosure page).
- The integration does not redistribute the raw images for others to download as a standalone asset set.
- Your team docs link to the maintained integration design guide and the full Picdrome Image License rather than paraphrasing them.
Before you ship, review the integration design guide and read the full Picdrome Image License end to end. The license is the source of truth; this checklist is a reminder, not a replacement.
When to get professional advice
This guide and the Picdrome license page are written in plain English to help you build responsibly. They are not legal advice. Licensing and disclosure obligations can depend on where you operate, who your audience is, and the specifics of your use.
Get professional advice when your situation goes beyond standard website placement: regulated industries, advertising claims tied to imagery, contexts with formal synthetic-media labeling rules, or anything where the realness of an image carries legal or contractual weight. A qualified professional can tell you what applies to your specific case in a way a general guide can't.
In Plain English
An automated image pipeline must preserve the source, current license record, and AI-generated provenance with every asset. Delivery through code grants no additional rights. For Picdrome images, read the current Picdrome Image License, resolve the attribution rule, and block publishing if the intended use is not clearly authorized. Do not let automation present an AI face as a real customer, team member, or endorser. This article is general information, not legal advice. Before shipping, run the checklist above, read the integration design guide, and get professional advice for anything specific to your project.
Next, see the pillar walkthrough on how to add website images automatically with an image API for the full integration picture.