DEV Community: Iteration Layer

Automating Content Operations for Professional Services Teams

Iteration Layer — Mon, 04 May 2026 21:19:51 +0000

The Work Is Too Specific for Enterprise Software

Small and mid-sized teams run on operational content.

A law firm receives NDAs, contracts, court filings, and client intake forms. A dental clinic handles referral letters, insurance documents, treatment plans, invoices, and patient forms. An accounting firm processes supplier invoices, receipts, bank statements, and monthly reports. A real estate office turns listing documents, photos, appraisal PDFs, and property descriptions into client-ready materials.

None of this looks like a major transformation project. It is just work. Repetitive work, usually owned by one person who knows all the exceptions.

That is why it survives.

The workflow is too specific for a generic enterprise platform, too valuable to ignore, and too messy for one built-in automation node. So the team builds a patchwork: one OCR service, one LLM prompt, one spreadsheet export, one PDF generator, one folder full of naming rules, and a few n8n document automation Code nodes that only one person understands.

The first version saves time. The second version becomes another system to maintain.

Content Operations Are Not Just Document Processing

The common mistake is to describe the job too narrowly.

If a lawyer wants to process incoming client documents, the job is not "extract text from PDFs." The job is intake, classification, term extraction, review, checklist generation, and filing.

If a dental clinic wants to handle referrals, the job is not "OCR a scanned form." The job is reading the referral, extracting patient and treatment details, routing missing information, generating an admin summary, and attaching it to the right internal workflow.

If an accountant wants to automate month-end work, the job is not "parse invoices." The job is collecting documents, extracting fields, detecting exceptions, generating review spreadsheets, and producing a report the client can understand.

Content operations are the workflows that turn messy business inputs into usable internal or client-facing outputs.

That usually crosses several formats:

PDFs, scans, images, DOCX files, spreadsheets, emails, and web pages as inputs.
Structured fields, Markdown, review tasks, spreadsheets, PDFs, and summaries as outputs.
Human review where the automation cannot safely decide.

That is why isolated tools disappoint. OCR is useful, but it is only one step. Extraction is useful, but the workflow still needs review and output. A generated PDF is useful, but only if the data feeding it can be trusted.

Automation Breaks Where Tools Disagree

The fragile parts are not always large codebases.

In n8n, Make, Zapier, or scripts, the fragile parts often appear as small fragments:

A Code node that renames fields before the next service accepts them.
A prompt that turns OCR text into JSON because the OCR service only returns text.
A date formatting expression copied across five workflows.
A temporary file upload so another vendor can fetch the output.
A retry branch that handles one vendor's timeout shape.
A spreadsheet formula that compensates for inconsistent extracted values.

None of those pieces look dangerous alone. The problem is that every piece becomes part of the workflow contract.

If the extraction output changes, the spreadsheet mapping breaks. If the review branch stores corrected values in a different shape, the PDF generation step fails. If a vendor returns a vague error, the automation cannot decide whether to retry, reject, or ask a human.

This is where operational knowledge hides. It is also where small teams lose the time they thought automation would save.

Build Around the Case File, Not the Tool

The practical fix is to stop designing the workflow around tools and start designing it around the business object.

For a legal workflow, the business object might be:

Client document review package:
- Original document
- Extracted parties, dates, obligations, and risky clauses
- Confidence and review status
- Internal checklist
- Client-ready summary PDF

For a dental referral workflow, it might be:

Referral intake package:
- Original referral form or email attachment
- Patient and referring-provider details
- Treatment request and urgency
- Missing-information checklist
- Admin summary for scheduling

For accounting, it might be:

Month-end document package:
- Supplier invoices and receipts
- Extracted totals, dates, VAT IDs, and line items
- Exception list for review
- XLSX tracker
- Client summary report

Once the business object is clear, the workflow can be evaluated by a better question: can every step produce output the next step can use without reinterpretation?

That question changes tool selection. A single-purpose OCR service may extract text well but leave you to structure it. A document parser may return fields but no source evidence. A PDF generator may work but require another mapping layer. A spreadsheet export may be useful but require manual formatting before review.

For content operations, the winning automation is rarely the one with the fewest nodes. It is the one with the fewest hidden translation layers.

Design Review as Part of the Workflow

Many SMB automations fail because they pretend human review is a temporary problem.

In professional-services workflows, review is normal. The goal is not to remove every human decision. The goal is to reserve human attention for the cases where it matters.

For document-heavy content operations, that usually means confidence routing:

High-confidence required fields continue automatically.
Low-confidence money, date, identity, or clause fields route to review.
Missing required fields stop the workflow with a clear reason.
Corrected values resume from the last safe step.

For legal workflows, a risky clause should route to a human. For dental workflows, missing patient identifiers should stop scheduling. For accounting workflows, uncertain totals or tax IDs should be checked before they update a ledger or client report.

If review lives outside the automation, the workflow becomes hard to audit. Someone checks a Slack thread, edits a spreadsheet, reruns a node manually, and nobody knows which value was approved.

Make review a visible branch. Store the decision. Preserve the source document. Include enough context that the reviewer can act without opening execution logs.

The low-confidence routing guide for n8n covers this pattern for document fields. The same principle applies across content operations: automate the obvious cases, route the uncertain cases, and keep the path explicit.

Unify the Processing Core

n8n and similar tools are good at orchestration. They should describe the business process: intake, validation, extraction, review, generation, delivery.

They should not have to translate between five content-processing vendors.

For SMB workflows, unifying the processing core has practical benefits:

One credential to manage for extraction, conversion, generation, and sheet output.
One credit pool for workloads that shift between documents, forms, reports, and spreadsheets.
One error style for retry and review branches.
One file-handling pattern for inputs and generated outputs.
One place to inspect usage when a manager or client asks what the automation costs.

This does not mean every node should come from one vendor. Triggers, databases, storage, notifications, CRMs, practice-management tools, and ERPs will still be separate systems. That is normal. The important part is to keep the content-processing core consistent.

If the workflow starts with messy files and ends with usable documents, sheets, summaries, or reports, the steps in the middle should share a contract.

Three Content Operations Workflows That Benefit

The pattern shows up in many small teams and professional-services firms. Here are three common examples.

Legal: Client Documents to Review Package

Input: NDAs, contracts, court filings, intake forms, or uploaded client documents.

Workflow:

Validate file type and matter metadata.
Convert long documents to Markdown for readable review.
Extract parties, dates, obligations, jurisdiction, and risky clauses.
Route uncertain or high-risk clauses to a lawyer or paralegal.
Generate an internal checklist or client-ready summary PDF.

Output: a review package instead of a folder of raw attachments.

Useful starting points: extract NDA terms, extract NDA and generate checklist, and convert contract to Markdown.

Dental and Clinic Admin: Referrals to Scheduling Summary

Input: referral letters, scanned forms, treatment plans, patient questionnaires, insurance documents, and emailed attachments.

Workflow:

Validate that the referral has the required patient and provider information.
Extract patient details, referring provider, treatment request, urgency, and insurance references.
Route missing or uncertain fields to admin review.
Generate a scheduling summary and attach the source reference.
Produce a spreadsheet or report for daily intake review.

Output: a clean intake package that staff can act on without rereading every attachment.

Useful starting points: extract medical record, convert document for knowledge base, and generate PDF report.

Accounting: Client Documents to Month-End Pack

Input: supplier invoices, receipts, purchase orders, bank statements, and client emails.

Workflow:

Extract invoice and receipt fields.
Route low-confidence totals, dates, or VAT IDs to review.
Generate an XLSX tracker for internal reconciliation.
Generate a PDF summary for the client.
Store outputs with source references for audit.

Output: approved accounting data, an exception list, and client-ready month-end materials.

Useful starting points: extract invoices to spreadsheet, extract receipts to expense report, and invoice-to-PDF report.

Where Iteration Layer Fits

Iteration Layer is built for SMB workflows where processing the file is only part of the job.

Document Extraction returns structured fields with confidence scores and source citations. Document to Markdown converts documents into readable Markdown when the workflow needs full text. Document Generation and Sheet Generation turn approved data into PDFs, DOCX files, XLSX trackers, CSV files, or Markdown tables.

The workflow benefit is consistency. Same credential. Same credit pool. Same API style. Outputs designed to feed the next step.

The n8n integration exposes those capabilities inside a workflow builder. If your team works in code instead, the same platform is available through the REST API and SDKs.

The Content Operations Checklist

Before automating the next document-heavy workflow, ask:

What business object should exist at the end of the workflow?
Which inputs are valid, invalid, or ambiguous?
Which fields can be accepted automatically?
Which cases need review before they continue?
What output artifact does the team or client actually use?
How many vendors sit inside the processing core?
Can the workflow retry from a safe boundary?
Can you explain the monthly cost without reconciling several dashboards?

If the workflow only saves time on the first clean file, it is not ready. If it handles messy inputs, review, generated outputs, and failure states without a pile of translation nodes, it can become part of daily operations.

SMB content automation does not need enterprise ceremony. It needs a clear workflow, fewer hidden seams, and tools that agree on what moves between steps.

Why We Rebuilt Iteration Layer in Elixir

Iteration Layer — Mon, 04 May 2026 21:19:44 +0000

The Problem Changed

The first version of Iteration Layer was written in TypeScript. That was the obvious choice at the time. The product looked like a normal web app with a normal API surface: accept a request, call a model or processing library, return a response.

That shape did not last.

Content-processing infrastructure does not behave like a CRUD app once people start using it for real work. A single user upload can turn into document ingestion, OCR, schema extraction, image transformation, document generation, spreadsheet output, retries, confidence checks, and webhook delivery. Some requests are quick. Some are slow. Some fail halfway through because a PDF is malformed, an image is huge, a model call times out, or a downstream step needs to be retried without duplicating work.

The problem stopped looking like "build an API around AI models." It started looking like a distributed systems problem.

So we chose Elixir for the platform we launched.

Not because TypeScript is bad. Not because Elixir is magic. We rebuilt because the operational shape of the product changed, and Elixir gave us better primitives for the system we were actually building.

TypeScript Was Good for the First Version

TypeScript was the right way to get the first product into the world. The ecosystem is excellent for API development, SDK generation, frontend work, and shipping quickly. A small team can move fast because every part of the stack speaks the same language.

For the earliest version, that mattered more than anything else. We needed to prove that developers wanted composable content-processing APIs. We needed to build the first document extraction, image transformation, and generation workflows. We needed to learn where the architecture would break before choosing the launch stack.

TypeScript helped with that. But once the product shape was clear, we chose the runtime we wanted to operate for years before putting Iteration Layer in front of users.

The problems appeared later, when the product moved from individual API calls to complete workflows. The hard part was no longer "can we expose this operation over HTTP?" The hard part was "can we run many long-lived, failure-prone, multi-step jobs at the same time and keep the system understandable when something breaks?"

Those are different engineering problems.

AI Workflows Are Mostly Coordination

Most AI infrastructure discussions focus on models. Which model is best. Which prompt format works. Which provider has the lowest latency.

Those choices matter, but they are not where most of the engineering time goes in a production workflow.

The engineering time goes into coordination:

Accepting files from different sources without blocking request handlers
Running CPU-heavy and I/O-heavy steps without starving the rest of the system
Retrying transient failures without duplicating side effects
Timing out slow steps without losing the job state
Isolating one customer's bad batch from everyone else
Reporting progress and errors in a way humans can act on
Keeping memory bounded when files are large or many jobs run at once

A simple request like "extract this invoice and generate a summary report" hides a full workflow. The visible product is one API call. The system underneath is a set of supervised processes coordinating file handling, external calls, parsing, validation, billing, logging, and cleanup.

TypeScript can do this. We did do this. But the more coordination logic we wrote, the more we were rebuilding ideas that the BEAM has treated as first-class concerns for decades.

Supervision Is a Product Feature

The biggest mindset shift was supervision.

In many web stacks, a crashed worker is treated as an exceptional event. You add process managers, queues, retry libraries, health checks, and alerting around the application to keep it alive. The language runtime is not where most of that operational model lives.

In Elixir, supervision is part of the design vocabulary. Processes are cheap. Failure is expected. The question is not "how do we prevent anything from crashing?" It is "what should restart, what state should survive, and what should be isolated?"

That maps directly to content-processing workflows.

If a single document extraction job fails because the input is corrupted, that failure should not affect other jobs. If a temporary provider error hits one step, that step should retry with clear limits. If a background worker crashes, it should restart without taking the API down. If a queue backs up, the system should degrade predictably instead of turning into a pile of stuck promises and mystery memory growth.

Supervision is not an implementation detail when reliability is part of the product. Customers do not care whether the system used a clever retry helper. They care that their invoice batch does not disappear at 2 AM because one malformed PDF hit an edge case.

Concurrency Without Turning Everything Into a Framework

Iteration Layer runs workflows that mix different kinds of work.

Document extraction is file-heavy and model-heavy. Image transformation can be CPU-heavy. Document generation can involve rendering, fonts, layout, and binary output. Webhook delivery is network-heavy. Billing and usage tracking must be consistent even when processing steps fail.

These tasks do not all have the same latency profile, resource profile, or failure profile. Treating them as one generic background job category makes the system harder to reason about.

Elixir lets us model this more directly. A workflow can be broken into processes with clear responsibilities. Supervisors define what restarts. Queues define backpressure. Tasks can be isolated by operation type. The runtime gives us visibility into what is running instead of forcing every concern through the same event loop.

This maps well to a platform built around composability.

Our APIs are designed to chain: extract data from a document, generate a spreadsheet, produce a PDF report, transform images for the final output. The product promise is not that one operation works in isolation. The promise is that the pipeline holds together when multiple operations run in sequence.

The runtime should make that easier, not harder.

Long-Running Work Needs a Different Shape

HTTP requests are a poor mental model for long-running AI work.

Some calls finish quickly. Others depend on document size, page count, file format, model latency, and downstream generation. A workflow may need to stream files, call external systems, wait for a model, transform output, and deliver a webhook. Forcing all of that into a request-response mindset creates pressure in the wrong places.

You start extending timeouts. Then you add background jobs. Then you add polling. Then you add status records. Then you add retries. Then you add cleanup. Eventually the real product is the workflow engine around the API call.

Elixir is a better fit for that shape. The request can validate input and enqueue work. The processing steps can run under supervision. State can move through a controlled lifecycle. Failures can be explicit instead of buried in logs. The web layer and the processing layer can live in the same application without pretending they are the same kind of work.

That last part is important. We do not want a separate microservice for every operation just to get isolation. We want a system where isolation is cheap enough to use inside the application.

The BEAM gives us that.

A Small Language Is Easier for Agents

Another reason that mattered more than we expected: Elixir is small and standardized.

