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 running headless on a server, 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 โ export โ 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 โ call the Photoshop API (pseudo-Node)
const res = await fetch("https://image.adobe.io/pie/psdService/documentOperations", {
method: "POST",
headers: { Authorization: `Bearer ${token}`, "x-api-key": KEY,
"Content-Type": "application/json" },
body: JSON.stringify({
inputs: [{ href: srcUrl, storage: "external" }],
options: { actions: [{ href: actionUrl, actionName: "Web Delivery" }] },
outputs: [{ href: dstUrl, storage: "external", type: "image/jpeg", quality: 8 }]
})
});
const { jobId } = await res.json(); // poll jobId until status === "succeeded"
โ ๏ธ 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: correct dimensions and aspect, right color mode and profile, resolution in range, total ink under limit (Module 5), file size sane, and no empty/blank output. Passes flow on; fails are logged with the reason for a human. Here's the shape of it:
// qa-gate.js โ returns { ok, reasons[] }
function qaCheck(meta) {
const reasons = [];
if (meta.width !== 2000) reasons.push("width != 2000");
if (meta.colorMode !== "RGB") reasons.push("not RGB (expected sRGB delivery)");
if (meta.dpi < 72) reasons.push("resolution too low");
if (meta.bytes > 5 * 1024 * 1024) reasons.push("file over 5 MB");
if (meta.maxInk && meta.maxInk > 300) reasons.push("total ink over 300%");
if (meta.isBlank) reasons.push("output appears blank");
return { ok: reasons.length === 0, reasons };
}
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, size, ink). 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: dims ยท mode ยท resolution ยท size ยท ink ยท not-blank โ 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.