Module 6 โข Lesson 3๐ Pipelines โ Headless Batch, APIs & QA
The Module 6 deliverable takes the human out of the loop. When thousands of assets must be generated, checked, and shipped, you build a pipeline: Photoshop operations running server-side, driven by APIs, with automated QA gates that reject bad output before it ever reaches a person.
๐ What You'll Learn
By the end of this lesson, you will be able to:
- Explain headless / server-side Photoshop and when it beats the desktop
- Drive processing with the Photoshop API (Firefly Services) via HTTP
- Design a pipeline: ingest โ process โ QA โ deliver
- Write an automated QA gate that rejects off-spec output
- Log, retry, and handle failure so a run completes unattended
โฑ๏ธ Estimated Time: 60 minutes
๐ฏ Project (module deliverable): A designed pipeline with a working QA-gate function that passes good files and flags bad ones.
In This Lesson
๐ค The Goal: Output Without a Human
Two ways to make ten thousand assets. On the right, a person opens, edits, checks, and exports each โ a job measured in weeks and mistakes. On the left, an automated pipeline ingests a queue, processes via the API, runs a QA gate, and delivers only the passes โ measured in hours and unattended. Drag the handle:
๐ง Mental Model: The Assembly Line
A pipeline is an assembly line with a quality inspector. Assets enter a queue (ingest); each is transformed by a script, action, or API call (process); a QA gate checks it against spec and routes passes forward and fails to a review pile; passes are packaged and shipped (deliver). The whole thing runs unattended, logs everything, and retries transient failures. Your craft knowledge lives in the process step; your professionalism lives in the QA gate.
The mindset shift from a batch (Intermediate Module 6) is autonomy plus verification. A batch runs your steps; a pipeline runs them at scale, checks its own work, and is honest about what failed. Silent success on a broken file is worse than a loud failure โ the gate exists to make failure loud.
๐ Headless & the Photoshop API
The desktop app needs a screen and a person; a pipeline needs neither. Adobe's Photoshop API (part of Firefly Services) runs Photoshop operations server-side over HTTP โ you POST a job describing inputs, an action or edit, and an output target, and it returns the rendered result. It even runs your recorded Actions (.atn) and PSD template edits (smart-object and text replacement โ the data-driven idea from Intermediate Module 6, at cloud scale).
// process step: run a recorded Action through the Photoshop API (Node 18+ sketch)
const res = await fetch("https://image.adobe.io/pie/psdService/photoshopActions", {
method: "POST",
headers: { Authorization: `Bearer ${token}`, "x-api-key": CLIENT_ID,
"Content-Type": "application/json" },
body: JSON.stringify({
inputs: [{ href: srcUrl, storage: "external" }],
options: { actions: [{ href: actionUrl, storage: "external", actionName: "Web Delivery" }] },
outputs: [{ href: dstUrl, storage: "external", type: "image/jpeg" }]
})
});
const job = await res.json();
const statusUrl = job._links.self.href; // poll this URL until status is "succeeded" or "failed"
Endpoint paths and payload fields change between API versions (Adobe has been introducing newer endpoints), so treat this as the shape of the call and check the current Photoshop API reference before you build. Access also takes setup: an Adobe Developer Console project with OAuth Server-to-Server credentials and a Firefly Services entitlement (typically an enterprise plan or a trial). Running the desktop app as an unattended "server" isn't a supported or licensed setup; the API is the sanctioned route.
โ ๏ธ Cloud APIs cost money and quota โ design for it
Every API call consumes credits/quota and can fail transiently (network, rate limits). A production pipeline batches sensibly, backs off and retries on 429/5xx, and tracks spend. Test the process step on a handful before you unleash it on ten thousand โ an infinite retry loop on a paid API is an expensive bug.
โ๏ธ The QA Gate
The gate is a function that returns pass or fail with a reason. It encodes the spec you'd otherwise check by eye, and each deliverable gets its own spec. A web delivery checks pixel dimensions, color mode and profile, file size, and no empty/blank output. A print delivery is a different gate: CMYK mode, the press profile, total ink under the limit (Module 5), and enough ppi at final size. Passes flow on; fails are logged with the reason for a human. Here's the shape of a web gate:
// qa-gate.js: WEB delivery spec, returns { ok, reasons[] }
function qaCheck(meta) {
const reasons = [];
if (Math.max(meta.width, meta.height) !== 2000) reasons.push("long edge != 2000 px");
if (meta.colorMode !== "RGB") reasons.push("not RGB");
if (meta.iccProfile !== "sRGB IEC61966-2.1") reasons.push("profile is not sRGB");
if (meta.bytes > 5 * 1024 * 1024) reasons.push("file over 5 MB");
if (meta.isBlank) reasons.push("output appears blank");
return { ok: reasons.length === 0, reasons };
}
// A PRINT gate is separate: CMYK mode, press profile,
// total ink (TAC) under the limit, and ppi at final size.
for (const asset of processed) {
const result = qaCheck(asset.meta);
if (result.ok) deliver(asset);
else log.fail(asset.id, result.reasons); // loud, not silent
}
โ A silent pipeline is a dangerous pipeline
The single most important habit: never let the pipeline hide what it dropped or fudged. Log every fail with a reason, report the pass/fail counts at the end, and make failures visible. A run that "completed" while silently shipping blank files is the nightmare the QA gate exists to prevent.
๐ ๏ธ Guided Build: Design a Pipeline
You'll design the flow and implement the one piece that makes it trustworthy โ the QA gate.
Step 1: Map the stages ยท 10 min
- Write out your ingest source, the process step (local script/action vs Photoshop API), the QA spec, and the delivery target.
Step 2: Write the QA gate ยท 16 min
- Adapt
qaCheckto your real spec (dimensions, mode, profile, size; ink and ppi for print). Return pass/fail with reasons. - Test it on known-good and known-bad metadata; confirm it catches each fault.
Step 3: Add resilience ยท 10 min
- Wrap the process step with retry-and-backoff for transient errors, and a per-asset try/catch so one failure doesn't kill the run.
Step 4: Report ยท 6 min
- End the run with a summary: N processed, N passed, N failed (with reasons), N retried. Make the outcome legible at a glance. Module 6 deliverable done. ๐
โ Project Completion Checklist (Module 6 deliverable)
- โ Pipeline stages mapped: ingest โ process โ QA โ deliver
- โ Process step chosen (local script/action or Photoshop API)
- โ A QA gate that returns pass/fail with reasons, tested both ways
- โ Retry/backoff + per-asset error isolation
- โ An end-of-run summary; nothing fails silently
๐ง Now You: Solo Variation
๐ Your challenge
- Extend the QA gate with a "blank/near-blank" check by sampling pixel variance โ the classic catch for a process step that silently failed.
- Design a pipeline that feeds a PSD template from a data source (Intermediate Module 6's variables) via the API, producing personalized assets at scale.
- Add a spend guard that stops the run if API cost passes a budget โ production autonomy with a safety brake.
Going further: wire the pipeline into a scheduler or a watch-folder so dropping files in triggers a run โ a service, not a script you remember to launch.
๐ณ Recipe Card: Pipeline
Automate and verify
- Ingest โ process โ QA โ deliver, with a fail branch to review
- Process locally (script/action) or via the Photoshop API (server-side)
- QA gate per deliverable: dims ยท mode + profile ยท size ยท not-blank (print adds ink + ppi) โ pass/fail + reasons
- Retry/backoff on transient errors; isolate per-asset failures
- Log everything; end with a pass/fail summary โ never silent
Mantra: a pipeline that can't tell you what it dropped can't be trusted.
๐ Learning Journal
Add to your journal after this lesson:
- Key concepts you learned
- Techniques that clicked for you
- Questions or confusion points to revisit
- Ideas you want to try
- Your progress and feelings about learning this
โ๏ธ This lesson's prompt: Write the QA spec for a real deliverable you produce โ the exact, checkable rules a gate would enforce. That list is the difference between a batch and a pipeline.
๐ Module 6 Summary
๐ Key Takeaways
- Scripts add loops and logic Actions can't โ walk the DOM, decide per file, reach further with batchPlay.
- UXP plugins wrap that logic in a real panel: manifest + HTML + JS, edits inside executeAsModal.
- Pipelines run headless via the Photoshop API through ingest โ process โ QA โ deliver.
- The QA gate โ pass/fail with reasons, nothing silent โ is what makes automation trustworthy.
๐ What You've Accomplished โ Across All of Module 6
You've crossed from operating Photoshop to programming it: scripting decisions, shipping tools with a UI, and building self-checking pipelines that produce at scale. This is the highest-leverage skill in the whole course โ it multiplies every other skill you have across thousands of assets, unattended.
โ Common Questions at This Stage
Do I need a server to have a "pipeline"?
No โ a local script that ingests a folder, processes, QA-checks, and exports is a real pipeline. The server/API version is for scale and always-on services. Start local with a QA gate; graduate to the API when volume or uptime demands it.
Isn't this a developer's job, not a designer's?
The line is blurring. A designer who can script and gate their own output is dramatically more valuable and independent. You don't need to be a full engineer โ being the artist who also ships automation is a rare and well-paid combination.
๐ญ Looking Ahead
You can automate the deterministic. Next you handle the probabilistic, professionally: Module 7 โ AI Mastery & Provenance uses generative tools at a controlled, rights-clean, disclosed standard.
โ Before the Next Module
- Ship one script and one panel button that do real work.
- Write and test a QA-gate function for a deliverable you make.
- Write your Learning Journal entry.
๐ Additional Resources
๐ Encouragement for the Journey
Learning to program the tool you already mastered is a genuine force multiplier โ the same hours now produce ten times the output, checked and consistent. Few artists ever make this leap. You just did. One tier left: using AI the way a professional must.