Iteration Layer is built in the same era as AI coding agents. We use agents while building the product, and we expect more of the surrounding ecosystem to be created by agents over time: SDK examples, integration snippets, workflow definitions, MCP tool descriptions, test cases, and internal maintenance work.

That changes the value of a language and framework stack.

TypeScript gives you many ways to solve the same problem. That flexibility is useful for humans, but it can make agent-generated code noisy. One file uses one async pattern, another uses a different framework convention, another pulls in a helper library for something the runtime already covers. The language is not the problem. The surface area is.

Elixir gives agents fewer reasonable paths. Pattern matching, pipelines, modules, behaviours, supervision trees, Ecto changesets, Phoenix contexts, Oban jobs. The conventions are narrow enough that generated code is easier to review, easier to correct, and easier to align with the existing codebase.

The product itself is agent-native. We ship MCP support because agents are becoming a normal way to build and operate workflows. The implementation stack should work well with the same tools we expect our users to adopt.

Rust Is the Escape Hatch

Content processing eventually hits work that should not be written in a high-level application language.

PDF parsing, image processing, layout rendering, format conversion, and model-adjacent operations can cross into CPU-heavy or library-heavy territory. Sometimes the right answer is not to force everything into the web stack. Sometimes the right answer is Rust.

Elixir makes that boundary practical through NIFs, especially with Rustler. We can keep orchestration, supervision, queues, billing, API shape, and workflow state in Elixir while moving performance-sensitive or systems-level code into Rust when needed.

This split is cleaner than pretending one language should do everything. Elixir coordinates. Rust handles the parts where memory control, native libraries, or raw performance matter. The BEAM still owns the reliability model around that work.

For Iteration Layer, that is important because the product spans formats and workloads. A malformed PDF, a strange image format, or a layout edge case should not force an architectural rewrite. We need an escape hatch that fits the platform, not a sidecar that becomes a second system to operate.

The AI Tooling Is Better Than People Assume

Elixir is not usually the first language people mention for AI infrastructure. Python owns the research ecosystem. TypeScript owns a lot of application-layer AI tooling. But the Elixir ecosystem is stronger than it looks when the job is production AI workflows.

The useful pieces are standardized around the same runtime model as the rest of the application. Nx and EXLA give us tensor and compiler foundations. Ortex gives us a path for ONNX Runtime. Bumblebee gives the ecosystem a standard shape for model loading and inference. Oban handles durable job execution. Phoenix gives us the API and web layer. OTP gives us supervision under all of it.

For our use case, this is more useful than chasing the largest model playground. Iteration Layer is not a notebook. It is a production system that needs to run document, image, generation, and agent workflows for customers without turning every capability into a separate service.

The Elixir stack lets us keep those concerns in one coherent system for longer.

Operational Simplicity Matters More Than Language Preference

A rewrite is expensive. The only good reason to do one is if it removes a class of problems that kept coming back.

For us, the recurring problems were operational:

Too much coordination logic lived in application code
Worker failure behavior was harder to reason about than it should be
Long-running jobs needed clearer lifecycle boundaries
Different operation types needed different concurrency limits
Observability needed to follow workflows, not just HTTP requests

Elixir did not remove the need to design those systems. It gave us better defaults for designing them.

Phoenix gives us a boring, productive web layer. Ecto gives us a clear database layer. Oban gives us durable jobs inside Postgres without adding another moving part for the current scale. OTP gives us the supervision model underneath the parts that should stay alive, restart, or isolate failure.

The result fits the way Iteration Layer is built: self-serve, API-first, workflow-oriented, and operationally lean.

Where Elixir Fits the Product

The product we are building is not a single-purpose OCR API. It is a composable content-processing platform. Customers use one auth token, one credit pool, and one API style to chain operations across documents, images, websites, spreadsheets, and generated outputs.

That positioning has technical consequences.

If a customer only needs one isolated operation, a specialized tool may be better. A point OCR service can go deeper on one document type. A dedicated image CDN can go deeper on global delivery. A cloud giant can offer a wider marketplace.

Iteration Layer wins when the workflow spans multiple steps and the customer wants fewer vendors, fewer credentials, fewer billing systems, and fewer glue layers.

Elixir is a good fit for that bet because it is built around systems that keep running. The language encourages explicit boundaries, message passing, supervision trees, and small processes that do one job. Those ideas match a platform where the product is the pipeline, not any one API call.

Why This Is the Launch Stack

We launched on Elixir because AI infrastructure becomes distributed systems infrastructure faster than you expect.

At the prototype stage, the model call looks like the product. In production, the model call is one step in a longer pipeline. The hard parts become backpressure, retries, observability, isolation, cleanup, data boundaries, and failure handling.

Content workflows make those problems obvious. Files are messy. PDFs are strange. Images arrive in formats nobody tested. Documents have missing fields, bad scans, unexpected layouts, and tables that break assumptions. The platform has to absorb that mess without making every customer rebuild the same operational shell around each API.

Elixir does not make those problems disappear. It gives us a runtime, language, and ecosystem that match them: supervised processes, explicit concurrency, durable jobs, a practical Rust boundary, and standard AI tooling that fits inside the application.

That is why Iteration Layer launched on Elixir, not the original TypeScript stack.

Get Started

If you are building workflows that extract data, transform files, generate outputs, or connect tools through MCP, try Iteration Layer with a free account. Start with one API, then add the next step when the workflow needs it. The APIs share authentication, credits, response patterns, and error handling so the second step does not become another integration project.

The docs cover the API surface, the MCP guide covers agent workflows, and the n8n guide covers automation-builder workflows.

Sheet Generation API: Structured JSON In, Formatted Spreadsheet Out

Iteration Layer — Thu, 30 Apr 2026 00:24:53 +0000

Spreadsheet Generation Is Still Painful

Every application eventually needs to export data as a formatted spreadsheet. Financial reports, inventory lists, invoices, analytics dashboards — at some point, someone asks for an Excel file and you start searching for libraries.

If you work in JavaScript, you find ExcelJS or SheetJS. Python has openpyxl. Ruby has caxlsx. Java has Apache POI. Each one has a different API surface, different quirks, and different failure modes. The common thread: they're all verbose. Generating a simple XLSX with headers, currency formatting, and a SUM formula takes dozens of lines of boilerplate — cell references, style objects, merge ranges, format strings.

CSV is simpler but limited. No formatting, no formulas, no multiple sheets. You get a flat text file and hope the recipient's spreadsheet app guesses the delimiter correctly.

And if you need both formats? You maintain two separate code paths. One for XLSX with its style objects and cell references. One for CSV with its string concatenation. Both doing the same conceptual thing — turning rows of data into a spreadsheet — in completely different ways.

One API Call, Three Formats

The Iteration Layer Sheet Generation API takes a single JSON payload describing your spreadsheet and returns a formatted file. The same payload produces XLSX, CSV, or Markdown — you just change the format field.

Here's the simplest possible request:

import { IterationLayer } from "iterationlayer";
const client = new IterationLayer({
  apiKey: "YOUR_API_KEY",
});

const result = await client.generateSheet({
  format: "xlsx",
  sheets: [
    {
      name: "Q1 Revenue",
      columns: [
        {
          name: "Company",
        },
        {
          name: "Region",
        },
        {
          name: "Revenue",
        },
      ],
      rows: [
        [
          {
            value: "Acme Corp",
          },
          {
            value: "North America",
          },
          {
            value: 48500.00,
            format: "currency",
            currency_code: "USD",
          },
        ],
        [
          {
            value: "Globex Ltd",
          },
          {
            value: "Europe",
          },
          {
            value: 37200.00,
            format: "currency",
            currency_code: "EUR",
          },
        ],
      ],
    },
  ],
});

{
  "success": true,
  "data": {
    "buffer": "UEsDBBQAAAAIAA...",
    "mime_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
  }
}

The response contains the file as a base64-encoded buffer with the appropriate MIME type. Decode it, save it, send it to a client — the file is ready to open in Excel, Google Sheets, or Numbers.

The Data Model

The API uses a positional model. You define columns, then provide rows as ordered arrays of cells. Each cell has a value and optional formatting.

Columns define the header row. Each column has a name and an optional width:

{
  "columns": [
    {
      "name": "Product",
      "width": 30
    },
    {
      "name": "Units Sold"
    },
    {
      "name": "Unit Price"
    },
    {
      "name": "Total"
    }
  ]
}

Cells carry the data. At minimum, a cell has a value. Add format to control how it's displayed:

{
  "value": 1500.50,
  "format": "currency",
  "currency_code": "USD"
}

Supported cell formats: text, number, decimal, currency, percentage, date, datetime, time, and custom.

Number styles control how digits are grouped. Four styles cover the major international conventions:

comma_period — 1,234.56 (US, UK, most of Asia)
period_comma — 1.234,56 (Germany, Brazil, most of Europe)
space_comma — 1 234,56 (France, Norway, Sweden)
space_period — 1 234.56 (Estonia, South Africa)

Date styles control how date, datetime, and time values are formatted. Pass any Excel date format code — dd/mm/yyyy for European dates, mm/dd/yyyy for US, d mmmm yyyy for full month names, hh:mm for short times. The format code is applied natively in XLSX and rendered to the equivalent string in CSV and Markdown.

Currency codes follow ISO 4217. The API supports 162 codes — from USD and EUR to THB and CLP — and maps each one to its correct symbol.

Styles: Base and Per-Cell

Instead of styling every cell individually, you define base styles for headers and body rows, then override specific cells as needed.

import { IterationLayer } from "iterationlayer";
const client = new IterationLayer({
  apiKey: "YOUR_API_KEY",
});

const result = await client.generateSheet({
  format: "xlsx",
  styles: {
    header: {
      is_bold: true,
      font_size_in_pt: 12,
      background_color: "#1a1a2e",
      font_color: "#ffffff",
      horizontal_alignment: "center",
    },
    body: {
      font_size_in_pt: 10,
    },
  },
  sheets: [
    {
      name: "Styled Report",
      columns: [
        {
          name: "Item",
        },
        {
          name: "Amount",
        },
      ],
      rows: [
        [
          {
            value: "Server costs",
          },
          {
            value: 4200.00,
            format: "currency",
            currency_code: "USD",
            styles: {
              font_color: "#cc0000",
            },
          },
        ],
      ],
    },
  ],
});

{
  "success": true,
  "data": {
    "buffer": "UEsDBBQAAAAIAA...",
    "mime_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
  }
}

The styles.header and styles.body objects set defaults. The styles field on individual cells overrides them. Available style properties include font_family, font_size_in_pt, is_bold, is_italic, font_color, background_color, horizontal_alignment, and number_format.

For XLSX output, you can also embed custom fonts by including a fonts array with base64-encoded font buffers.

Formulas

Cells whose value starts with = are treated as formulas. In XLSX output, they're written as native Excel formulas — Excel evaluates them when the file opens. In CSV and Markdown output, the API evaluates them server-side and writes the computed result.

The server-side evaluator supports SUM, AVERAGE, COUNT, MIN, and MAX on cell ranges.

{
  "sheets": [
    {
      "name": "Invoice",
      "columns": [
        {
          "name": "Description"
        },
        {
          "name": "Amount"
        }
      ],
      "rows": [
        [
          {
            "value": "Design work"
          },
          {
            "value": 3200,
            "format": "currency",
            "currency_code": "USD"
          }
        ],
        [
          {
            "value": "Development"
          },
          {
            "value": 8500,
            "format": "currency",
            "currency_code": "USD"
          }
        ],
        [
          {
            "value": "QA testing"
          },
          {
            "value": 1500,
            "format": "currency",
            "currency_code": "USD"
          }
        ],
        [
          {
            "value": "Total"
          },
          {
            "value": "=SUM(B2:B4)",
            "format": "currency",
            "currency_code": "USD"
          }
        ]
      ]
    }
  ]
}

In XLSX, the Total cell contains =SUM(B2:B4) and Excel computes it. In CSV, the API evaluates the formula and writes 13200. Same input, correct output in every format.

Cell Merging

Cells can span multiple columns and rows using from_col, to_col, from_row, and to_row. This works in XLSX output for building headers that span columns or summary rows that stretch across a table.

{
  "value": "Q1 2026 Financial Summary",
  "from_col": 0,
  "to_col": 3,
  "styles": {
    "is_bold": true,
    "horizontal_alignment": "center",
    "font_size_in_pt": 14
  }
}

The Pipeline: Extract Then Generate

The Sheet Generation API is designed to compose with the Document Extraction API and Document to Markdown. A common workflow: you receive invoices as PDFs, extract the line items, and generate a consolidated spreadsheet. For dense layouts or RAG-style full-text preparation, convert the document to markdown first and use that context alongside structured extraction.

import { IterationLayer } from "iterationlayer";
const client = new IterationLayer({
  apiKey: "YOUR_API_KEY",
});

// Step 1: Extract invoice data
const extraction = await client.extractDocument({
  file: invoicePdfBase64,
  schema: {
    vendor: {
      type: "text",
    },
    invoice_number: {
      type: "text",
    },
    line_items: {
      type: "array",
      items: {
        description: {
          type: "text",
        },
        quantity: {
          type: "number",
        },
        unit_price: {
          type: "currency",
        },
        total: {
          type: "currency",
        },
      },
    },
  },
});

const fields = extraction.data.fields;

// Step 2: Generate the spreadsheet
const rows = fields.line_items.value.map((item) => [
  {
    value: item.description.value,
  },
  {
    value: item.quantity.value,
    format: "number",
  },
  {
    value: item.unit_price.value,
    format: "currency",
    currency_code: "USD",
  },
  {
    value: item.total.value,
    format: "currency",
    currency_code: "USD",
  },
]);

const sheet = await client.generateSheet({
  format: "xlsx",
  styles: {
    header: {
      is_bold: true,
      background_color: "#f0f0f0",
    },
  },
  sheets: [
    {
      name: `Invoice ${fields.invoice_number.value}`,
      columns: [
        {
          name: "Description",
        },
        {
          name: "Quantity",
        },
        {
          name: "Unit Price",
        },
        {
          name: "Total",
        },
      ],
      rows,
    },
  ],
});

{
  "success": true,
  "data": {
    "buffer": "UEsDBBQAAAAIAA...",
    "mime_type": "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
  }
}

PDF in, formatted XLSX out. Two API calls, no local dependencies.

Get Started

The Sheet Generation API is available now. Check the docs for the full API reference, including all cell formats, style properties, and formula support.

If you're already using the Document Extraction API, the two compose naturally — extraction output maps directly to sheet rows. If you're starting fresh, the Sheet Generation quickstart is the fastest path to your first generated spreadsheet.

Image Crop API for Smart Cropping and Resizing

Iteration Layer — Thu, 30 Apr 2026 00:24:42 +0000

Every App Needs Image Resizing

User uploads a 4000x3000 photo. Your thumbnail needs to be 200x200. Your product listing needs 800x600. Your social share card needs 1200x630. The original image fits none of these.

You could install Sharp, write the resizing logic, handle edge cases (what if the image is portrait? what if it's smaller than the target?), deploy it, and maintain the server. Or you could make one API call.

The Iteration Layer Image Transformation API resizes and crops images in the cloud. Send an image, define your operations, get the result back. No server, no library, no Docker container.

Resize: Five Fit Strategies

The resize operation takes a target width, height, and a fit strategy that determines how the image fills the target dimensions:

import { IterationLayer } from "iterationlayer";

const client = new IterationLayer({
  apiKey: "YOUR_API_KEY",
});

const { data: { buffer: imageBase64 } } =
  await client.transformImage({
    file: {
      type: "url",
      name: "photo.jpg",
      url: "https://example.com/photo.jpg",
    },
    operations: [
      {
        type: "resize",
        width_in_px: 800,
        height_in_px: 600,
        fit: "cover",
      },
    ],
  });

{
  "success": true,
  "data": {
    "buffer": "/9j/4AAQSkZJRgABAQAAAQ...",
    "mime_type": "image/jpeg"
  }
}

The five fit strategies:

cover — scales the image to fill the target dimensions, cropping any overflow. The result is exactly width x height with no empty space. Best for thumbnails and cards where you need an exact size.
contain — scales the image to fit entirely within the target dimensions, adding letterboxing if the aspect ratios don't match. The result is at most width x height. Best when you need the full image visible.
fill — stretches the image to exactly width x height, ignoring aspect ratio. Best for backgrounds or abstract patterns where distortion doesn't matter.
inside — scales down to fit within the target dimensions, preserving aspect ratio, never upscaling. The result may be smaller than the target. Best for constraining maximum dimensions.
outside — scales so the image covers the target dimensions, preserving aspect ratio, never downscaling. The result may be larger than the target. Best when you want to guarantee minimum dimensions.

Choosing the Right Fit Strategy

The fit strategy you pick depends on what you're building. Here's how each one maps to common use cases.

cover for thumbnails and cards. When you need a grid of identically-sized images — product listings, team member cards, gallery thumbnails — cover guarantees every image is the exact same dimensions. The tradeoff is that parts of the image may be cropped. For product photos shot against clean backgrounds, the crop is usually imperceptible. For portraits, combine cover with smart_crop to keep faces visible.

contain for previews and lightboxes. When users expect to see the entire image — document previews, artwork displays, lightbox modals — contain preserves everything. The image sits within a bounding box, so you may get letterboxing (bars on the sides or top/bottom). Pair it with the extend operation and a background color to fill the letterbox area with a solid color instead of transparency.

inside for upload constraints. When users upload images and you need to cap the dimensions without upscaling small images, inside is the right fit. A 4000x3000 photo resized with inside at 1920x1080 becomes 1440x1080. A 800x600 photo stays at 800x600. This is what you want for content management systems where you need to limit bandwidth without distorting smaller images.

outside for minimum size guarantees. When a downstream process requires a minimum resolution — print workflows, large-format displays — outside ensures the image is at least the target dimensions. The result may be larger, which you can then crop to exact size.

Crop: Extract a Region

The crop operation extracts a rectangular region from the image:

const operations = [
  {
    type: "crop",
    left_in_px: 100,
    top_in_px: 50,
    width_in_px: 500,
    height_in_px: 400,
  },
];

This cuts a 500x400 rectangle starting at position (100, 50) from the top-left corner. Useful when you know exactly which region of the image you need.

Manual crop is common in image editors and annotation tools where the user draws a selection rectangle. Your frontend captures the coordinates, and the API does the extraction.

Smart Crop: Let AI Find the Subject

Manual cropping requires knowing where the subject is. The smart_crop operation handles that automatically — it uses AI object detection to find the main subject (a face, a product, a focal point) and crops around it:

const operations = [
  {
    type: "smart_crop",
    width_in_px: 400,
    height_in_px: 400,
  },
];

The result is a 400x400 image with the subject centered. No coordinate math, no face detection library, no guesswork about where to crop.

Smart crop is particularly useful for:

Profile pictures — always centers the face
Product thumbnails — keeps the product in frame regardless of the original composition
Content cards — finds the focal point of editorial images

The difference between resize with cover and smart_crop is intelligence. cover crops from the center. smart_crop crops around the detected subject. For images where the subject isn't centered — a person standing to the left, a product in the bottom-right corner — smart crop produces noticeably better results.

Responsive Images with Resize

Modern web development requires multiple sizes of every image. A hero image might need five variants for different screen widths. The resize operation handles this naturally:

import { IterationLayer } from "iterationlayer";

const client = new IterationLayer({
  apiKey: "YOUR_API_KEY",
});

const widths = [320, 640, 960, 1280, 1920];

const variants = await Promise.all(
  widths.map(async (width) => {
    const { data: { buffer } } = await client.transformImage({
      file: {
        type: "url",
        name: "hero.jpg",
        url: sourceUrl,
      },
      operations: [
        {
          type: "resize",
          width_in_px: width,
          height_in_px: Math.round(width * 0.5625),
          fit: "cover",
        },
        {
          type: "convert",
          format: "webp",
          quality: 85,
        },
      ],
    });

    return {
      width,
      buffer: Buffer.from(buffer, "base64"),
    };
  })
);

Five sizes at a 16:9 aspect ratio, all converted to WebP. Use these in a srcset attribute to let the browser pick the right size for each viewport:

<img
  srcset="/images/hero-320.webp 320w,
          /images/hero-640.webp 640w,
          /images/hero-960.webp 960w,
          /images/hero-1280.webp 1280w,
          /images/hero-1920.webp 1920w"
  sizes="100vw"
  src="/images/hero-960.webp"
  alt="Hero image"
>

The browser downloads only the variant that matches the device width, saving bandwidth on mobile and delivering sharp images on high-DPI screens.

Chaining Operations

Resize and crop are often just the start. The API lets you chain supported operations in a single request. Each operation's output feeds into the next:

const operations = [
  {
    type: "resize",
    width_in_px: 1200,
    height_in_px: 900,
    fit: "cover",
  },
  {
    type: "sharpen",
    sigma: 0.5,
  },
  {
    type: "convert",
    format: "webp",
    quality: 85,
  },
];

This resizes to 1200x900, sharpens slightly (common after downscaling), and converts to WebP at 85% quality. One API call, three operations, one result.

Practical Recipes

Thumbnail generation:

const operations = [
  {
    type: "resize",
    width_in_px: 200,
    height_in_px: 200,
    fit: "cover",
  },
  {
    type: "convert",
    format: "webp",
    quality: 80,
  },
];

Constrain to max dimensions (never upscale):

const operations = [
  {
    type: "resize",
    width_in_px: 1920,
    height_in_px: 1080,
    fit: "inside",
  },
];

Smart crop for a social card:

const operations = [
  {
    type: "smart_crop",
    width_in_px: 1200,
    height_in_px: 630,
  },
  {
    type: "convert",
    format: "jpeg",
    quality: 90,
  },
];

Center crop with padding:

const operations = [
  {
    type: "resize",
    width_in_px: 800,
    height_in_px: 600,
    fit: "contain",
  },
  {
    type: "extend",
    top_in_px: 10,
    bottom_in_px: 10,
    left_in_px: 10,
    right_in_px: 10,
    hex_color: "#ffffff",
  },
];

Product image with white background:

const operations = [
  {
    type: "resize",
    width_in_px: 1000,
    height_in_px: 1000,
    fit: "contain",
  },
  {
    type: "remove_transparency",
    hex_color: "#ffffff",
  },
  {
    type: "convert",
    format: "jpeg",
    quality: 90,
  },
];

What's Next

Chain with Image Generation to add watermarks or branded overlays to resized images — same auth, same credit pool.

Get Started

Check the docs for the full operation reference, including current operations and their parameters. The TypeScript and Python SDKs handle file upload and response parsing.

Sign up for a free account — no credit card required. Send an image, try the different fit strategies, and see the results.

Convert Markdown to Styled PDF in n8n

Iteration Layer — Thu, 30 Apr 2026 00:24:13 +0000

The n8n Forum's Most Repeated Question

Search the n8n community forum for "Markdown to PDF" and you will find the same question asked repeatedly, with no satisfying answer. The replies fall into three categories.

"Use a Function node with Puppeteer." This requires a Chromium binary in your n8n environment, headless browser rendering, and a pile of JavaScript to set up page sizes, margins, and print styles. Self-hosted n8n can make this work with enough effort. n8n Cloud cannot — there is no browser binary available.

"Use the HTML-to-PDF community node." These nodes convert raw HTML, not Markdown. You need to convert Markdown to HTML first (another Function node), then style it with inline CSS (another Function node), then pass it to the PDF node. Three nodes of glue code, and the output still looks like a web page printed to PDF — no proper headers, footers, or page numbers.

"Export from Google Docs." Create a Google Doc, write content via the API, export as PDF. This technically works but is not automatable for dynamic content. The Google Docs API for formatting is verbose and fragile, and you are creating throwaway documents just to get a PDF.

None of these produce a professional document with consistent typography, a header on every page, a footer with page numbers, and controlled margins.

Markdown In, Styled PDF Out

Iteration Layer Document Generation accepts Markdown content in paragraph blocks — via the markdown field — and renders it into a fully styled PDF. You control the fonts, page size, margins, header, footer, page numbers, heading styles, link colors, and table styling through a JSON document definition.

The Markdown content goes into "type": "paragraph" blocks with a "markdown" field instead of a "text" field. The rendering engine parses the Markdown and applies your style definitions — headings get your heading font and size, links get your link color, code blocks get your code font, tables get your table styling. The output is a PDF that looks like it came from a design tool, not a browser print dialog.

One API call. Fixed credit cost per document. No browser binary, no HTML intermediate step, no throwaway Google Docs.

The Workflow: Webhook to Styled PDF

Here is what we are building in n8n: a webhook that receives Markdown content, converts it into a styled PDF with headers, footers, and page numbers, and stores the result. Three nodes. No Function nodes. No Puppeteer.

Step 1: Webhook Trigger

Open the n8n canvas and add a new node. Search for "Webhook" and add it.

In the node settings, set the HTTP Method to POST. Set Response Mode to "Last Node" so the workflow returns the generated PDF to the caller. The webhook will accept a JSON body with the Markdown content.

A typical request body:

{
  "title": "Project Status Report",
  "author": "Engineering Team",
  "markdown": "## Executive Summary\n\nThe migration to the new platform is **on track** for the Q2 deadline...\n\n## Milestones\n\n| Milestone | Status | Date |\n|-----------|--------|------|\n| Database migration | Complete | March 15 |\n| API v2 rollout | In progress | April 1 |\n| Legacy deprecation | Planned | May 15 |"
}

The Markdown content comes from wherever your process starts — a CMS, a form submission, a GitHub webhook, a previous workflow step, or a manual API call.

Step 2: Iteration Layer (Document Generation)

Add an Iteration Layer node after the webhook trigger. In the Resource dropdown, select Document Generation. Set the Format to pdf.

In the Document JSON field, define the full document structure. Here is a concrete example that converts the incoming Markdown into a styled PDF with a header, footer, and page numbers:

{
  "metadata": {
    "title": "{{ $json.body.title }}",
    "author": "{{ $json.body.author }}"
  },
  "page": {
    "size": "A4",
    "margin": {
      "top": 80,
      "bottom": 60,
      "left": 50,
      "right": 50
    }
  },
  "styles": {
    "font": {
      "family": "Inter",
      "size": 11,
      "color": "#1a1a2e"
    },
    "headings": {
      "h1": { "size": 24, "color": "#1a1a2e", "margin_bottom": 12 },
      "h2": { "size": 18, "color": "#2d2d44", "margin_bottom": 8 },
      "h3": { "size": 14, "color": "#4a4a6a", "margin_bottom": 6 }
    },
    "links": {
      "color": "#0066cc",
      "underline": true
    },
    "code": {
      "font_family": "JetBrains Mono",
      "background_color": "#f5f5f5",
      "border_radius": 4
    }
  },
  "header": {
    "content": [
      {
        "type": "paragraph",
        "text": "{{ $json.body.title }}",
        "style": {
          "font_size": 9,
          "color": "#888888"
        }
      }
    ],
    "border_bottom": {
      "color": "#e0e0e0",
      "width": 1
    }
  },
  "footer": {
    "content": [
      {
        "type": "paragraph",
        "text": "{{ $json.body.author }} — Page {{page_number}} of {{total_pages}}",
        "style": {
          "font_size": 9,
          "color": "#888888",
          "align": "center"
        }
      }
    ],
    "border_top": {
      "color": "#e0e0e0",
      "width": 1
    }
  },
  "content": [
    {
      "type": "headline",
      "text": "{{ $json.body.title }}",
      "level": 1
    },
    {
      "type": "paragraph",
      "markdown": "{{ $json.body.markdown }}"
    }
  ]
}

The key pieces:

Page setup: A4 with generous margins. The top margin is larger to accommodate the header. Adjust size to "Letter" for US standard.
Styles: Global font, heading hierarchy with decreasing sizes, link styling, and code block formatting. These styles apply to all Markdown content in the document.
Header: Appears on every page. The document title in small gray text with a subtle bottom border. The header sits inside the top margin area.
Footer: Appears on every page. Author name, page number, and total page count — centered with a top border. {{page_number}} and {{total_pages}} are built-in template variables that the rendering engine resolves.
Content: A headline block for the document title, followed by a paragraph block with "markdown" instead of "text". The Markdown field accepts the full Markdown string and renders it according to the style definitions above.

The paragraph block with the markdown field is what makes this work. All Markdown syntax — headings, bold, italic, links, tables, code blocks, lists — renders with your defined styles. No HTML intermediate. No CSS. The JSON definition controls everything.

Step 3: Google Drive / S3 / Email Node

The Iteration Layer node outputs the PDF as n8n binary data. Connect it to whatever storage or delivery node your workflow needs.

Google Drive: Add a Google Drive node, set the operation to "Upload", select the target folder, and map the binary data. The PDF lands in the shared drive.

S3: Add an AWS S3 node, set the bucket and key path, and upload the binary data. Use n8n expressions in the key to include the document title or a timestamp.

Email: Add a Send Email node, configure SMTP or OAuth, and attach the binary data. The recipient gets a styled PDF in their inbox.

Return to caller: If Response Mode on the webhook is set to "Last Node", the PDF binary streams back as the HTTP response. The calling application gets the PDF directly without any intermediate storage.

Chaining: DOCX to Branded PDF

This is where the Markdown approach becomes useful for document conversion. Combine Iteration Layer Document to Markdown with Document Generation to convert any document format into a consistently branded PDF. For public pages where you also need typed metadata, add Website Extraction before generating the final document.

The use case: you receive DOCX files from different teams, each with their own formatting. You need them all in a consistent PDF format with your organization's branding — same fonts, same header, same footer, same page layout.

In n8n, this is two Iteration Layer nodes:

Node 1 (Document to Markdown): Convert the DOCX to clean Markdown. The source formatting is stripped. Headers, tables, lists, and body text come through as Markdown structure.
Node 2 (Document Generation): Take the Markdown output and render it into a styled PDF using your brand's document definition. Every document comes out with the same look, regardless of how the original DOCX was formatted.

The Markdown acts as a normalization layer. Whatever formatting chaos exists in the source document — Comic Sans headings, inconsistent margins, random font sizes — gets reduced to semantic structure. Your document definition then applies consistent styling on top.

Get Started

Install the Iteration Layer community node from the n8n UI — search for n8n-nodes-iterationlayer under Settings > Community Nodes. The Document Generation docs cover all styling options, content block types, header/footer configuration, and template variables. The n8n integration docs walk through every resource and parameter.

Start with a short Markdown string and a minimal document definition — just the content block with a markdown field. Verify the output renders your Markdown correctly. Then add styles, headers, footers, and page numbers incrementally. Once the template looks right, wire it to your content source. Sign up to get your API key.

Process Images From Your Coding Session — Smart Crop, Convert, Compress via MCP

Iteration Layer — Thu, 30 Apr 2026 00:24:06 +0000

Image Processing Shouldn't Break Your Flow

Image processing tasks are small but they interrupt everything. A designer sends over a photo that's the wrong dimensions. A client's logo is a 4MB PNG that needs to be a 40KB WebP. A product photo needs smart-cropping for a thumbnail but the subject is off-center. None of these take more than ten seconds to describe — but each one takes you out of your editor, into a terminal, into an image app, or into a back-and-forth with the designer.

With MCP tool calling, your AI assistant handles it directly. The Iteration Layer Image Transformation API ships as an MCP tool — connect it once, and Claude Code or Cursor can resize images, smart crop, convert, compress, and chain supported operations together from a chat prompt. You describe what you need, the assistant builds the operation sequence, and you get the result without leaving your session.

What MCP Is

Model Context Protocol is an open standard that lets AI assistants discover and call external tools. Think of it as a plugin system for AI — you connect a service, and the assistant can use it when relevant.

When you connect the Image Transformation API as an MCP server, your assistant gains the ability to:

Resize images to specific dimensions
Crop images (including AI-powered smart crop)
Convert between formats (PNG, JPEG, WebP, AVIF)
Chain supported operations in a single request
Apply filters, adjust colors, and optimize file sizes

All from a natural language prompt.

Setting Up in Claude Code

Claude Code supports MCP servers natively. Add the Iteration Layer server with a single command:

claude mcp add iterationlayer --transport http https://api.iterationlayer.com/mcp

The first time you use an Iteration Layer tool, a browser window opens for OAuth authentication. Log in, authorize access, and you're connected. No API keys to manage.

To verify the server is available, start a conversation and ask Claude Code what MCP tools it has access to. You should see transform_image listed among the available tools.

Setting Up in Cursor

Add to your .cursor/mcp.json:

{
  "mcpServers": {
    "iterationlayer": {
      "type": "http",
      "url": "https://api.iterationlayer.com/mcp"
    }
  }
}

Save and restart. The Image Transformation tool is now available in your Cursor AI conversations. Authentication works the same way — OAuth in the browser on first use.

Using It Conversationally

The strength of MCP is that you describe intent, not API parameters. The assistant translates natural language into the right combination of operations.

Resize for a landing page hero:

"Resize this to 1200x630, convert to WebP at 85% quality."

The assistant translates that into two operations — a resize with cover fit and a convert to WebP with quality 85 — and returns the processed image.

Smart crop a product photo:

"Smart crop this product photo to 400x400 — keep the product centered."

The assistant calls the smart_crop operation, which uses AI object detection to find the main subject before cropping. No coordinate math on your part.

Compress for email:

"Make this under 500KB for an email attachment."

The assistant uses the compress_to_size operation, which reduces JPEG quality first, then dimensions, to hit the target file size.

Chain multiple operations:

"Take this PNG, resize it to 800x600 cover, sharpen it slightly, convert to WebP, and make sure it's under 200KB."

That's four operations in one request — resize, sharpen, convert, and compress_to_size. The assistant chains them in the correct order.

Batch processing in conversation:

"I have five product images at these URLs. Resize each to 1000x1000 with contain fit, add a white background, and convert to JPEG at quality 90."

The assistant makes five API calls, each with three operations: resize with contain, remove_transparency with white, and convert to JPEG.

Quick format conversion:

"Convert this screenshot from PNG to AVIF."

A single convert operation. The assistant picks up the format from your description and handles the rest.

Prepare social media variants:

"I need this image as a 1080x1080 square for Instagram and a 1200x630 rectangle for Twitter, both as WebP."

The assistant makes two calls with different resize dimensions, both followed by a WebP conversion.

24 Operations, One Tool

The Image Transformation API supports sequential operations. Through MCP, your assistant can combine them in a single request:

Geometry: resize, crop, smart_crop, extend, trim, rotate, flip, flop
Color: modulate (brightness/saturation/hue), tint, grayscale, invert_colors, auto_contrast, gamma
Quality: blur, sharpen, denoise, threshold, opacity
Output: convert (format + quality), compress_to_size, upscale (2x/3x/4x)
Transparency: remove_transparency

Each operation's output feeds into the next, so "resize then convert then compress" is one API call with three operations. The 30-operation limit is generous — most real tasks need three to five.

What Happens Under the Hood

When you describe an image transformation in natural language, the assistant doesn't just forward your text to the API. It constructs a structured API request with the correct operation types, parameters, and ordering.

For example, when you say "resize this to 800x600 and convert to WebP," the assistant builds:

{
  "file": {
    "type": "url",
    "name": "image.jpg",
    "url": "https://..."
  },
  "operations": [
    {
      "type": "resize",
      "width_in_px": 800,
      "height_in_px": 600,
      "fit": "cover"
    },
    {
      "type": "convert",
      "format": "webp",
      "quality": 85
    }
  ]
}

The assistant makes decisions you didn't specify: it picks cover as the default fit strategy (the most common choice), sets quality to 85 (a sensible default for web images), and orders the operations correctly (resize before convert). If you need different defaults — contain instead of cover, or quality 75 instead of 85 — just say so, and the assistant adjusts.

The MCP server handles authentication, request formatting, and response parsing. The assistant receives the processed image back and can display it in the conversation, save it to a file, or pass it to the next step in your workflow.

Real Workflows Where MCP Shines

During development. You're building a product page and need placeholder images at specific dimensions. Instead of opening Figma or Photoshop, describe the size you need and the assistant transforms the source image on the spot.

Code review with visuals. A PR includes new image assets. Ask the assistant to check the dimensions, convert to the right format, or verify the file size meets your budget — all without leaving the review.

Content creation. You're writing documentation and need to include screenshots. The assistant can resize them to a consistent width, convert to WebP for the web, and sharpen them after downscaling.

Quick fixes. A client emails an image that's too large, the wrong format, or needs a transparent background removed. Describe what you need, and the assistant handles it in seconds.

When to Use MCP vs the API Directly

MCP is ideal for ad-hoc work — resizing an image during development, converting a screenshot, quick-cropping a photo. The assistant handles the API details so you stay focused on your work.

For production pipelines — processing uploads at scale, generating thumbnails for a CMS, optimizing images for a CDN — use the API directly via the TypeScript or Python SDK. The SDK gives you full control over error handling, retries, and integration with your existing codebase.

The dividing line is automation. If you're doing it once or a few times interactively, MCP saves time. If you're doing it thousands of times as part of an automated workflow, the SDK is the right tool.

Get Started

Sign up for a free account at iterationlayer.com — no credit card required. Run the claude mcp add command above, authenticate in the browser, and start transforming images from your next Claude Code or Cursor conversation.

The docs cover every operation, every parameter, and every output format. Start with a simple resize — it's the fastest way to see how conversational image transformation works.

Optimize Product Images for Amazon, Shopify, and the Web

Iteration Layer — Thu, 30 Apr 2026 00:23:58 +0000

Product Images Need to Work for Marketplaces and the Web

If you sell on Amazon or Shopify, image optimization is not just a performance task, it is also a requirements task. Marketplaces impose different background, size, and format rules, and those rules change over time. Then your own site still needs responsive image delivery, modern formats, and smaller files for Core Web Vitals.

This guide covers the broad image optimization workflow behind all of those requirements: format selection, compression, responsive delivery, and automation. If you want the marketplace-specific implementations, start with Optimize Product Image for Amazon or Optimize Product Image for Shopify, then come back here for the deeper optimization framework.

Images Are the Heaviest Part of the Web

Images are often the heaviest part of a web page. For media-heavy sites — e-commerce, real estate, travel, news — unoptimized image payloads can dominate load time, especially on mobile connections.

Google measures this. Largest Contentful Paint (LCP) — the time until the largest visible element renders — is a Core Web Vital that directly affects search ranking. For most pages, the largest element is an image. Slow images mean lower rankings, higher bounce rates, and fewer conversions.

Image optimization isn't a nice-to-have. It's the single highest-impact performance improvement for most websites. This guide covers the complete workflow: choosing formats, compressing effectively, sizing for different screens, and building automated pipelines.

Image Formats: Choosing the Right One

Four formats dominate the web. Each has a specific use case.

JPEG

The workhorse of web images since 1992. Lossy compression with a quality parameter (1-100) that controls the size-quality tradeoff. Universal browser support.

Use for: photographs, complex images with many colors, images where a small quality loss is acceptable.

Quality guidelines: 80-90 for hero images, 70-80 for thumbnails and cards, 60-70 for background images.

Limitations: no transparency, no lossless mode, compression artifacts visible at low quality settings (blocky patterns around edges).

PNG

Lossless compression. Supports transparency (alpha channel). Files are significantly larger than JPEG for photographs.

Use for: screenshots, graphics with sharp edges and text, images requiring transparency, icons and logos.

Limitations: large file sizes for photos (3-5x larger than equivalent JPEG), no lossy mode for size reduction.

WebP

Developed by Google, now supported by 97%+ of browsers. Offers both lossy and lossless modes, plus transparency. 25-34% smaller than JPEG at equivalent quality.

Use for: everything on the web where browser support isn't a concern. WebP should be your default format.

Quality guidelines: 80-85 for general web images, 75 for thumbnails, 85-90 for hero images.

Limitations: slightly less saturated colors than JPEG at very low quality settings, some older tools don't support it.

AVIF

The newest contender. Based on the AV1 video codec. 50% smaller than JPEG in many cases. Supports transparency, HDR, and wide color gamut. 92%+ browser support.

Use for: hero images and product photos where maximum compression matters. Best results on photographic content.

Quality guidelines: 65-75 for general use (AVIF maintains quality at lower numbers than JPEG), 75-80 for hero images.

Limitations: slower to encode than WebP, slightly less browser support, some edge cases with very detailed textures.

The Decision Framework

For most websites, the hierarchy is:

Serve AVIF when the browser supports it (hero images, product photos)
Fall back to WebP for broad compatibility
Fall back to JPEG for legacy contexts (email, old systems)
Use PNG only when you need lossless quality or transparency

Implement this with the <picture> element:

<picture>
  <source srcset="/images/hero.avif" type="image/avif">
  <source srcset="/images/hero.webp" type="image/webp">
  <img src="/images/hero.jpg" alt="Hero image" width="1200" height="800">
</picture>

Compression: Finding the Quality Sweet Spot

Compression quality has diminishing returns. The difference between quality 100 and quality 90 is invisible to most viewers. The file size difference is 40-60%.

The Quality Curve

At quality 100, you're storing nearly every pixel perfectly. At quality 90, you're losing imperceptible detail. At quality 80, most viewers can't tell the difference from the original. Below quality 60, artifacts become visible — blocky patterns in JPEG, color banding in WebP.

The practical sweet spots by format:

Format	High quality	Standard web	Thumbnails	Background
JPEG	90	80-85	70-75	60-70
WebP	90	80-85	75	65-70
AVIF	80	65-75	60-65	50-60

AVIF maintains visual quality at lower numbers than JPEG and WebP — a quality 70 AVIF often looks as good as a quality 85 JPEG.

Compress to a Target File Size

Sometimes the requirement isn't "quality 85" — it's "under 500KB." Email attachment limits, mobile app asset budgets, CMS upload restrictions.

The Iteration Layer Image Transformation API has a compress_to_size operation that handles this:

import { IterationLayer } from "iterationlayer";
const client = new IterationLayer({ apiKey: "YOUR_API_KEY" });

const result = await client.transformImage({
  file: {
    type: "url",
    name: "photo.jpg",
    url: sourceUrl,
  },
  operations: [
    {
        type: "compress_to_size",
        max_file_size_in_bytes: 500_000,
    },
  ],
});

{
  "success": true,
  "data": {
    "buffer": "iVBORw0KGgoAAAANSUhEUg...",
    "mime_type": "image/jpeg"
  }
}

The operation uses a quality-first strategy: it reduces JPEG quality from 85 down to 50. If the image is still over the target, it reduces dimensions. Quality-first preserves visual quality better than dimension-first because quality reduction removes imperceptible detail, while dimension reduction removes visible content.

Resizing: Never Serve Larger Than Display Size

A 4000x3000 photo displayed at 800x600 wastes 96% of its pixels. The browser downloads 5 MB to display 300 KB worth of content. This is the most common image performance mistake.

Resize to Display Size

If your hero image displays at 1200px wide on desktop, serve a 1200px wide image. Not the 4000px original from the photographer.

const result = await client.transformImage({
  file: {
    type: "url",
    name: "hero.jpg",
    url: sourceUrl,
  },
  operations: [
    {
      type: "resize",
      width_in_px: 1200,
      height_in_px: 800,
      fit: "cover",
    },
    {
      type: "convert",
      format: "webp",
      quality: 85,
    },
  ],
});

{
  "success": true,
  "data": {
    "buffer": "iVBORw0KGgoAAAANSUhEUg...",
    "mime_type": "image/webp"
  }
}

Fit Strategies

The fit parameter controls how the image fills the target dimensions:

cover — scales to fill the target, crops overflow. Result is exactly the target dimensions. Best for thumbnails, cards, hero images — anything needing exact dimensions.
contain — scales to fit within the target, adds letterboxing. Result is at most the target dimensions. Best when the full image must be visible.
inside — scales down to fit within the target, preserves aspect ratio, never upscales. Best for constraining maximum dimensions.
fill — stretches to exactly the target dimensions. Distorts the image. Rarely what you want.
outside — scales to cover the target, preserves aspect ratio, never downscales. Best for guaranteeing minimum dimensions.

For most web use cases, cover (exact dimensions, cropped) and inside (constrained, not cropped) handle everything.

Responsive Images: Different Sizes for Different Screens

A 4K monitor needs a larger image than a phone screen. Serving the desktop image to mobile wastes bandwidth. Serving the mobile image to desktop looks blurry.

srcset and sizes

HTML's responsive image attributes let the browser choose the right image size:

<img
  srcset="/images/hero-320.webp 320w,
          /images/hero-640.webp 640w,
          /images/hero-960.webp 960w,
          /images/hero-1280.webp 1280w,
          /images/hero-1920.webp 1920w"
  sizes="100vw"
  src="/images/hero-960.webp"
  alt="Hero image"
  width="1920"
  height="1080"
>

The srcset tells the browser which sizes are available. The sizes tells the browser how wide the image will be at the current viewport. The browser picks the smallest image that covers the display area.

Generating Responsive Variants

Generate all variants from a single source image:

import { IterationLayer } from "iterationlayer";
const client = new IterationLayer({ apiKey: "YOUR_API_KEY" });

const widths = [320, 640, 960, 1280, 1920];

const variants = await Promise.all(
  widths.map(async (width) => {
    const result = await client.transformImage({
      file: {
    type: "url",
    name: "hero.jpg",
    url: sourceUrl,
  },
      operations: [
        {
          type: "resize",
          width_in_px: width,
          height_in_px: Math.round(width * 0.5625),
          fit: "cover",
        },
        {
            type: "sharpen",
            sigma: 0.5,
        },
        {
      type: "convert",
      format: "webp",
      quality: 85,
    },
      ],
    });
  })
);

Five sizes, WebP format, optimized quality, sharpened after downscaling. Each variant is a single API call.

Art Direction with picture

When different aspect ratios are needed for different screen sizes — landscape on desktop, square on mobile — use the <picture> element:

<picture>
  <source media="(max-width: 768px)" srcset="/images/hero-mobile.webp" type="image/webp">
  <source media="(min-width: 769px)" srcset="/images/hero-desktop.webp" type="image/webp">
  <img src="/images/hero-desktop.jpg" alt="Hero image">
</picture>

Generate the mobile variant with different dimensions or a different crop. The smart_crop operation is useful here — it detects the subject and crops around it, so the focal point is preserved across aspect ratios.

// Mobile: square crop, subject-centered
const mobileResult = await client.transformImage({
  file: {
    type: "url",
    name: "hero.jpg",
    url: sourceUrl,
  },
  operations: [
    {
      type: "smart_crop",
      width_in_px: 640,
      height_in_px: 640,
    },
    {
      type: "convert",
      format: "webp",
      quality: 85,
    },
  ],
});

// Desktop: landscape, standard resize
const desktopResult = await client.transformImage({
  file: {
    type: "url",
    name: "hero.jpg",
    url: sourceUrl,
  },
  operations: [
    {
      type: "resize",
      width_in_px: 1920,
      height_in_px: 1080,
      fit: "cover",
    },
    {
      type: "convert",
      format: "webp",
      quality: 85,
    },
  ],
});

{
  "success": true,
  "data": {
    "buffer": "iVBORw0KGgoAAAANSUhEUg...",
    "mime_type": "image/webp"
  }
}

Sharpening After Downscaling

Downscaling images softens them slightly — a 4000px image resized to 800px loses some perceived sharpness even though the content is identical. A light sharpen pass after resizing restores crispness without introducing artifacts.

const result = await client.transformImage({
  file: {
    type: "url",
    name: "photo.jpg",
    url: sourceUrl,
  },
  operations: [
    {
      type: "resize",
      width_in_px: 800,
      height_in_px: 600,
      fit: "cover",
    },
    {
        type: "sharpen",
        sigma: 0.5,
    },
    {
      type: "convert",
      format: "webp",
      quality: 85,
    },
  ],
});

{
  "success": true,
  "data": {
    "buffer": "iVBORw0KGgoAAAANSUhEUg...",
    "mime_type": "image/webp"
  }
}

Keep the sigma low — 0.3 to 0.7. Higher values create visible halos around edges that look worse than the softness you're trying to fix.

Order matters: sharpen after resize, convert last. Sharpening before resize wastes effort (the resize will soften it again). Converting before the final step may introduce artifacts that get amplified by later operations.

Smart Cropping for Responsive Thumbnails

Traditional center-cropping works when the subject is centered. It fails when the subject is off to one side — a portrait where the person stands left of frame, a product photo with the item in the lower-right corner.

The smart_crop operation uses AI object detection to find the main subject before cropping:

const result = await client.transformImage({
  file: {
    type: "url",
    name: "photo.jpg",
    url: sourceUrl,
  },
  operations: [
    {
      type: "smart_crop",
      width_in_px: 400,
      height_in_px: 400,
    },
    {
      type: "convert",
      format: "webp",
      quality: 80,
    },
  ],
});

{
  "success": true,
  "data": {
    "buffer": "iVBORw0KGgoAAAANSUhEUg...",
    "mime_type": "image/webp"
  }
}

The result is a 400x400 image with the subject centered, regardless of where it was in the original. No coordinate math, no face detection library, no per-image manual adjustment.

Automated Pipelines

The Basic Pipeline

A production image optimization pipeline combines resizing, sharpening, and conversion:

import { IterationLayer } from "iterationlayer";
const client = new IterationLayer({ apiKey: "YOUR_API_KEY" });

const result = await client.transformImage({
  file: {
    type: "url",
    name: "image.jpg",
    url: sourceUrl,
  },
  operations: [
    {
      type: "resize",
      width_in_px: 800,
      height_in_px: 533,
      fit: "cover",
    },
    { type: "auto_contrast" },
    {
        type: "sharpen",
        sigma: 0.5,
    },
    {
      type: "convert",
      format: "webp",
      quality: 85,
    },
  ],
});

{
  "success": true,
  "data": {
    "buffer": "iVBORw0KGgoAAAANSUhEUg...",
    "mime_type": "image/webp"
  }
}

Four operations, one API call. Resize, auto-contrast, sharpen, convert. No server to maintain.

The Complete Pipeline with Variants

For a production content pipeline, generate multiple formats and sizes from each source image:

import { IterationLayer } from "iterationlayer";
const client = new IterationLayer({ apiKey: "YOUR_API_KEY" });

const generateImageSet = async (sourceUrl: string) => {
  const widths = [320, 640, 960, 1280, 1920];
  const formats = ["webp", "avif"] as const;

  const variants = await Promise.all(
    formats.flatMap((format) =>
      widths.map(async (width) => {
        const quality = format === "avif" ? 70 : 85;
        const result = await client.transformImage({
          file: {
    type: "url",
    name: "image.jpg",
    url: sourceUrl,
  },
          operations: [
            {
              type: "resize",
              width_in_px: width,
              height_in_px: Math.round(width * 0.667),
              fit: "cover",
            },
            {
                type: "sharpen",
                sigma: 0.5,
            },
            {
              type: "convert",
              format,
              quality,
            },
          ],
        });
      })
    )
  );

  return variants;
};

This generates 10 variants (5 widths x 2 formats) from a single source image. Upload each variant to your CDN and reference them in srcset and <source> elements.

Measuring Performance

Core Web Vitals

Three metrics that matter for image optimization:

Largest Contentful Paint (LCP) — time until the largest element renders. Smaller images load faster. Target: under 2.5 seconds.

Cumulative Layout Shift (CLS) — layout instability caused by elements loading and shifting content. Set width and height on <img> tags so the browser reserves space before the image loads. Target: under 0.1.

First Contentful Paint (FCP) — time until any content renders. Large images on the critical rendering path delay FCP. Lazy-load below-the-fold images.

Lighthouse

Run Lighthouse audits regularly. The "Opportunities" section flags specific images that could be resized, compressed, or converted to modern formats. It estimates the byte savings for each suggestion.

Real User Monitoring

Lab tools like Lighthouse test under controlled conditions. Real user monitoring (Vercel Analytics, web-vitals library, Google CrUX) shows actual performance across real devices and connections. An image that loads fine on fiber may be the bottleneck on 3G.

Lazy Loading

Images below the fold — not visible when the page first loads — should lazy-load. The browser fetches them only when they scroll into view.

<img src="/images/product.webp" alt="Product" loading="lazy" width="400" height="400">

The loading="lazy" attribute is supported by all modern browsers. No JavaScript needed.

Do NOT lazy-load the hero image or any above-the-fold content. Those images are on the critical rendering path — they need to load immediately.

CDN Delivery

Serve optimized images from a CDN (Content Delivery Network). The CDN caches images at edge locations close to the user, reducing latency.

Most CDNs support cache headers. Set a long Cache-Control max-age on image URLs that include a content hash — the URL changes when the image changes, so stale cache isn't a concern:

Cache-Control: public, max-age=31536000, immutable

This tells the browser and CDN to cache the image for one year without revalidation.

Putting It All Together

A complete image optimization workflow:

Upload — accept the original image (any format, any size)
Process — resize to target dimensions, sharpen, convert to WebP and AVIF
Generate variants — multiple sizes for responsive delivery
Store — upload processed variants to object storage (S3, R2, GCS)
Serve — deliver through a CDN with long cache headers
Reference — use srcset, sizes, and <picture> in your HTML

Steps 2-3 are the API calls. Steps 4-6 are your infrastructure. The processing itself is one API call per variant — no servers to scale, no libraries to patch, no image processing infrastructure to maintain.

Get Started

Check the docs for the full operation reference and format-specific quality guidelines. The TypeScript and Python SDKs handle file input and response parsing.

Sign up for a free account — no credit card required. Take your heaviest page image, run it through the pipeline, and measure the before-and-after file size.

Compose Branded Graphics from Your AI Assistant — No Design Tools Required

Iteration Layer — Thu, 30 Apr 2026 00:23:54 +0000

The Branded Image Tax

Every developer who ships products pays the branded image tax. OG images for every blog post and landing page. Event banners for every launch. Email headers for every campaign. Social cards for every product update.

None of these are hard to make. But collectively they eat hours — because every one of them means opening Figma, finding the template, updating the text, fixing the alignment, exporting, uploading. Fifteen minutes per image, multiplied by everything you ship.

Before you reach for an AI image generator: tools like DALL-E or Midjourney generate images from abstract prompts, but they don't produce branded graphics with specific fonts, hex colors, and precise layouts. What you actually need for the above use cases isn't generation — it's composition.

The Iteration Layer Image Generation API uses a layer-based model. You specify a canvas size and stack layers: backgrounds, rectangles, text, photos, overlays. The output is pixel-perfect and deterministic. Same layers, same result, every time.

MCP tool calling connects this to your AI assistant. Describe the layout in plain language — "dark background, white title, red accent line, 1200x630" — and the assistant translates that into the layer structure, calls the API, and returns the image. No Figma, no Photoshop, no code.

What MCP Is

MCP is an open standard that lets AI assistants discover and call external tools. It's a plugin system — you connect a service, and the assistant can use it when relevant.

Setting Up in Claude Code

Claude Code supports MCP servers natively. Add the Iteration Layer server with a single command:

claude mcp add iterationlayer --transport http https://api.iterationlayer.com/mcp

The first time you use an Iteration Layer tool, a browser window opens for OAuth authentication. Log in, authorize access, and you're connected. No API keys to manage.

To verify the server is available, start a conversation and ask Claude Code what MCP tools it has access to. You should see generate_image listed among the available tools.

Setting Up in Cursor

Add to your .cursor/mcp.json:

{
  "mcpServers": {
    "iterationlayer": {
      "type": "http",
      "url": "https://api.iterationlayer.com/mcp"
    }
  }
}

Save and restart. The Image Generation tool is now available in your Cursor AI conversations. Authentication works the same way — OAuth in the browser on first use.

The MCP server exposes a tool that maps to POST https://api.iterationlayer.com/image-generation/v1/generate. When the assistant calls it, it sends a JSON body with fonts, dimensions, layers, and output_format. You never see the raw request unless you ask — the assistant handles the structure, and you describe what you want in plain language.

A Real Conversation

Here's what using it actually looks like. You type:

"Generate an OG image for my blog post titled 'Why We Moved to Postgres'. Dark background, white text, red accent line at the top. 1200x630."

The assistant builds a layer stack:

A solid-color layer — dark navy (#1a1a2e)
A rectangle layer — thin red bar (#e94560) across the top, 4px tall
A text layer — your title in white, large font, positioned with breathing room

It calls the API with that structure and returns the generated image. The whole exchange takes seconds.

You can iterate from there:

"Make the title bigger. Add the site name 'acme.dev' in smaller text at the bottom right."

The assistant adjusts the font size on the title layer, adds a second text layer for the site name, and regenerates. Same workflow a designer would follow in Figma — but through conversation.

More Conversations, More Use Cases

The examples above cover OG images, but the same conversational pattern works for any composition. Here are a few more real interactions.

Adding a photo with smart cropping:

"Add the team photo from https://example.com/team.jpg on the right side. Make sure nobody's face gets cut off."

The assistant adds a static-image layer with should_use_smart_cropping enabled. The API detects the people in the photo and positions the crop so faces stay visible — even if the original photo has off-center framing.

Building an event banner:

"Create a 1200x600 banner for our meetup. Black background. 'TypeScript Berlin' in white at the top. 'March 12, 2026 — 7pm' in gray below it. Put a thin orange line between the two."

The assistant generates a five-layer composition: background, title text, divider rectangle, date text, all positioned with appropriate spacing. You see the result and decide:

"Move the date closer to the line. Make the orange brighter."

Two adjustments, one regeneration. The assistant updates the y coordinate of the date layer and changes the rectangle's hex_color. Iterating on a design through conversation is faster than clicking through Figma panels when you already know what you want.

Using an image overlay for texture:

"Take the OG image we just made and add a subtle paper texture over it. Use this URL for the texture: https://example.com/paper-grain.png. Keep it subtle — maybe 15% opacity."

The assistant adds an image-overlay layer at the top of the stack with opacity: 15. The texture blends over the entire canvas without obscuring the text or accent elements underneath.

The Layer Model

The Image Generation API composes images from layer types, stacked by index:

solid-color — a full-canvas fill. Your base layer.
rectangle — colored shapes for accents, borders, dividers, cards. Supports rotation and angled edges for diagonal designs.
text — rendered text with custom fonts, alignment, and markdown support (bold and italic). Auto-wraps lines within a bounding box.
static-image — photos, logos, icons. Placed at specific coordinates with specific dimensions. Supports AI-powered smart cropping that detects the subject and keeps it centered.
image-overlay — a full-canvas image overlay with opacity control. Useful for textures, gradients, and watermarks.
layout — arranges child layers horizontally or vertically with gap, alignment, padding, background color, and border radius. Supports nesting.

Layers render bottom-to-top by index. A background at index 0, shapes at index 1-2, text at index 3, an overlay at index 4. The mental model is the same as any design tool — Figma, Photoshop, Sketch. Except the "design tool" is your AI assistant.

What You Can Generate

OG images and social cards. The most common use case. Every blog post, every landing page, every product update needs a 1200x630 image. Define a template in conversation, swap the title for each post.

Event graphics. Conference talk cards, meetup announcements, workshop banners. Background + event name + speaker name + date. Four layers, one API call.

Email headers. Branded rectangles with campaign-specific text. Generate a batch by asking the assistant to loop over your campaign titles.

Placeholder graphics. Need a hero image for a prototype? Describe the layout and let the assistant generate it. When the real design arrives, you swap it out.

Custom Fonts

The API supports TTF, OTF, WOFF, and WOFF2 font files. You reference them by URL in the request, and text layers use them by name and weight:

{
  "fonts": [
    {
      "name": "Inter",
      "weight": "Regular",
      "style": "normal",
      "file": {
        "type": "url",
        "name": "Inter-Regular.ttf",
        "url": "https://example.com/fonts/Inter-Regular.ttf"
      }
    },
    {
      "name": "Inter",
      "weight": "Bold",
      "style": "normal",
      "file": {
        "type": "url",
        "name": "Inter-Bold.ttf",
        "url": "https://example.com/fonts/Inter-Bold.ttf"
      }
    }
  ]
}

Text layers that use **bold markdown** automatically render with the Bold variant. This means you can mix weights within a single text block — useful for highlighting a keyword in a title.

When you tell the assistant "use Inter for the text, bold the product name," it knows to include both font weights and wrap the product name in **double asterisks** in the text layer.

MCP vs Direct API Calls

MCP is for ad-hoc work. You need one image, right now, and you don't want to write code. The assistant handles the API structure, the layer composition, the font references. You describe, it generates.

For production pipelines — generating OG images at build time, creating social cards from a CMS, batch-producing event graphics — use the API directly. The request body is JSON. Any language that can make an HTTP POST can generate images.

The two approaches complement each other. Prototype in conversation with MCP, then extract the layer structure into your codebase for automation.

Combining Multiple MCP Tools

The Iteration Layer MCP server exposes Image Generation alongside the rest of the content pipeline. You can chain image generation with Image Transformation, Document Generation, Sheet Generation, Document Extraction, Document to Markdown, and Website Extraction in a single conversation with the same auth and credit pool:

"Generate a 1200x630 OG image with a dark blue background and white title 'API Reference'. Then convert it to WebP."

The assistant calls the Image Generation API first, then pipes the result through the Image Transformation API for format conversion. Two API calls, one conversation, no manual file handling.

"The icon I want to use is only 200x200. Upscale it to 4x first, then add it to the banner."

The assistant calls the Image Transformation upscale operation to bring the icon to 800x800, then uses the upscaled version as an image layer in the generation request.

Get Started

Sign up for a free account at iterationlayer.com — no credit card required. Run the claude mcp add command above, authenticate in the browser, and generate your first image from your next Claude Code or Cursor conversation.

The docs cover every layer type, every property, and every output format. Start with an OG image — it's the simplest template and the most immediately useful.

Extract IBANs, Currencies, and Addresses from Financial Documents — Validated, Not Just Strings

Iteration Layer — Thu, 30 Apr 2026 00:23:50 +0000

Regex Doesn't Understand Financial Data

You need to extract an IBAN from a bank statement. So you write a regex. It matches something that looks like an IBAN — starts with two letters, followed by two digits, followed by up to 30 alphanumeric characters. The pattern matches. You store the result.

Except the regex can't validate the IBAN. It doesn't check the country-specific length. It doesn't verify the check digits. It matches "DE89 3704 0044 0532 0130 00" and "DE00 0000 0000 0000 0000 00" with equal confidence. One is a real IBAN, the other is garbage.

Currency amounts are worse. Is "1.234,56" one thousand two hundred thirty-four euros and fifty-six cents? Or is it one point two three four with some trailing nonsense? Depends on the locale. A regex can't know.

The Iteration Layer Document Extraction API has purpose-built field types for financial data — IBAN, CURRENCY_AMOUNT, CURRENCY_CODE, and ADDRESS. They don't just extract text. They validate, normalize, and structure the results.

IBAN Extraction with Validation

The IBAN field type extracts International Bank Account Numbers and validates them:

const schema = {
  fields: [
    {
      name: "beneficiary_iban",
      type: "IBAN",
      description: "IBAN of the payment recipient",
      is_required: true,
    },
    {
      name: "beneficiary_name",
      type: "TEXT",
      description: "Name of the payment recipient",
    },
  ],
};

The response returns a validated IBAN string:

{
  "beneficiaryIban": {
    "type": "IBAN",
    "value": "DE89370400440532013000",
    "confidence": 0.96
  }
}

This isn't a regex match. The parser identifies the IBAN in the document, validates its format against the country-specific rules, and returns it in the standard format. If the document contains something that looks like an IBAN but doesn't validate, the confidence score reflects that.

IBAN Validation Edge Cases

IBAN formats vary by country. A German IBAN is 22 characters. A Norwegian IBAN is 15. A Maltese IBAN is 31. A regex that accepts "2 letters + 2 digits + up to 30 alphanumeric characters" matches all of them — and also matches strings that aren't IBANs at all.

The IBAN field type validates several things that a regex cannot. It checks the country-specific length (DE must be exactly 22 characters, not 20 or 24). It verifies the check digits using the MOD-97 algorithm defined in ISO 13616. It ensures the BBAN (Basic Bank Account Number) portion follows the country's structure — for Germany, that's an 8-digit bank code followed by a 10-digit account number.

Documents often contain multiple strings that look like IBANs. Account statements might list the account holder's IBAN, the sender's IBAN, a reference number that happens to start with two letters, and a transaction ID with similar formatting. The field description helps the parser identify which one you want. "IBAN of the payment recipient" is more specific than "IBAN" — and that specificity matters when a document has three valid IBANs on the same page.

Currency Amounts Across Locales

The CURRENCY_AMOUNT field type handles the formatting chaos of international financial documents:

"$1,234.56" — US format with comma thousands separator and period decimal
"1.234,56 €" — European format with period thousands separator and comma decimal
"CHF 1'234.56" — Swiss format with apostrophe thousands separator
"¥123,456" — no decimal places

A regex parser needs a different pattern for each locale. The CURRENCY_AMOUNT field type handles all of them and returns a normalized numeric value:

const schema = {
  fields: [
    {
      name: "invoice_total",
      type: "CURRENCY_AMOUNT",
      description: "Total invoice amount",
      is_required: true,
    },
    {
      name: "currency",
      type: "CURRENCY_CODE",
      description: "Currency of the invoice (ISO 4217 code)",
    },
  ],
};

{
  "invoiceTotal": {
    "type": "CURRENCY_AMOUNT",
    "value": 1234.56,
    "confidence": 0.95
  },
  "currency": {
    "type": "CURRENCY_CODE",
    "value": "EUR",
    "confidence": 0.94
  }
}

The amount comes back as a number — not a string with locale-specific formatting. The currency comes back as an ISO 4217 code — not a symbol that could mean multiple currencies ($ is used by USD, CAD, AUD, and dozens of others).

Currency Disambiguation

Currency symbols are ambiguous. The $ sign is used by the US dollar, Canadian dollar, Australian dollar, Hong Kong dollar, Singapore dollar, and at least 20 other currencies. The kr symbol could be Swedish krona, Norwegian krone, or Danish krone. Even "FR" on a document could mean French francs (obsolete) or something else entirely.

The CURRENCY_CODE field type returns an ISO 4217 three-letter code — USD, CAD, AUD, SEK, NOK. No ambiguity. The parser uses context from the document to determine the correct currency: the issuing bank's country, the document language, other addresses on the page. A Swiss bank statement showing "Fr. 1'234.56" returns CHF, not some generic "franc" designation.

When a document uses multiple currencies — a foreign exchange confirmation, for example — define separate CURRENCY_CODE fields for each. "Source currency of the exchange" and "target currency of the exchange" give the parser enough context to distinguish them.

ADDRESS Decomposition

Financial documents are full of addresses — billing addresses, beneficiary addresses, registered office addresses. The ADDRESS field type doesn't just extract the address as a text blob. It decomposes it into structured components:

const schema = {
  fields: [
    {
      name: "billing_address",
      type: "ADDRESS",
      description: "Billing address of the customer",
    },
  ],
};

{
  "billingAddress": {
    "type": "ADDRESS",
    "value": {
      "street": "Kurfürstendamm 194",
      "city": "Berlin",
      "region": "Berlin",
      "postal_code": "10707",
      "country": "DE"
    },
    "confidence": 0.93
  }
}

The country is an ISO 3166-1 alpha-2 code. The components are split out and ready for your database — no address parsing library needed.

International Address Formats

Addresses are surprisingly hard to decompose. A US address has a street, city, state, and ZIP code in a predictable order. A Japanese address starts with the prefecture and works down to the building number — the opposite of Western conventions. A UK address might include a county, or it might not. German addresses put the postal code before the city. Brazilian addresses include a neighborhood (bairro) as a standard component.

The ADDRESS field type handles these variations and normalizes the output into consistent components: street, city, region, postal_code, and country. The region field maps to whatever the country calls its primary subdivision — state in the US, Bundesland in Germany, prefecture in Japan, province in Canada.

Not every address has every component. A rural address might not have a street name. A city-state like Singapore might not have a region. The parser returns the components it can identify and omits the rest. Your code should handle optional fields rather than expecting every component to be present.

A Complete Financial Document Schema

Here's a schema for a bank transfer confirmation that uses all the financial field types:

import { IterationLayer } from "iterationlayer";
const client = new IterationLayer({ apiKey: "YOUR_API_KEY" });

const result = await client.extractDocument({
  files: [
    {
      type: "url",
      name: "transfer.pdf",
      url: "https://example.com/transfer.pdf",
    },
  ],
  schema: {
    fields: [
      {
        name: "transaction_date",
        type: "DATE",
        description: "Date of the transfer",
      },
      {
        name: "sender_name",
        type: "TEXT",
        description: "Name of the sending party",
      },
      {
        name: "sender_iban",
        type: "IBAN",
        description: "IBAN of the sender",
      },
      {
        name: "sender_address",
        type: "ADDRESS",
        description: "Address of the sender",
      },
      {
        name: "recipient_name",
        type: "TEXT",
        description: "Name of the receiving party",
      },
      {
        name: "recipient_iban",
        type: "IBAN",
        description: "IBAN of the recipient",
      },
      {
        name: "recipient_address",
        type: "ADDRESS",
        description: "Address of the recipient",
      },
      {
        name: "transfer_amount",
        type: "CURRENCY_AMOUNT",
        description: "Amount transferred",
      },
      {
        name: "currency",
        type: "CURRENCY_CODE",
        description: "Currency of the transfer",
      },
      {
        name: "reference",
        type: "TEXT",
        description: "Payment reference or description",
      },
    ],
  },
});

{
  "success": true,
  "data": {
    "transaction_date": {
      "type": "DATE",
      "value": "2026-03-01",
      "confidence": 0.97,
      "citations": ["Date: 01.03.2026"],
      "source": "bank-transfer.pdf"
    },
    "sender_name": {
      "type": "TEXT",
      "value": "Müller GmbH",
      "confidence": 0.95,
      "citations": ["Müller GmbH"],
      "source": "bank-transfer.pdf"
    },
    "sender_iban": {
      "type": "IBAN",
      "value": "DE89370400440532013000",
      "confidence": 0.96,
      "citations": ["IBAN: DE89 3704 0044 0532 0130 00"],
      "source": "bank-transfer.pdf"
    },
    "sender_address": {
      "type": "ADDRESS",
      "value": {
        "street": "Kurfürstendamm 194",
        "city": "Berlin",
        "region": "Berlin",
        "postal_code": "10707",
        "country": "DE"
      },
      "confidence": 0.93,
      "citations": ["Kurfürstendamm 194, 10707 Berlin"],
      "source": "bank-transfer.pdf"
    },
    "recipient_name": {
      "type": "TEXT",
      "value": "Acme B.V.",
      "confidence": 0.94,
      "citations": ["Acme B.V."],
      "source": "bank-transfer.pdf"
    },
    "recipient_iban": {
      "type": "IBAN",
      "value": "NL91ABNA0417164300",
      "confidence": 0.95,
      "citations": ["NL91 ABNA 0417 1643 00"],
      "source": "bank-transfer.pdf"
    },
    "transfer_amount": {
      "type": "CURRENCY_AMOUNT",
      "value": 8450.00,
      "confidence": 0.97,
      "citations": ["EUR 8.450,00"],
      "source": "bank-transfer.pdf"
    },
    "currency": {
      "type": "CURRENCY_CODE",
      "value": "EUR",
      "confidence": 0.96,
      "citations": ["EUR 8.450,00"],
      "source": "bank-transfer.pdf"
    },
    "reference": {
      "type": "TEXT",
      "value": "Invoice 2026-0142",
      "confidence": 0.92,
      "citations": ["Ref: Invoice 2026-0142"],
      "source": "bank-transfer.pdf"
    }
  }
}

One API call. Two validated IBANs. Two decomposed addresses. A normalized currency amount with its ISO code. All with confidence scores.

Why Purpose-Built Types Matter for Fintech

Generic text extraction followed by post-processing is fragile. Every post-processing step — IBAN validation, currency parsing, address decomposition — is a point of failure. And each step needs its own test suite, error handling, and locale awareness.

Purpose-built field types push this complexity into the extraction layer, where it's handled once and consistently. Your fintech application receives clean, validated, structured data. The IBAN is valid or it's flagged. The currency amount is a number or it's flagged. The address is decomposed or it's flagged.

No regex library for IBANs. No locale-aware currency parser. No address normalization service. One API with types designed for financial data.

Combining Financial Types with CALCULATED Fields

Financial documents often contain values that should add up. An invoice has a subtotal, a tax amount, and a total. A bank statement has an opening balance, transactions, and a closing balance. Purpose-built types and CALCULATED fields work together to verify these relationships.

const schema = {
  fields: [
    {
      name: "subtotal",
      type: "CURRENCY_AMOUNT",
      description: "Invoice subtotal before tax",
      is_required: true,
    },
    {
      name: "vat_amount",
      type: "CURRENCY_AMOUNT",
      description: "VAT amount",
      is_required: true,
    },
    {
      name: "printed_total",
      type: "CURRENCY_AMOUNT",
      description: "Total as printed on the invoice",
      is_required: true,
    },
    {
      name: "computed_total",
      type: "CALCULATED",
      description: "Subtotal plus VAT",
      operation: "sum",
      source_field_names: ["subtotal", "vat_amount"],
    },
    {
      name: "currency",
      type: "CURRENCY_CODE",
      description: "Invoice currency",
    },
    {
      name: "supplier_iban",
      type: "IBAN",
      description: "IBAN of the invoice issuer",
    },
    {
      name: "supplier_address",
      type: "ADDRESS",
      description: "Address of the invoice issuer",
    },
  ],
};

One API call gives you validated financial identifiers, normalized currency amounts, a structured address, and a computed cross-check on the totals. The alternative is five separate libraries — an IBAN validator, a currency parser, an address decomposer, a math verifier, and the extraction logic itself.

What's Next

Extracted financial data flows directly into Document Generation for formatted reports — same auth, same credit pool.

Get Started

Check the docs for all 17 field types, including the financial types covered here. The TypeScript and Python SDKs return typed responses, so your editor knows the shape of every field result.

Sign up for a free account — no credit card required. Try extracting financial data from your own documents and compare the structured output to what your current regex or template approach produces.

Generate Hundreds of Social Media Images from a Single Template

Iteration Layer — Thu, 30 Apr 2026 00:23:35 +0000

Social Images Don't Scale Manually

You publish regularly. Each post needs a Twitter card, a LinkedIn image, and an Instagram post, all with the same layout but different titles. You open Canva, duplicate the template, update the text, export, resize for the next platform, repeat.

After a few months, the image count turns into a backlog. The layout hasn't changed — just the title and maybe a background image. The manual work is pure repetition.

This is a templating problem. Define the layout once, inject the dynamic content per post, generate the image. The Iteration Layer Image Generation API does exactly this — you describe your template as a stack of layers, swap the variable parts, and get an image back for each combination.

One Template, Three Platforms

Social platforms have different image dimensions. Common recommendations at publication time include:

Twitter/X cards: 1200x675
LinkedIn posts: 1200x627
Instagram posts: 1080x1080

The layout logic is the same across all three — background, accent shape, title text, optional image. Only the dimensions and positioning change.

Here's what a Twitter/X card request looks like — a dark background, accent bar, title, and site name:

import { IterationLayer } from "iterationlayer";

const client = new IterationLayer({
  apiKey: "YOUR_API_KEY",
});

const result = await client.generateImage({
  dimensions: {
    width_in_px: 1200,
    height_in_px: 675,
  },
  output_format: "png",
  fonts: [
    {
      name: "Inter",
      weight: "Regular",
      style: "normal",
      file: {
        type: "url",
        name: "Inter-Regular.ttf",
        url: "https://example.com/fonts/Inter-Regular.ttf",
      },
    },
    {
      name: "Inter",
      weight: "Bold",
      style: "normal",
      file: {
        type: "url",
        name: "Inter-Bold.ttf",
        url: "https://example.com/fonts/Inter-Bold.ttf",
      },
    },
  ],
  layers: [
    {
      type: "solid-color",
      index: 0,
      hex_color: "#0f172a",
    },
    {
      type: "solid-color",
      index: 1,
      hex_color: "#e94560",
      position: {
        x_in_px: 0,
        y_in_px: 0,
      },
      dimensions: {
        width_in_px: 1200,
        height_in_px: 6,
      },
    },
    {
      type: "text",
      index: 2,
      text: "Why We Moved to Postgres",
      font_name: "Inter",
      font_weight: "bold",
      font_size_in_px: 48,
      text_color: "#ffffff",
      text_align: "left",
      position: {
        x_in_px: 60,
        y_in_px: 169,
      },
      dimensions: {
        width_in_px: 1080,
        height_in_px: 338,
      },
    },
    {
      type: "text",
      index: 3,
      text: "acme.dev",
      font_name: "Inter",
      font_size_in_px: 20,
      text_color: "#64748b",
      text_align: "left",
      position: {
        x_in_px: 60,
        y_in_px: 615,
      },
      dimensions: {
        width_in_px: 200,
        height_in_px: 30,
      },
    },
  ],
});

{
  "success": true,
  "data": {
    "buffer": "iVBORw0KGgoAAAANSUhEUg...",
    "mime_type": "image/png"
  }
}

The template uses a dark background, a colored accent bar at the top, the post title in white, and the site name at the bottom. The font size and text positioning adapt to the canvas size.

Generating for All Platforms

To generate for all three platforms, make one API call per platform with the same layer structure but different dimensions. Adjust text positions proportionally — for Instagram's 1080x1080 square, move the title lower and the site name further down. For LinkedIn's 1200x627, use the same horizontal layout with slightly different vertical spacing.

Adding Visual Variety

A solid background works, but it gets repetitive across dozens of posts. Two layer types add variety without changing the template structure:

Background images with low opacity. The image-overlay layer puts a full-canvas image behind your text. Set the opacity to 10-20% so the text stays readable against the dark background. Each post can use a different background image — a relevant photo, an abstract pattern, a gradient texture.

Angled accent shapes. Rectangle layers support angledEdges for diagonal designs. Instead of a flat bar across the top, use an angled rectangle for a more dynamic look:

{
  "type": "solid-color",
  "index": 2,
  "hex_color": "#e94560",
  "position": {
    "x_in_px": 0,
    "y_in_px": 0
  },
  "dimensions": {
    "width_in_px": 400,
    "height_in_px": 630
  },
  "angledEdges": [
    {
      "edge": "right",
      "angleInDegrees": 80
    }
  ],
  "opacity": 20
}

This creates a diagonal accent shape on the left side of the image — a subtle design element that adds depth without overwhelming the title text.

Batch Generation from a Content Feed

The real value shows up when you connect this to your content pipeline. Pull posts from your CMS, generate images for each one:

type BlogPost = {
  title: string;
  slug: string;
  category: string;
};

const ACCENT_COLOR_BY_CATEGORY: Record<string, string> = {
  engineering: "#3b82f6",
  product: "#e94560",
  company: "#10b981",
  tutorial: "#f59e0b",
};

const generateAllSocialImages = async (posts: BlogPost[]) => {
  for (const post of posts) {
    const accentColor = ACCENT_COLOR_BY_CATEGORY[post.category] ?? "#6366f1";
    const images = await generateSocialImages(post.title, accentColor);

    for (const [platform, imageBuffer] of Object.entries(images)) {
      await writeFile(`./public/social/${post.slug}-${platform}.png`, imageBuffer);
    }
  }
};

Each post gets a color based on its category. Engineering posts are blue, product posts are red, tutorials are amber. The template is the same — only the title, color, and filename change.

Template Variants

A single template handles most posts, but some content types deserve their own layout. Product launches might show a screenshot. Team announcements might show a headshot. Quote cards might center a pull quote.

Define each variant as its own template function:

const buildQuoteCardRequest = (quote: string, author: string, width_in_px: number, height_in_px: number) => ({
  dimensions: { width, height },
  output_format: "png" as const,
  fonts: [
    {
      name: "Inter",
      weight: "Regular",
      style: "normal",
      file: {
        type: "url",
        name: "Inter-Regular.ttf",
        url: "https://example.com/fonts/Inter-Regular.ttf",
      },
    },
    {
      name: "Inter",
      weight: "Bold",
      style: "normal",
      file: {
        type: "url",
        name: "Inter-Bold.ttf",
        url: "https://example.com/fonts/Inter-Bold.ttf",
      },
    },
  ],
  layers: [
    {
      type: "solid-color",
      index: 0,
      hex_color: "#0f172a",
      opacity: 100,
    },
    {
      type: "text",
      index: 1,
      text: `*"${quote}"*`,
      font_name: "Inter",
      font_weight: "regular",
      font_size_in_px: 36,
      text_color: "#e2e8f0",
      text_align: "center",
      vertical_align: "center",
      position: {
        x_in_px: 80,
        y_in_px: Math.round(height * 0.2),
      },
      dimensions: {
        width_in_px: width - 160,
        height_in_px: Math.round(height * 0.5),
      },
      is_splitting_lines: true,
      opacity: 100,
    },
    {
      type: "text",
      index: 2,
      text: `— ${author}`,
      font_name: "Inter",
      font_weight: "bold",
      font_size_in_px: 22,
      text_color: "#94a3b8",
      text_align: "center",
      position: {
        x_in_px: 80,
        y_in_px: height - 120,
      },
      dimensions: {
        width_in_px: width - 160,
        height_in_px: 40,
      },
      opacity: 100,
    },
  ],
});

The quote renders in italic (wrapped in *...*), centered on the card. The author name sits below in bold. Same API, different layer arrangement.

Output Formats

Social platforms accept different image formats. The API supports PNG, JPEG, WebP, and AVIF:

PNG — lossless, best for text-heavy images where sharpness matters
JPEG — smaller files, good for images with photos or complex backgrounds
WebP — smaller than PNG and JPEG at equivalent quality. Twitter and LinkedIn both accept it.
AVIF — smallest files, but not universally supported yet

For social images, PNG is the safe default. If file size matters — uploading via an API with size limits — switch to WebP or JPEG with quality at 90.

Get Started

Check the docs for the full layer reference, including all layer types and their properties.

Sign up at iterationlayer.com for a free API key — no credit card required. Build one template, generate images for your last five blog posts, and see how it fits your workflow.

Generate Formatted Excel Spreadsheets in n8n

Iteration Layer — Thu, 30 Apr 2026 00:23:32 +0000

n8n Can Read Spreadsheets but Can't Generate Them

n8n has solid spreadsheet reading support. The Spreadsheet File node parses XLSX and CSV. The Google Sheets node reads and writes rows. But generating a standalone XLSX file — with formatted headers, currency columns, multiple sheets, and formulas — does not have a native answer.

The workarounds are all painful. You can use a Function node with ExcelJS, but you are writing JavaScript to build a spreadsheet cell by cell. You lose the visual workflow benefit of n8n entirely. You can export from Google Sheets, but that means creating a temporary sheet, writing data, formatting it through the Google Sheets API (which has a separate formatting endpoint from the data endpoint), exporting to XLSX, and cleaning up the temporary file. That is five nodes for one spreadsheet.

Some teams use a Puppeteer node to render an HTML table and "print" it to XLSX. This works about as well as you would expect — the formatting is approximate, formulas are impossible, and multiple sheets are out of the question.

Define the Spreadsheet, Get an XLSX

Iteration Layer Sheet Generation takes a JSON definition and returns a binary XLSX file. You define sheets, columns, rows, cell formatting, and formulas. The API handles rendering. No code, no temporary files, no export chain.

The definition is declarative. You describe what the spreadsheet should look like — column widths, header styles, cell formats, formulas — and the API builds it. Currency formatting, percentage formatting, date formatting, bold headers, merged cells, and Excel formulas all work through the JSON definition.

The output is a standard XLSX file that opens in Excel, Google Sheets, LibreOffice, or any spreadsheet application. Or request CSV or Markdown format if you need a simpler output.

The Workflow: Database Query to Email Report

Here is what we are building in n8n: a weekly automated pipeline that queries sales data from a database, generates a formatted Excel report with multiple sheets, and emails it to the team. Four nodes. No Function nodes. No Google Sheets intermediary.

Step 1: Schedule Trigger

Open the n8n canvas and add a new node. Search for "Schedule Trigger" and add it.

In the node settings, set the Trigger Interval to "Weeks" and pick the day and time for your report — Monday at 8:00 AM is a common choice for weekly sales summaries. This fires the workflow automatically on schedule.

Step 2: Postgres Node (Query Sales Data)

Add a Postgres node (or MySQL, MSSQL, or any database node that fits your stack). Configure your database credentials and enter the query:

SELECT
  product_name,
  region,
  units_sold,
  unit_price,
  units_sold * unit_price AS revenue,
  tax_rate
FROM sales
WHERE sale_date >= NOW() - INTERVAL '7 days'
ORDER BY revenue DESC

The node returns an array of items, one per row. Each item has the column values as properties. This is the data that will populate the spreadsheet.

Step 3: Iteration Layer (Sheet Generation)

Add an Iteration Layer node. In the Resource dropdown, select Sheet Generation. Set the Format to xlsx.

In the Sheets JSON field, define the spreadsheet structure. Here is a concrete example with two sheets — a sales detail sheet and a summary sheet:

{
  "sheets": [
    {
      "name": "Sales Detail",
      "columns": [
        {
          "name": "Product",
          "width": 30
        },
        {
          "name": "Region",
          "width": 15
        },
        {
          "name": "Units Sold",
          "width": 12
        },
        {
          "name": "Unit Price",
          "width": 14
        },
        {
          "name": "Revenue",
          "width": 16
        },
        {
          "name": "Tax Rate",
          "width": 10
        }
      ],
      "header_style": {
        "bold": true,
        "background_color": "#1a1a2e",
        "font_color": "#ffffff"
      },
      "rows": [
        {
          "values": [
            {
              "value": "Enterprise Platform License"
            },
            {
              "value": "EMEA"
            },
            {
              "value": 142
            },
            {
              "value": 299.00,
              "format": "currency",
              "currency": "EUR"
            },
            {
              "value": 42458.00,
              "format": "currency",
              "currency": "EUR"
            },
            {
              "value": 0.19,
              "format": "percentage"
            }
          ]
        },
        {
          "values": [
            {
              "value": "API Access — Pro Tier"
            },
            {
              "value": "Americas"
            },
            {
              "value": 89
            },
            {
              "value": 149.00,
              "format": "currency",
              "currency": "USD"
            },
            {
              "value": 13261.00,
              "format": "currency",
              "currency": "USD"
            },
            {
              "value": 0.07,
              "format": "percentage"
            }
          ]
        }
      ]
    },
    {
      "name": "Summary",
      "columns": [
        {
          "name": "Metric",
          "width": 25
        },
        {
          "name": "Value",
          "width": 20
        }
      ],
      "header_style": {
        "bold": true,
        "background_color": "#1a1a2e",
        "font_color": "#ffffff"
      },
      "rows": [
        {
          "values": [
            {
              "value": "Total Revenue"
            },
            {
              "value": 55719.00,
              "format": "currency",
              "currency": "EUR"
            }
          ]
        },
        {
          "values": [
            {
              "value": "Total Units Sold"
            },
            {
              "value": 231
            }
          ]
        },
        {
          "values": [
            {
              "value": "Average Unit Price"
            },
            {
              "value": "=55719/231",
              "format": "formula"
            }
          ]
        }
      ]
    }
  ]
}

In practice, you would build the rows array dynamically using n8n expressions that reference the Postgres node output. The static example above shows the structure — column definitions with widths, header styling, and cell-level formatting for currency, percentages, and formulas.

Key formatting options:

Currency: Set "format": "currency" and "currency": "EUR" on a cell value. The XLSX renders with the correct currency symbol and two decimal places.
Percentage: Set "format": "percentage". The value 0.19 renders as 19%.
Formulas: Set "format": "formula" and pass the Excel formula as the value string. Standard Excel formula syntax works — SUM, AVERAGE, VLOOKUP, cell references.
Header styling: The header_style object applies to the first row of each sheet. Bold text, background colors, and font colors.
Multiple sheets: Each object in the sheets array becomes a separate sheet tab in the XLSX file.

The node returns the generated XLSX as n8n binary data, ready to attach to an email, upload to a file storage service, or pass to another node.

Step 4: Send Email Node

Add a Send Email node (or Gmail, Outlook, or any email node). Configure your SMTP credentials or OAuth connection.

Set the To field to the distribution list for the report. Add a subject line like Weekly Sales Report — {{ $now.format('yyyy-MM-dd') }}. In the Attachments section, select the binary data output from the Iteration Layer node. The XLSX file attaches automatically.

The recipients get a formatted Excel file in their inbox every Monday morning. No Google Sheets link to lose access to. No CSV that loses all formatting on open. A proper XLSX with styled headers, currency formatting, and a summary sheet.

Beyond the Weekly Report

The same Sheet Generation resource handles many generated-spreadsheet workflows:

Invoice line item exports: Extract data from invoices using Document Extraction, or convert dense documents with Document to Markdown first, then generate a formatted XLSX with each invoice on its own sheet. Finance teams get a file they can open in Excel immediately — no CSV import step, no column width adjustments.
Inventory reports: Query product stock levels on a schedule, generate an XLSX with conditional formatting highlights for low-stock items, and upload to a shared drive.
Client deliverables: Pull analytics data from your application's API, generate a branded report with your client's data on separate sheets, and email it automatically. The formatting stays consistent across every client.
Data migration exports: When moving data between systems, generate an XLSX with the exact column structure the target system expects. The import template matches on the first try.

CSV and Markdown Alternatives

Not every use case needs a full XLSX. Set the Format to csv for a simple comma-separated output, or markdown for a Markdown table. The same sheet definition works for all three formats — change one parameter and the output format changes.

CSV is useful when the downstream system only accepts plain text. Markdown is useful when the spreadsheet data feeds into documentation, a chat message, or a Markdown-based CMS.

Get Started

Install the Iteration Layer community node from the n8n UI — search for n8n-nodes-iterationlayer under Settings > Community Nodes. The Sheet Generation docs cover all formatting options, formula syntax, and multi-sheet configuration. The n8n integration docs walk through every resource and parameter.

Start with a simple single-sheet report. Define your columns, add a few rows with formatting, and check the output in Excel or Google Sheets. Once the structure looks right, wire it up to your data source and schedule trigger. Sign up to get your API key.

Generate Print-Ready Book Covers Programmatically — A Self-Publisher's Guide

Iteration Layer — Thu, 30 Apr 2026 00:23:28 +0000

The Cover Problem for Self-Publishers

You've written the book. Now you need a cover. Every format needs its own — Kindle ebook, KDP paperback, hardcover, audiobook thumbnail. Each with different dimensions, different bleed requirements, different text placement. A professional designer often costs hundreds or thousands of dollars per cover. Canva gives you templates that look like every other self-published book on Amazon.

If you're publishing one book, you hire the designer. If you're publishing ten books a year — or running a publishing platform that handles hundreds of authors — manual design doesn't scale.

The Iteration Layer Image Generation API generates cover artwork from a JSON template. Define your cover layout — background, title, author name, decorative elements, optional cover image — and generate it in one API call. Change the title, get a new cover. Change the format, get the right dimensions. No design tool, no export step, no manual work per variant. For print production, still validate bleed, spine width, color profile, and full-wrap requirements against the platform's current specs.

Print Dimensions: Getting the Math Right

Print-on-demand platforms have strict dimension requirements. Amazon KDP specifies dimensions in inches at 300 DPI. The API works in pixels. The conversion is straightforward.

For a standard 6"x9" paperback front cover at 300 DPI:

Width: 6 x 300 = 1800 pixels
Height: 9 x 300 = 2700 pixels

Common book cover dimensions as examples:

Format	Inches	Pixels at 300 DPI
KDP Paperback (6"x9")	6 x 9	1800 x 2700
KDP Paperback (5.5"x8.5")	5.5 x 8.5	1650 x 2550
Kindle Ebook	—	1600 x 2560
Audiobook Thumbnail	—	3200 x 3200
Square Social Promo	—	1080 x 1080

The same cover template can generate all of these by adjusting the composition dimensions and repositioning the layers.

A Fiction Cover Template

Here's a complete book cover for a fiction title — dark background, large serif title, author name, decorative line elements:

import { IterationLayer } from "iterationlayer";

const client = new IterationLayer({
  apiKey: "YOUR_API_KEY",
});

const result = await client.generateImage({
  dimensions: {
    width_in_px: 1800,
    height_in_px: 2700,
  },
  output_format: "png",
  fonts: [
    {
      name: "Playfair Display",
      weight: "Bold",
      style: "normal",
      file: {
        type: "url",
        name: "PlayfairDisplay-Bold.ttf",
        url: "https://cdn.example.com/fonts/PlayfairDisplay-Bold.ttf",
      },
    },
    {
      name: "Playfair Display",
      weight: "Regular",
      style: "italic",
      file: {
        type: "url",
        name: "PlayfairDisplay-Italic.ttf",
        url: "https://cdn.example.com/fonts/PlayfairDisplay-Italic.ttf",
      },
    },
    {
      name: "Lato",
      weight: "Light",
      style: "normal",
      file: {
        type: "url",
        name: "Lato-Light.ttf",
        url: "https://cdn.example.com/fonts/Lato-Light.ttf",
      },
    },
  ],
  layers: [
    {
      index: 0,
      type: "solid-color",
      hex_color: "#1C1917",
    },
    {
      index: 1,
      type: "solid-color",
      hex_color: "#A8A29E",
      position: {
        x_in_px: 200,
        y_in_px: 600,
      },
      dimensions: {
        width_in_px: 1400,
        height_in_px: 2,
      },
    },
    {
      index: 2,
      type: "solid-color",
      hex_color: "#A8A29E",
      position: {
        x_in_px: 200,
        y_in_px: 1900,
      },
      dimensions: {
        width_in_px: 1400,
        height_in_px: 2,
      },
    },
    {
      index: 3,
      type: "text",
      text: "THE LONG\nSILENCE",
      font_name: "Playfair Display",
      font_weight: "bold",
      font_size_in_px: 160,
      text_color: "#FAFAF9",
      text_align: "center",
      position: {
        x_in_px: 100,
        y_in_px: 700,
      },
      dimensions: {
        width_in_px: 1600,
        height_in_px: 600,
      },
    },
    {
      index: 4,
      type: "text",
      text: "A Novel",
      font_name: "Playfair Display",
      font_size_in_px: 48,
      text_color: "#A8A29E",
      text_align: "center",
      position: {
        x_in_px: 100,
        y_in_px: 1350,
      },
      dimensions: {
        width_in_px: 1600,
        height_in_px: 100,
      },
    },
    {
      index: 5,
      type: "text",
      text: "ELIZABETH ASHWORTH",
      font_name: "Lato",
      font_size_in_px: 52,
      text_color: "#D6D3D1",
      text_align: "center",
      position: {
        x_in_px: 100,
        y_in_px: 2000,
      },
      dimensions: {
        width_in_px: 1600,
        height_in_px: 100,
      },
    },
  ],
});

{
  "success": true,
  "data": {
    "buffer": "iVBORw0KGgoAAAANSUhEUg...",
    "mime_type": "image/png"
  }
}

The template uses three fonts: Playfair Display Bold for the title, Playfair Display Italic for the subtitle, and Lato Light for the author name. This is a classic fiction cover typography stack — a serif display font for impact, a light sans-serif for the byline.

The decorative rectangles at 2px height serve as horizontal rules, framing the title area. Simple, but they add structure to the composition.

Adding a Cover Image

Not every cover is typography-only. Many genres — thriller, romance, sci-fi — expect a photographic or illustrated cover. Add a background image using the static-image layer or image-overlay:

// Replace the solid-color with an image
{
  index: 0,
  type: "image",
  file: {
    type: "url",
    name: "mountain-landscape.jpg",
    url: "https://cdn.example.com/covers/mountain-landscape.jpg",
  },
  position: {
    x_in_px: 0,
    y_in_px: 0,
  },
  dimensions: {
    width_in_px: 1800,
    height_in_px: 2700,
  },
  should_use_smart_cropping: true,
},
// Add a dark overlay so text remains readable
{
  index: 1,
  type: "image",
  file: {
    type: "url",
    name: "dark-gradient.png",
    url: "https://cdn.example.com/overlays/dark-gradient.png",
  },
  opacity: 70,
  should_use_smart_cropping: false,
},

The static-image fills the full cover area. Smart cropping positions the focal point of the photo correctly — a mountain peak stays centered, a cityscape keeps the skyline visible. The image-overlay adds a dark gradient so white or light title text remains readable against any background photo.

Font Handling for Publishing

Typography makes or breaks a book cover. The API accepts TTF, OTF, WOFF, and WOFF2 font files via the fonts array. Each font entry specifies the family name, weight, and style — so you can use bold for titles and light for bylines from the same family.

Genre conventions matter here. Literary fiction tends toward serif display fonts — Playfair Display, Cormorant, EB Garamond. Thrillers go bold and condensed — Oswald, Bebas Neue, Impact. Romance leans into scripts and elegant serifs. Non-fiction often uses clean sans-serifs — Inter, Montserrat, Source Sans.

The key advantage of programmatic generation: once you've chosen your typography for a series, every book in the series gets the same fonts, the same spacing, the same weight. Consistency you'd otherwise enforce through a brand guide and hope your designer follows.

Series Consistency

When you're publishing a series, visual consistency across covers sells books. Same font, same layout, same color scheme — different title and maybe a different accent color per book.

const seriesBooks = [
  {
    title: "THE LONG\nSILENCE",
    accentColor: "#A8A29E",
    number: 1,
  },
  {
    title: "THE DEEP\nCURRENT",
    accentColor: "#7C9885",
    number: 2,
  },
  {
    title: "THE LAST\nWITNESS",
    accentColor: "#9B8B7A",
    number: 3,
  },
];

const covers = await Promise.all(
  seriesBooks.map(async (book) => {
    const result = await client.generateImage({
      dimensions: {
        width_in_px: 1800,
        height_in_px: 2700,
      },
      output_format: "png",
      fonts: [/* same font config for the series */],
      layers: [
        {
          index: 0,
          type: "solid-color",
          hex_color: "#1C1917",
        },
        {
          index: 1,
          type: "solid-color",
          position: {
            x_in_px: 200,
            y_in_px: 600,
          },
          dimensions: {
            width_in_px: 1400,
            height_in_px: 2,
          },
          hex_color: book.accentColor,
        },
        {
          index: 2,
          type: "solid-color",
          position: {
            x_in_px: 200,
            y_in_px: 1900,
          },
          dimensions: {
            width_in_px: 1400,
            height_in_px: 2,
          },
          hex_color: book.accentColor,
        },
        {
          index: 3,
          type: "text",
          text: `**${book.title}**`,
          position: {
            x_in_px: 100,
            y_in_px: 700,
          },
          dimensions: {
            width_in_px: 1600,
            height_in_px: 600,
          },
          font_name: "Playfair Display",
          font_weight: "bold",
          font_size_in_px: 160,
          text_color: "#FAFAF9",
          text_align: "center",
          vertical_align: "center",
          is_splitting_lines: true,
        },
        {
          index: 4,
          type: "text",
          text: "ELIZABETH ASHWORTH",
          position: {
            x_in_px: 100,
            y_in_px: 2000,
          },
          dimensions: {
            width_in_px: 1600,
            height_in_px: 100,
          },
          font_name: "Lato",
          font_weight: "light",
          font_size_in_px: 52,
          text_color: "#D6D3D1",
          text_align: "center",
          vertical_align: "center",
        },
      ],
    });

    return {
      title: book.title,
      number: book.number,
      buffer: Buffer.from(result.data.buffer, "base64"),
    };
  })
);

Three covers, same template, same typography, different titles and accent colors. The series looks cohesive on a bookshelf — digital or physical.

Multi-Format Generation

A single book needs multiple cover formats. The Kindle version needs 1600x2560. The paperback needs 1800x2700. The audiobook square needs 3200x3200. A social media promo card needs 1080x1080.

Same template logic, different dimension parameters. You can build a function that takes a book's metadata and a format spec, then generates the appropriate cover:

const formatSpecs = [
  {
    name: "kindle",
    width_in_px: 1600,
    height_in_px: 2560,
    titleSize: 140,
  },
  {
    name: "paperback",
    width_in_px: 1800,
    height_in_px: 2700,
    titleSize: 160,
  },
  {
    name: "audiobook",
    width_in_px: 3200,
    height_in_px: 3200,
    titleSize: 220,
  },
  {
    name: "social",
    width_in_px: 1080,
    height_in_px: 1080,
    titleSize: 80,
  },
];

For each format, adjust the font size and layer positions proportionally to the canvas dimensions. The audiobook square needs a larger title to fill the space. The social card needs everything compressed into a smaller area.

Why Not Canva or AI Image Generators

Canva templates work for one-off covers. But they don't integrate into a publishing pipeline. You can't call Canva from your book management system, pass in the title and author, and get back a cover image. Every cover requires manual clicks.

AI image generators (Midjourney, DALL-E) produce impressive visuals, but they don't produce print-ready covers. You can't control typography precisely — the title might be misspelled, the font won't match your series, and the dimensions won't be exact. You'd still need to composite the AI art with your text in a design tool.

The API gives you pixel-level control over layout and typography while accepting any image — stock photos, AI-generated art, illustrations — as input layers. You get the creative flexibility of a design tool with the automation of an API.

Get Started

Check the docs for the full layer reference, font configuration, and output format options. The TypeScript and Python SDKs handle authentication and response parsing.

Sign up for a free account — no credit card required. Generate your first cover and see how it compares to your current workflow.