Showing Posts From

Guides

Coupon Template Design and Bulk Generation Guide

Coupon Template Design and Bulk Generation Guide

A marketer opens a spreadsheet and sees 200 unique coupon codes waiting to ship before Tuesday. The old route is obvious and miserable, duplicate the artwork, paste each code by hand, check every expiry line, then pray the barcode still matches what the cashier will scan. That is exactly where a coupon template earns its keep, because the design stays fixed while the changing fields are bound once and rendered many times. The difference sounds small until the batch starts drifting. One manual edit changes a discount term in one file but not the other 199, a shared drive fills with near-identical exports, and the first typo at the till costs more than the render job ever did. A real template is not finished artwork. It is a layout with named variable slots, a CSV feeding those slots, and a render pipeline that turns one design into many consistent outputs. Table of ContentsWhy a Coupon Template Beats 200 Manual Edits What manual editing really costs Why binding beats duplicationThe Variables That Change Per Coupon Core fields and how they bindReal Coupon Designs and the Retail Uses They Fit Designs that map cleanly to retail jobs Print-first versus digital-first layoutsBinding the Spreadsheet and Choosing Print Dimensions The CSV-to-render pipelineQR Codes, Expiry, and Delivery Options That Actually Work Symbol choice and scan behavior Expiry and retention choicesBulk Generation Through the API and Automation Tools How automation tools should pass the job A working batch flowPre-Flight Checklist Before You Render 200 Coupons Final checks that prevent wasteWhy a Coupon Template Beats 200 Manual Edits A small-box retailer with a loyalty platform often gets trapped in a familiar mess. The loyalty system hands over 200 one-time codes, someone has to turn them into coupon assets, and the deadline is close enough that shortcuts start looking reasonable. Manual duplication seems faster at first, but it becomes brittle the moment the campaign needs one more edit.What manual editing really costs The hidden cost is version drift. If the expiry date changes, the designer has to open 200 files and make the same edit 200 times. If the terms line changes after legal review, some exports get updated and others don't, especially when multiple people are editing in Drive or desktop folders at once.Practical rule: if a coupon can be represented as data, it should not be maintained as 200 separate design files.The better pattern is a single template with bindings for the parts that change, plus a CSV column for each variable. One row becomes one rendered coupon, and the batch job produces the full set in one pass. That is the difference between “saved a file” and “built a system.”Why binding beats duplication A bound template keeps the barcode in sync with the human-readable code because both come from the same variable. If the expiry date shifts, the operator edits one field in the spreadsheet, not 200 separate canvases. That means fewer mismatches, fewer re-exports, and fewer “which version is current” mistakes. For teams that need a starting point, the template library at Zandovi templates follows this exact model, design once and render many. The workflow is the same whether the output is a printable insert, a digital coupon, or a scan-at-register voucher.The Variables That Change Per Coupon A coupon design only works at scale when the moving parts are clearly separated from the fixed layout. The logo position, brand colors, legal footer, bleed marks, and overall composition stay locked. The data layer changes per coupon, and it needs to be treated like structured input, not freeform text pasted into a canvas.Core fields and how they bind The code is the most obvious variable, usually bound as {{code}}. It should be required, unique, and validated before rendering starts, because duplicate codes create reconciliation problems later. The discount or value field, often written as {{discount}}, should stay numeric so the renderer doesn't choke on stray symbols or inconsistent formatting. The expiry date should bind as {{expiry}}, ideally in ISO format so it sorts cleanly in the CSV and displays consistently in the artwork. The terms line, such as {{terms}}, is where teams get sloppy. It needs control, not improvisation, because one coupon saying “full-price items only” and another saying “select styles only” will confuse cashiers and support staff if they're mixed inside the same batch.A controlled terms list is safer than open text when the same promotion will be redeemed by staff who need to interpret it quickly at the till.A serial or batch ID is often optional, but it helps with reconciliation when finance or support has to trace a problem back to a specific run. In practice, the template should reject null codes and null expiry dates before the job writes any files, then let optional fields stay blank only where the design supports that.Common coupon variables and validation rules Example value Type Validation ruleVariable {{code}} Required text Must be unique and non-emptyDiscount {{discount}} Number Numeric only, no currency symbol in the fieldExpiry {{expiry}} Date ISO date format, non-empty if the design shows expiryTerms {{terms}} Controlled text Must match approved copy, not ad hoc wordingBatch ID {{batch_id}} Optional text Should be consistent within the runReal Coupon Designs and the Retail Uses They Fit A strong template gallery saves time because it already matches the job. The blank-canvas problem is real, and it wastes more time than many companies admit. Picking a design whose variable slots already match the CSV column names is faster than rebuilding a layout for each campaign.Designs that map cleanly to retail jobs A percent-off coupon fits a fashion retailer running a seasonal sale. The visual usually centers the percentage mark, then keeps the code block smaller so the discount reads first. In that layout, the variables are {{code}}, {{discount}}, {{expiry}}, and {{terms}}, with {{recipient_name}} added only when the campaign needs personalized email delivery. A fixed amount coupon works better for hospitality or higher-ticket retail where the shopper needs a simple dollar value instead of a percentage calculation. The same variable logic applies, but the copy stays cleaner when the amount is presented as a value field and the terms line explains what the offer covers. That pattern is also easier to scan on a receipt-style insert. A free shipping coupon is the most natural fit for ecommerce promotions, especially when the code is being reused across email and social. The code must still be bound, but the main visual cue is the shipping offer itself. For that reason, the gallery at the ecommerce coupon template section is useful when the campaign is more about cart completion than in-store redemption.Print-first versus digital-first layouts Print-first coupon designs need bleed, safe zones, and a composition that survives trimming. Digital-first versions usually care more about square or mobile-friendly framing, with transparent PNG export often making handoff easier for email or social placements. The best template is the one that already fits the channel, not the one that looks nicest in a browser preview.Binding the Spreadsheet and Choosing Print Dimensions The cleanest workflow starts in a spreadsheet, not in the editor. Each row becomes one coupon, and each column maps to a variable name that the template already expects. Once the column headers match the bindings, the render job can be run row by row without hand-editing each asset.The CSV-to-render pipeline The safest sequence is simple. Prepare the CSV or XLSX file with one row per coupon and one field per variable, upload it to the bulk render tool, map the sheet columns to the template fields, and dry-run the first few rows before committing the full batch. That first check catches missing codes, malformed dates, and empty QR or barcode fields before the job wastes time. For press work, the common formats are 3.5 x 2 inch wallet cards, 4 x 6 inch postcard inserts, and A5 tear-off flyers. A commercial printer usually wants 300 DPI and CMYK, while in-house proofs can be checked at a lower resolution before final export. Full-bleed designs need 3 mm bleed, plus crop marks, and the variable text must sit inside safe zones so trimming doesn't clip the code or expiry line.Press files fail most often because the template looked fine at screen size but pushed the code too close to the edge.Coupon print dimensions and export settings Dimensions (in) DPI Color Export ProfileWallet card 3.5 x 2 300 CMYK PDF/X-1aPostcard insert 4 x 6 300 CMYK PDF/X-3Tear-off flyer A5 300 CMYK PDF/X-1aProof export any approved trim 150 minimum RGB or CMYK depending on proof Plain PDFThe practical payoff is simple. The same bound design can render to a single-page PDF, a PNG for digital handoff, or a ZIP of many outputs without rebuilding the artwork each time. That keeps the design contract stable while the delivery format changes.QR Codes, Expiry, and Delivery Options That Actually Work A barcode and a QR code solve different problems, even when they both point to the same bound code. A Code 128 or Code 39 barcode is the safer fit when the coupon is scanned at a point-of-sale terminal, because 1D symbols are what most tills and laser scanners are already built to read. A QR code is better when the coupon is shown on a phone screen, opened from email, or needs to point to a redemption URL that can be tracked.Symbol choice and scan behavior QR error correction should stay at M for clean layouts, then move to Q when the code sits on a busy background or gets resized more aggressively. The important thing is not the symbol type alone, but whether the design keeps enough quiet space around it for reliable scanning. A beautiful coupon that won't scan is just a complaint waiting to happen.Expiry and retention choices Expiry should be visible in the design and enforced in the system that serves the coupon, especially when the code is redeemed through a hosted link. Some workflows keep the file available for a short retention window after expiry so customer support can settle disputes, then purge it automatically. That is a better operational trade-off than leaving stale offers floating around indefinitely. Delivery should match the job. Raw bytes make sense when the caller will archive the PDF immediately. A signed hosted URL makes more sense when the coupon is being emailed or sent by SMS, because the attachment does not have to pass through mail infrastructure and the link can expire on schedule.Bulk Generation Through the API and Automation Tools A real bulk workflow is a request, a job, and a download. For a single coupon render, the caller posts the template ID, a variables object, and the output format to the render endpoint, then receives either the PDF bytes or a signed URL. For a batch, the caller posts the template ID plus the CSV upload, receives a job ID, polls the status endpoint until complete, then downloads the ZIP of all rendered files.How automation tools should pass the job n8n, Make, and Zapier all follow the same pattern even though the wiring looks different. Set the HTTP Request node to POST, send the body as form-data, attach the CSV as a file field, and pass the template binding as a JSON field. Once the response comes back, parse the job payload, then pipe the download URL into the next step for email delivery or cloud storage. The useful part of that setup is that the automation tool never has to understand the artwork. It only moves data, waits for the render, and hands the output to the next module. That keeps the coupon system deterministic and lets the spreadsheet stay the source of truth. For teams comparing render APIs, Zandovi's API comparison page is one way to inspect the public differences without assuming feature parity. The key point stays the same regardless of vendor, the batch job should accept structured rows and return a predictable download artifact.A working batch flow A marketer drops a 200-row CSV into a Make scenario, the HTTP module posts it, the response returns a ZIP URL, and a Gmail module sends the right coupon PDF to each row's address. No manual duplication, no separate file naming, no last-minute code swapping.Pre-Flight Checklist Before You Render 200 Coupons A batch should not start until the bindings, the file, and the delivery path all agree. The fastest failures are usually invisible until render time, so a pre-flight pass is cheaper than fixing 200 broken outputs after the fact.Final checks that prevent wastePopulate every variable: Each {{variable}} should resolve to a real CSV column, with no nulls in the code or expiry fields. Confirm uniqueness: Duplicate code rows should fail before any PDF is written. Check trim safety: The code, discount, and expiry must stay inside the safe area for the chosen print size. Test one sample row: A dry run should prove that PDF or PNG output looks right before the full queue starts. Match delivery to audience: Email and print workflows should map to the correct segment, with hosted URLs or raw bytes chosen intentionally.The rendering rule is straightforward. 300 DPI and CMYK belong to press work, while 150 DPI minimum and on-screen color spaces are fine for proofs. If the coupon includes a barcode or QR code, that field can't be empty, and the final file count should match the expected row count before the job is considered done. For redemption-specific design thinking, the gift-card workflow guide at Zandovi's gift-card design article uses the same logic around scan-to-redeem fields, codes, and clear instructions.A coupon template should behave like a bound-variable system, not a folder full of hand-edited images. Teams that keep the layout fixed, validate the CSV early, and bind the code to the barcode end up with fewer errors and faster fulfillment. If the next campaign already has its rows in a spreadsheet, the practical move is to map the variables, run a three-row test, then render the full batch and ship the coupon flow before the deadline tightens.

Event Ticket Template That Prints Right Every Time

Event Ticket Template That Prints Right Every Time

The wrong event ticket template usually fails in the same way every time. It looks fine on the screen, then someone prints it on cheap stock, scans it under bad lighting, and the whole check-in line slows down because the code is too small, the fields are in the wrong place, or the CSV column names don't match the template anymore. A better workflow treats the ticket like a database row first and a print job second. The spreadsheet carries the truth, the template is just the layout, and the QR code is only useful if the variable behind it stays consistent from upload to scan. Table of ContentsChoosing an Event Ticket Template From Real Designs Real layouts and the jobs they doWhat Fields Belong on a Printable Ticket Fixed fields versus variable fieldsBinding Variables in the Visual Editor The binding flow that actually holds upUploading an Attendee CSV and Running a Batch Job The batch flow from upload to ZIPGenerating Tickets Individually Through the API Request shape and delivery behaviorValidation, Error Handling, and Quota Safety The failure layers that matterDistribution With Share Links, Expiry, and Revoke Links, expiry, and revoke behaviorChoosing an Event Ticket Template From Real Designs A gate workflow should determine the starting template, not the artwork. A front-of-house concert stub serves a different handoff than a trade-show badge, while a raffle ticket and VIP pass have their own print and access requirements. Use the tickets category page as a gallery of real design patterns. Compare each layout against the fields your spreadsheet must supply and the tasks staff perform at entry. The working question is practical: which fields stay fixed, which values change per attendee, and which printed elements must remain readable during a rushed handoff? A good event ticket template keeps the branding, event name, and terms stable. Attendee-specific values belong to bound variables, with the spreadsheet remaining the source of truth and the template handling layout.Real layouts and the jobs they do A front-of-house concert stub suits general admission, seated shows, and events where staff tear off a stub while retaining the other half. Its compact print area usually carries the event branding, one scan zone, and a human-readable fallback code. A trade-show badge fits conferences, expos, and multi-entry events. The printed format is often taller, with room for a name line, company, and lanyard slot. Variable fields commonly include attendee name, ticket type, date, and a QR code.Practical rule: if the badge hangs on a lanyard, readable text deserves nearly as much attention as the scan code.A raffle ticket supports fundraising, school events, and drawer-style prize systems. The layout generally needs a duplicate number, tear line, and compact placement that keeps the ticket number clear after separation. A VIP pass suits backstage access, speaker lounges, and premium entry lanes. Its visual treatment can signal status, but the data contract still needs attendee name, seat or access level, date, ticket number, and QR code. The right choice depends on field placement and the physical handoff. A sample may look attractive yet fail once variable text grows, a code is scanned at an angle, or staff need the ticket number for manual lookup. Treat every unique QR value as one CSV column rather than a manual edit. After selecting a layout, open it in the editor, inspect the placeholder types, and confirm that the canvas matches the intended stock. For badge-style formats, the event badges template page offers the closest comparison for a ticket that also functions as an access credential.What Fields Belong on a Printable Ticket A printable ticket should separate fixed fields from variable fields before anyone uploads data. Fixed fields are the parts every attendee sees the same way, like the event name, venue, date, organizer logo, brand colors, and terms. Variable fields change per row in the spreadsheet, and that is where mistakes usually begin. The most reliable templates keep the fixed layer calm and obvious. That means the event title stays visible at a glance, the venue text doesn't get buried under decoration, and the print-safe area leaves room for the QR or barcode without crowding it.Fixed fields versus variable fieldsField Type Source Render ruleEvent name Fixed Template design Keep prominent and readableVenue and address Fixed Template design Place where staff can scan or inspect quicklyDate and time Fixed Template design Keep near the title or entry detailsBrand logo Fixed Template design Use a stable print-safe assetTerms and conditions Fixed Template design Keep legible, not decorativeAttendee name Variable CSV row Bind as text, preserve spelling exactlyTicket type Variable CSV row Render clearly as GA, VIP, or similarSeat row and seat number Variable CSV row Keep in a dedicated seating zoneTicket number Variable CSV row Make it visible for manual fallbackQR code Variable CSV row or payload Render with enough whitespace for scanningThe QR area deserves special care. Contemporary ticketing moved toward scan-first validation because QR codes support fast entry, and industry coverage in the mid-2020s reported that 58% of venues used QR codes for entry and 86% of buyers preferred mobile delivery through apps or QR as reported in event-ticket coverage. That means the code can't be treated as decoration. It has to stay scannable on a phone screen and on a printed stub. A practical ticket design guide recommends a QR code size of at least 0.75 by 0.75 inches with a quiet zone of at least 0.125 inches so scanners can read it reliably at the entrance according to the layout guide. That aligns with the operational reality of crowded doors, where staff need a fast fallback if a ticket is crumpled, glossy, or held under glare. The strongest habit is to decide which fields belong on the retained half of the ticket and which ones belong on the stub. The stub still needs a readable code and a unique number after tear-off, because gate staff and ushers often use that strip after the attendee walks in. The layout should protect those fields first, then let branding fill whatever remains.Binding Variables in the Visual Editor A ticket template only works at batch scale when its fields have stable names. In the visual editor, start with static sample text, then convert each editable element into a variable binding. Text, image, and barcode elements use different value types, so configure each binding according to the element rather than treating every field as plain text. The spreadsheet remains the source of truth. If the editor expects attendee_name and the CSV sends name, the renderer will not infer the relationship. Store the template ID, binding slugs, and CSV schema together, then change them through a controlled update rather than renaming columns after production data has been prepared.The binding flow that actually holds up Open the template, drag a Text element onto the canvas, and replace its sample value with {{attendee_name}}. For a name badge or seated ticket, this usually controls the most prominent line. Keep the variable name readable because operators will need to match it to a CSV header later. Image bindings take a URL, and the render service fetches that asset when the job runs. A slow or unreliable host can delay a row or produce a missing image, so cache the asset or host it where the renderer can reach it consistently. Barcode and QR bindings require a payload string and an encoding type such as QR, Code128, or PDF417. The payload should come from the row, not from a manually edited design. Error correction also affects the layout: a code placed over a busy background or printed on glossy stock needs more tolerance than one on a plain, uncluttered card. Treat the binding as the variable contract that makes the design repeatable, distinct from the design itself. Each unique QR value can occupy one CSV column, while the template controls its position, size, and visual treatment. Gate-control systems have long paired readable ticket numbers with QR codes and barcodes, allowing staff to scan or type the same code at entry in documented gate-control workflows. The template supplies the layout, while the ticket code connects each spreadsheet row to its validation record. The API follows the same contract. Upload variable names must match the bindings exactly, and the template ID should travel with the schema so later edits do not break existing jobs. The API template reference provides a useful comparison for how a visual design maps to rendered output.Uploading an Attendee CSV and Running a Batch Job A spreadsheet error can affect an entire ticket run. Treat the CSV as the source of truth and the template as a layout that is already bound to its fields. Export the template schema, fill one attendee per row, then submit the file so each row produces one rendered ticket. Numbered tickets and unique QR values stay in their own columns instead of requiring manual edits. This workflow fits seated events, conferences, and registration systems that already hold attendee data. One row becomes one ticket record, while the batch job converts those records into print-ready PDFs.The batch flow from upload to ZIP Fill the exported CSV with the bound fields, such as attendee_name, ticket_type, seat_row, seat_number, and qr_payload. Upload it through the batch endpoint. Before rendering begins, the system compares the CSV headers with the template schema. A mapping modal provides an early check. It matches each header to the template variable, so a spelling error is caught before rows enter the render queue. If the headers match, run a dry pass first. The result gives the operator a render count to review before committing the batch. After the job is queued, the render service processes rows in chunks. It returns a job object containing a batch identifier and a status URL. Successful files are collected in a ZIP, while a manifest CSV records the filename and render status. The print operator can then isolate failed rows without opening every PDF.attendee_name ticket_type seat_row seat_number qr_payload render_statusMaya Chen Keynote A 14 ticket_001 renderedJordan Lee Keynote A 15 ticket_002 renderedPriya Shah Keynote B 01 ticket_003 renderedSam Ortiz Keynote B 02 missing_payload failedA failed row usually points to a missing value or an invalid format. The error should be treated as a data correction, not a design failure. Fix the row, validate it against the schema, and rerun the affected work rather than changing a template that rendered correctly for the other records. The batch model matches spreadsheet-first bulk QR workflows, where each CSV row becomes one QR code or ticket record and the output is downloaded as a ZIP for printing as described in the batch generator guide. The division of responsibility is clear: the spreadsheet stores the records, the template renders them, and the ZIP contains the print set.Generating Tickets Individually Through the API Single renders are the right move when the ticket has to be generated on demand, like a late VIP walk-up, a corrected name, or a door sale that needs a fresh PDF without rerunning the full batch. The request body sends one value per bound variable, and the response comes back in one of two patterns, depending on whether the caller wants the file immediately or wants to pick it up later. For a door-side workflow, single render calls are easier to debug because each ticket is isolated. They're also cleaner when an operator is printing from a tablet and needs one result right away instead of a ZIP file full of unrelated rows.Request shape and delivery behavior A basic single-render call uses the template ID and a JSON body with the variable values. When the request is set for inline delivery, the response returns the PDF as base64 plus a render ID. When it's set for async delivery, the render ID comes back first and a webhook or callback can notify the caller when the file is ready. The delivery-link option changes the output from binary content to a signed URL, which is better when another system needs to hand off the file later. That link should expire on a defined schedule, and it can be revoked if the ticket needs to be invalidated before it gets used. A request with strong safeguards also includes an idempotency key so a retry does not create a duplicate render. That matters on flaky mobile networks, where the same door operator might tap submit twice while waiting for a response.Operational rule: use single renders for the long tail, not the main batch. They're simpler to trace, but they're the wrong shape for a hundred-seat manifest.The practical trade-off is straightforward. Single renders are the cleanest way to handle exceptions, but batches are the better fit when the attendee list is already stable and the only real variable is the spreadsheet. For API-driven teams, the ticket template rendering endpoint is the deeper reference for numbering logic and one-off generation patterns.Validation, Error Handling, and Quota Safety The right validation stack starts before rendering and keeps working after the job is queued. Header checks catch missing columns up front, unknown-column rejection blocks stray input, and type validation makes sure each variable looks like the template expects. That is how a batch avoids wasting render capacity on rows that were never valid. This is also where the ticketing stack needs to be more honest than the design preview. A ticket can look perfect and still fail because a font is missing, a field is placed out of bounds, or a QR payload is malformed. The preview is only one layer of confidence, not proof that the row will render.The failure layers that matter The first failure class is schema mismatch. If the CSV headers do not match the bound variables, the upload should stop before any render is charged. The next layer is variable typing, where string length, seat-row format, image encoding, and payload shape all get checked against the schema. After that comes render preflight. The engine catches issues like missing fonts or coordinates that fall outside the canvas. If a batch starts failing repeatedly at this stage, a circuit breaker should pause the job instead of hammering the renderer with the same broken input. Partial failures need a clean trail. A failed rows file with row numbers and reasons is more useful than a vague job error, because the successful rows can still ship while the broken ones get fixed and rerun. That keeps a venue from losing a whole ticket run because of one malformed record.Failed renders shouldn't cost a clean batch its momentum. The job needs to surface the bad rows, not bury them.The main CSV mistakes are predictable. One is a renamed header that no longer matches the binding slug. Another is a seat field that contains free-form text instead of a stable row value. A third is an image column that carries plain text instead of encoded image data or a valid fetchable asset. The fourth is a QR payload that was edited by hand and no longer matches the row's unique record. The safer habit is to validate the CSV before submission, keep the schema fixed, and let the failed rows file do the debugging. That's much cheaper than reprinting a whole batch because one column drifted overnight.Distribution With Share Links, Expiry, and Revoke Once a ticket becomes a URL, distribution becomes an access-control problem as well as a delivery task. That affects email, wallet handoff, and any workflow where staff or attendees must reopen a ticket without regenerating it. The spreadsheet remains the source of truth. Each generated file and share link should trace back to one attendee row and its unique QR value. The first choice is link scope. An order-level link suits one purchaser holding multiple admissions. An attendee-level link gives each person a separate ticket, which makes independent gate validation and revocation easier to manage.Links, expiry, and revoke behavior A share link commonly uses a tokenized path tied to the ticket ID. The delivery mode changes the response: delivery: link returns a URL, while delivery: email prepares the ticket for a messaging workflow. Short alias paths also reduce wrapping and truncation in mobile email clients that handle long URLs poorly. Set expiry explicitly. An absolute timestamp gives staff a fixed cutoff, while a TTL window defines how long the link remains usable after creation. Keep that policy separate from the QR payload. The QR validates at the gate; the delivery link provides file access. Revoke provides containment when a venue changes, a ticket is duplicated, or the distribution list is incorrect. A soft revoke marks the token invalid, allowing the scanner or delivery endpoint to return a 410-style response. A hard purge removes the record more aggressively, so it should be reserved for cases where retention is no longer required. On event night, use a short operational checklist. Pre-warm scanner caches, confirm that backup PDFs follow the same QR specification, and resolve-test every alias before doors open. These checks connect clean attendee data with reliable crowd entry. The final handoff should be reversible. Send links only after the batch has passed validation, record which attendee received each token, and keep revoke access with the operations team rather than burying it in the design editor.If the next ticket run needs to work the first time, build it from the spreadsheet backward. Bind the variables, validate the CSV before upload, print one sample, and then send the full batch. For a production event ticket template, that order saves more time than a design tweak.

Shipping Label Generator Guide for Small Sellers

Shipping Label Generator Guide for Small Sellers

A small seller can lose half a morning to the same mistake: mixing up postage buying with label generation. One system buys the shipment, another renders the artwork, and a thermal printer only cares that the file is exact, scannable, and sized right. That separation matters for anyone printing internal labels, packing slips, return labels, box labels, or a whole batch from an orders CSV. A shipping label generator is the part that turns template fields into print-ready output, while postage still comes from USPS, DHL, UPS, or a shipping platform. Zandovi fits that narrower job because it generates label artwork from a template, binds address, order number, and barcode fields to variables, and prints to exact label dimensions at 300 DPI. It doesn't buy postage, fetch carrier rates, or produce carrier-certified labels. Table of ContentsWhat a Shipping Label Generator Actually Does for Small Sellers Artwork generation, not postage purchase What the file should containDesigning the Label Template and Binding Variables Set the canvas to the printer, not the other way around Bind every changing field to a variablePicking the Right Barcode Symbology for Labels and Cartons Code 128 for order and tracking fields Compare the symbologies by jobSingle Render vs Batch Job From a CSV One order at a time The decision to make before printing at scaleReturn Labels, Packing Slips, and Reverse Logistics Include with the order or email on request What changes inside the templatePrint Settings, DPI, and Pre-Flight Checklist Match the export to the device Pre-flight checklist for the first print runFrom CSV to Printed Labels the Repeatable Workflow The workflow that scales without dramaWhat a Shipping Label Generator Actually Does for Small Sellers A Monday-morning Shopify export can make the difference obvious fast. The warehouse lead has a CSV with recipient names, street lines, order IDs, SKUs, and maybe a return reason code, and the printer queue needs something clean before packing starts. A shipping label generator takes that data, drops it into a designed template, and outputs a PNG or PDF that the printer can consume without a human editing every order.Artwork generation, not postage purchase That's the part many teams blur together. Postage purchase lives in carrier tools or shipping software, while the generator handles the layout, the font sizing, the barcode placement, and the quiet zones that make scanning work at the dock. The output can be a parcel label, a packing slip, a carton label, or a return label, but the rendering step stays the same, the data changes. Shipping labels are not just decoration. Barcode-based logistics runs at scale, with 7.8 billion barcode scans per day worldwide in 2023 in GS1 ecosystem reporting, and labels have to survive repeated scans across sortation and returns flows. Barcode standards and readable label geometry are what keep that system working, not a prettier layout alone, as noted in barcode industry coverage and logistics guidance. The broader shipping-label market also reflects that shift, with a 2026 industry report valuing the global market at USD 2.3 billion in 2025 and projecting USD 3.6 billion by 2036 at a 4.2% CAGR (shipping-label market report).Practical rule: keep postage logic out of the renderer. If a label file needs a carrier service code, pass it in as data, don't ask the template layer to decide shipping policy.What the file should contain At the template layer, the file needs the fields a packer would otherwise type by hand. That usually means the from address, ship-to address, order number, a tracking placeholder, and one barcode field. If the workflow also prints box labels, pallet marks, or a carton ID, those are separate render targets, not a different kind of shipping logic. A good generator keeps the output deterministic. Same template, same row, same pixels, every time. That's why a template-rendering API is useful for small sellers who want reliable print assets without pretending the renderer is the carrier.Designing the Label Template and Binding Variables A useful template starts with the physical label, not the browser canvas. For parcel work, 4 × 6 inches is the common size, and one label-size reference maps 100 × 150 mm to roughly 1181 × 1772 pixels at 300 DPI (label size converter). That gives a practical target for print artwork, especially when the output must land cleanly on a thermal roll or a laser sheet.Set the canvas to the printer, not the other way around For thermal work, 203 DPI is usually enough for standard shipping labels, while 300 DPI is safer for smaller or denser barcodes, and 600 DPI is reserved for specialist compact designs (barcode printing guidance). The label generator should render at the exact physical size, then let the printer output at 100% scaling, not “fit to page.” That prevents cropped corners, soft barcodes, and shifted address blocks. The template layout itself should be boring in the best way. Put the sender block in the upper-left, the recipient block in the center, and reserve a clean lower-right area for the barcode and its quiet zone. If the label also carries carton IDs, that field belongs on the carton template, not crammed into the parcel label.Bind every changing field to a variable A CSV row becomes useful only after its columns map cleanly into placeholders. Typical bindings look like {{ship_to_name}}, {{ship_to_address1}}, {{ship_to_city}}, {{ship_to_zip}}, {{order_id}}, and {{sku}}. Optional fields like {{weight_lb}} or {{service}} can stay blank when the seller doesn't need them, but the template should still expect them by name.Missing fields are dangerous because they often fail silently. A blank barcode or truncated postcode can look fine on screen and still break at scan time.A template library helps here because it gives the seller a carrier-aligned starting point instead of a blank page. Zandovi's shipping-label template library is available at https://zandovi.com/templates/shipping-labels/, and the same template approach works well for sellers who later adapt the size for international A4 output.Picking the Right Barcode Symbology for Labels and Cartons Barcode choice should follow the job, not the aesthetic. A tracking number on a parcel label and a GTIN on a carton don't serve the same purpose, so they shouldn't use the same symbology by default. GS1 guidance says ITF-14 is used for traded units such as outer cases, while GS1-128 is used when additional data like expiry dates, weights, batch numbers, or SSCCs must be encoded (GS1 retail barcode guide).Code 128 for order and tracking fields For shipping workflows, Code 128 is the workhorse. Independent label-printing references list it as a logistics and shipping-label symbology, and USPS package-identification labels also use Code 128 formatting for fixed-data package IDs (barcode label reference, USPS package identification Code 128 spec). That makes it the right default for order numbers, tracking zones, and internal package identifiers. ITF-14 belongs on cartons and outer packs, not on every parcel label. Its role is to identify traded units, especially when a retailer or warehouse needs a carton-level code that scans reliably through handling. If the workflow needs return-portal links or richer metadata, a QR code can carry that data, but the core shipping label still usually needs a linear barcode for carrier and warehouse scanning.Compare the symbologies by jobSymbology Best Use Min Module Width Quiet ZoneCode 128 Order numbers, tracking fields, package IDs Use printer resolution and target scan distance to set the X-dimension Keep a clean blank margin around the barsITF-14 Cartons, outer cases, traded units Use a wider, high-contrast bar pattern for compliance scanning Leave the bearer-bar and surrounding margin intactQR Return portal links, mixed data payloads Use a module size that stays readable at the target print DPI Keep the required quiet zone around the codeCode 39 Internal bins, legacy warehouse labels Keep it simple and large enough for human handling Leave enough blank space to avoid crowdingThe important operational point is consistency. Pick the symbology once per template, then render it the same way across the batch. That keeps scan behavior predictable at the printer, the pack desk, and the carrier hub.Single Render vs Batch Job From a CSV A single label render is the simplest path when the order volume is still lumpy. One JSON payload goes in, the generator returns one PNG or PDF, and the packing desk can print immediately. That's useful for manual tests, webhook-driven orders, and any situation where a picker wants to confirm the layout before committing a whole batch.One order at a time Single-render endpoints fit the way many small operations work. A merchant prints one replacement label, one sample, or one rush order without standing up a spreadsheet import flow. The drawback is obvious, though, because every label is its own request and the process gets slower when someone has to repeat it dozens of times. Batch jobs solve the repeat problem. A CSV upload or line-delimited JSON file can feed the same template with many rows, and the response usually comes back as a job ID plus a status path or callback. Zandovi supports batch generation from CSV rows, and its plan structure caps rows per job at 25, 100, 200, 300, or 400, depending on tier, while 1 render = 1 image or 1 PDF with no format multipliers. Manual editor exports are unlimited on paid plans.The decision to make before printing at scale A practical batch setup needs idempotency. If the same order_id appears again because a CSV gets retried, the job should return the original render instead of creating duplicates. That protects both inventory and customer service, especially when labels are attached to fulfillment states that downstream systems assume are unique.Operational shortcut: send delivery by link when the workflow ends in automation. An HTTP request node can pick up the link, pass it through a scenario, and avoid writing files to local storage.Aspect Single Render Batch JobInput shape One JSON payload CSV or row setOutput timing Immediate AsynchronousBest for Testing, rush orders, webhook events Fulfillment runs, CSV importsFailure handling Easy to inspect one result Needs job status or callback handlingAutomation fit Simple integrations n8n, Make, Zapier-style HTTP flowsThat split keeps the shipping-label layer honest. Single renders handle exceptions, batch jobs handle throughput, and neither one needs to pretend it's a postage engine.Return Labels, Packing Slips, and Reverse Logistics A return starts the same way every time, a buyer says the order needs to come back. The seller then renders a second label from the same template family, but the data flips, so the merchant address becomes the return destination and the buyer's address becomes the sender on the return form. That swap is the core mechanic behind a clean reverse-logistics flow.Include with the order or email on request Two patterns show up again and again. Include-with-order puts the return label in the outbound parcel, usually as a smaller companion sheet or a second panel. Email-on-request waits until a return case opens, then sends a PDF link after the buyer submits the reason. Independent shipping help pages already treat return labels as a separate use case, but the core friction is workflow design, not field labels. The hard question is when to preprint, when to delay, and how to keep the customer from editing sender and receiver fields by hand. That's where template-driven reverse logistics helps, because the same render engine can produce the outbound label, the return label, and the packing slip with different assets. Packing slips usually follow the same pattern as the label, just with a different layout. The merchant reuses the same data source, but the document is meant for humans checking contents, not for carrier sortation. That separation keeps the parcel exterior scannable and the interior paperwork readable.What changes inside the template A return reason code can sit in a barcode or a text block, depending on how the warehouse team wants to consume it. The label may also need a service code or RMA field if the receiving dock sorts returns by disposition. That is still a template job, not a carrier-rate job. The same reverse-logistics pattern also fits invoice-like paperwork. A shipping workflow can borrow the same render system used by a document template, and Zandovi's invoice templates show how layout reuse can stay separate from transport logic. The useful takeaway is simple, one generator can serve several documents, but each document should keep its own purpose and scan behavior.Print Settings, DPI, and Pre-Flight Checklist Most label failures show up at the printer, not in the API. A file can look fine in the preview and still fail because the driver rescales it, the printer clips the quiet zone, or the barcode density doesn't match the device resolution. That's why print settings deserve as much discipline as the template itself.Match the export to the device A 203 DPI thermal printer needs source artwork sized for its pixel density, while 300 DPI works well for inkjet, laser, and denser barcode layouts (barcode printing guidance). The safest output for shipping work is usually a flattened PDF or a vector-style page rendered at the exact physical size, because that reduces the chance of re-encoding artifacts. PNG can work, but only when the page size and scaling are controlled tightly. Quiet zones need real space. Barcode references commonly call for a margin of at least ten times the narrowest bar width around the barcode, and that blank space has to survive the printer driver and the adhesive sheet or label roll. If the barcode gets crowded by an address block or a crop box, scanners often fail at the worst possible moment, at the carrier hub or the packing desk.Pre-flight checklist for the first print runDPI match: confirm the export matches the printer, with 203 DPI for common thermal heads and 300 DPI for denser output. Canvas size: keep the page at the exact label size, usually 4 × 6 inches for parcel labels. Barcode clarity: verify that Code 128 stays black, crisp, and uncrowded, with no gray conversion on thermal stock. Scaling: set the print dialog to 100%, not fit-to-page. Test print: run one label on plain paper before using adhesive stock. Physical check: measure the first printed label with a ruler before the batch starts.The first bad print usually comes from scaling, not design. A clean template can still fail if the driver decides to be helpful.A final detail matters for production runs. VDC research summarized in a barcode-labelling whitepaper found the biggest error sources were unclear template selection 49%, incorrect data on labels 49%, manual spot-checking 46%, and unscannable barcodes caused by poor print or media quality 45% (barcode-labelling whitepaper summary). That's a strong argument for deterministic templates, automated data validation, and scan checks after application, not just after export.From CSV to Printed Labels the Repeatable Workflow A small seller usually needs the same pipeline every time, just without the manual retyping. The clean version starts with orders_export.csv containing order_id, ship_to_name, address_1, city, postcode, weight, and service, then maps those columns into template variables, chooses the barcode symbology, and submits the batch job for rendering. If the workflow is built that way once, the same process can run every morning without a different operator improvising the layout.The workflow that scales without drama The most stable setup is straightforward. Use a 4 × 6 inch canvas, render at 300 DPI for thermal or print-ready PDF for office printers, bind tracking fields to Code 128, and keep carton identifiers on ITF-14 when the box needs its own mark. If the automation layer is n8n, the delivery step can use a link response, which keeps the file handoff clean and avoids local storage churn. Template versioning matters more than teams expect. So does carrier service-code mapping, because one wrong code can print a clean-looking label for the wrong service level. Error fallback should also be decided up front, whether a bad row gets retried automatically or pushed to a human queue for correction. The simplest rule is the one that survives Monday mornings.Lock the page size: choose one label size and keep it fixed. Keep the template version stable: change layout only when the print logic changes. Map carrier codes once: don't let each row invent its own service logic. Set an error path: retry for transient failures, human review for bad addresses or missing fields. Print one test row: confirm the label before launching the full batch.A template-rendering API like Zandovi can fit this flow because it reads templates and renders them, which is the exact boundary a seller needs when postage buying stays in carrier or shipping-platform software. The useful outcome is not a bigger shipping stack, it's a smaller, more reliable one. For teams ready to ship their own labels without mixing artwork with postage, the next step is to load one template, map one CSV, and print ten test labels before scaling the job. Start with the shipping-label template library, keep the carrier logic outside the renderer, and verify the first batch on real stock before the morning run goes live.

7 Gift Card Generator Workflows for Small Businesses

7 Gift Card Generator Workflows for Small Businesses

A seasonal promotion is approaching, and a small retailer needs several gift cards that look consistent, carry unique codes, show the correct value and expiry date, and reach customers without creating a spreadsheet nightmare. A single attractive design isn't enough. The workflow also has to connect the visual card with changing recipient data, scannable codes, batch production, print output, and delivery. That makes a gift card generator more than a design canvas or redemption platform. The right tool depends on whether the business needs branded card files, a hosted checkout, a catalog of third-party rewards, or a full issuance and redemption system. The seven workflows below start with real designs and practical production steps, then move into distribution platforms and, only later, API-based automation. Table of Contents1. Zandovi The batch workflow Where automation belongs2. Voucherify The decision to make3. Tango RaaS API Catalog fulfillment versus merchant cards4. Tremendous Match the platform to the card design5. Giftbit Confirm the operating model first6. Gift Up! Match the tool to the bottleneck7. Shopify Gift Cards Decide whether native is enoughTop 7 Gift Card Generators Comparison Turn One Approved Design Into Every Card1. Zandovi A retailer with one approved design can use Zandovi to produce personalized cards without building a custom rendering system. Its gift card templates support different retail situations. A polished layout suits a seasonal promotion or premium store credit. A simpler service-focused design fits salons, restaurants, and appointment-based businesses. Seasonal artwork can support holiday gifting while keeping separate campaigns visually distinct. The workflow begins in the visual editor. Add the logo, colors, offer wording, redemption instructions, and supporting artwork to the canvas. Then map changing fields such as {{code}}, {{amount}}, {{expiry}}, and {{recipient}}. Text, QR codes, and barcodes can bind to those values, allowing every card to carry its own amount, recipient details, and scannable identifier.The batch workflow Keep one card per spreadsheet row. Upload the file, validate the columns, run the batch, and download a ZIP with one file per card. Free supports 25 rows per job, Personal supports 100, and Business supports up to 400. Use the gift card redemption design guide when the artwork needs clearer offer wording, stronger redemption instructions, or a more visible call to action. Every plan includes print-ready PDF at 300 DPI, including Free. The plan quota still controls automated renders. One render equals one image or one PDF, so changing the output format does not multiply the usage count. Paid plans include unlimited manual editor exports, while API calls and batch rows count toward automated usage. Zandovi's published plan details list Free at $0 with 100 renders per month, Personal at $29 with 5,000 renders, Studio at $49 with 12,000, Team at $79 with 25,000, and Business at $199 with 100,000.Where automation belongs The public API renders an existing template through the documented render endpoint. It can return image bytes or provide a hosted link when link delivery suits the campaign better. The API reads templates and renders them. It does not create, update, or delete templates, so template authorship stays in the visual editor. Zapier, Make, and n8n require an HTTP request node, rather than native apps or nodes. Set up automation only after the visual and spreadsheet workflow produces reliable test cards. Check unique codes, restricted data, QR destinations, expiry dates, test renders, delivery logs, and quota use. Avoid placing sensitive information in public links, and shorten or revoke hosted-link lifetimes when the delivery process allows it.Practical rule: Reuse the card artwork, but control every code, expiry value, and redemption destination as operational data.ProsVisual control: Designers manage templates on a full canvas, while engineers render approved designs without maintaining a headless-browser stack. Accessible entry point: The Free plan includes the API and print-ready PDF, while paid plans separate manual editing from automated usage. Deterministic output: Server-side Skia rendering produces consistent image and PDF results instead of generative variations. Operational batch support: CSV upload and batch jobs suit teams producing cards from structured rows.ConsEditor-first template management: The public API can't create or modify templates. Scoped integrations: Zapier, Make, and n8n need HTTP request nodes, and public plans do not provide features such as SSO, audit logs, or white-labelling.2. Voucherify A retailer running a seasonal promotion may already have approved card artwork, yet still struggle with eligibility, redemption status, and campaign rules. Voucherify addresses that operational layer. Its focus covers gift-card issuance, validation, redemption, metadata, and promotion logic. The Voucherify gift-card platform provides REST APIs, SDKs, and a dashboard for retailers that need consistent behavior across sales and redemption channels. This model suits campaigns where a code's validity depends on customer data, campaign membership, conditions, or redemption state. Barcode and QR assets can support physical or digital redemption, while reporting helps operations teams track what has been issued and used. Gift cards, coupons, and loyalty mechanics can also operate within one promotion system. The distinction from a visual gift card generator is practical. Zandovi handles the controlled card asset, variable binding, print-ready files, and batch delivery. Voucherify manages the offer and its lifecycle. A retailer may use either product or connect both, depending on whether the immediate problem is producing branded cards or enforcing redemption rules.The decision to make Start with the required outcome. A salon issuing a limited seasonal voucher may need a branded printable or digital card and a dependable spreadsheet workflow. A retailer combining gift cards with coupons, loyalty rewards, and channel-specific validation may accept the implementation work of a promotion platform. Voucherify's publicly available pricing above the free tier is sales-led rather than fully detailed. Before purchase, confirm implementation scope, support expectations, and redemption requirements. A business that needs a separate visual asset workflow can review Zandovi's coupon templates and decide whether approved artwork should remain in a dedicated template system. Use Voucherify when rules and redemption control drive the project. Choose a visual generator when producing branded files is the main task. Pros: Flexible developer control, a clear separation between campaigns and vouchers, and one promotion model for related mechanics. Cons: Setup requires more implementation effort than a plug-and-play card production workflow, and pricing requires a direct commercial discussion. Capabilities and pricing checked against the Voucherify gift-card page, verification date: August 27, 2026.3. Tango RaaS API A SaaS company sending rewards to customers, researchers, or business contacts may need brand choice and dependable fulfillment rather than custom card artwork. Tango's RaaS API supports ordering and tracking across sandbox and production environments, with delivery through email, links, or physical fulfillment. That model suits marketplaces, research incentives, and B2B gifting programs where recipients select from an available catalog. Teams without developers can use the self-serve portal. Developers can connect recurring or larger programs through the API. Catalog access and reporting support administration, while digital, prepaid, and physical reward formats cover different delivery requirements.Catalog fulfillment versus merchant cards Tango handles much of the catalog and fulfillment work. A local retailer issuing its own gift card controls the design, amount, code, offer terms, and redemption destination. For that job, the workflow may start with an approved visual template, bind variable fields, generate a spreadsheet batch, and deliver print-ready PDFs or hosted links. An API can automate distribution, but it does not replace the need to create the retailer's card asset. Use Tango when recipients should choose an established brand and the business needs reliable reward delivery. Choose a visual generator when the required output is a branded PDF or digital card containing the retailer's own code and redemption instructions. Credit-card funding typically carries a processing fee of about 2.9%, according to Tango's gift-card API page. Larger programs should confirm current funding terms, catalog availability, delivery options, and margins before committing. Pros: One integration can support multiple brands and reward types, with onboarding support and enterprise-oriented processes. Cons: Pricing and margins are commonly negotiated, and funding costs must be included in the operating model. Capabilities and fee information checked against the linked Tango API documentation, verification date: August 27, 2026.4. Tremendous A research team sending rewards across several countries needs recipient choice and dependable payout operations. A local shop issuing branded cards needs a fixed design, controlled amount, unique code, and clear redemption instructions. Tremendous serves the first situation more directly than the second. Its platform supports gift cards, prepaid cards, and monetary rewards across an international footprint. Businesses can launch through a dashboard or connect distribution through an API. That setup suits incentive programs, research rewards, referral campaigns, and distributed teams where recipients may prefer different reward types.Match the platform to the card design Start with the intended card experience. If recipients should select from available brands, a rewards-distribution platform can handle catalog delivery and geographic requirements. If every customer should receive the retailer's own design and redemption terms, use a template-rendering workflow that binds fields such as amount, code, and expiry to each card. Tremendous describes 2,000+ gift cards and coverage across 200+ countries on its rewards platform. Its fee policy treats gift cards and prepaid rewards differently from monetary payouts, so review the current terms for the selected reward type. Brand and denomination restrictions can also vary by region. Confirm catalog availability before approving a campaign. Pros: Fast launch, dashboard and API access, broad geographic coverage, and multiple payout choices. Cons: Monetary payout methods can carry fees, while brand and denomination availability varies by region. A small retailer should select Tremendous when recipient flexibility solves a real distribution problem. For a branded merchant card, its catalog layer may create extra administration without improving the customer experience. In that case, approve the visual template first, then use controlled data binding and batch generation to produce the required files or links. Capabilities and coverage checked, verification date: August 27, 2026.5. Giftbit A small rewards program may need brand choice, centralized reporting, and a self-serve issuance process rather than a custom retailer card. Giftbit supports that model through brand discovery and issuance features in its REST API and SDKs. One integration can therefore provide access to multiple brands without separate arrangements for every reward. The card design determines whether that model fits. Giftbit delivers an existing brand card from a catalog. A spreadsheet-driven gift card generator starts with the merchant's approved artwork, binds fields such as recipient, amount, code, and expiry, then produces the files or hosted links that represent the merchant's own offer.Confirm the operating model first Before launch, confirm target markets, catalog availability, delivery format, funding fees, reporting requirements, and the intended redemption identity. Recipients choosing an outside brand calls for a rewards-distribution platform. A retailer-owned card calls for controlled template rendering and data binding. Giftbit describes a no-platform-fee model, while credit-card funding and selected prepaid products may carry fees. Catalog coverage can vary by market, and physical prepaid options may add cost and lead time. Check those details against the Giftbit platform before setting the campaign budget. Pros: A relatively simple cost model, self-serve tools, and clear developer documentation. Cons: Market-specific catalog coverage requires validation, while physical options add operational work. For a local retailer, Giftbit suits reward programs where recipients benefit from brand choice. Set up the catalog workflow when that flexibility solves a real distribution need. For cards sold under the retailer's own name, approve the visual template first, then bind each spreadsheet row to the required amount, code, expiry, and delivery output. The merchant retains control of the artwork and redemption identity. Capabilities and pricing policy checked, verification date: August 27, 2026.6. Gift Up! A small shop that wants to sell and redeem digital gift cards without custom development can start with Gift Up!. It supports branded cards, email and print delivery, wallet options, staff tools, and dashboard validation, including partial redemptions. Connections with payment processors and site builders can reduce the work required to put a functioning checkout online. The operating model centers on the transaction. Gift Up! manages selling, payment, delivery, and redemption. A template-based gift card generator instead produces controlled card files or hosted links from structured rows. Choose Gift Up! when the priority is a hosted selling page and counter redemption. Choose the template workflow when payment and redemption already exist, but the retailer needs repeatable visual assets, spreadsheet batches, ZIP delivery, or print-ready PDFs.Match the tool to the bottleneck Gift Up! has no monthly fee, but charges per card or transaction. A per-card charge may apply outside its stated free allowance, and payment processor fees remain separate. Model seasonal transaction volume before launch. A subscription-free plan can still create meaningful platform costs at scale. Staff apps and the dashboard fit shops where employees validate cards at the counter. The REST API and Checkout API support deeper integrations, though the product's main value is hosted commerce and redemption rather than spreadsheet-to-ZIP production. Pros: Quick SMB setup, no monthly fee, mobile redemption tools, and straightforward POS workflows. Cons: Transaction charges affect unit economics, while highly customized catalogs may require more work than a specialized visual workflow. Check the Gift Up! product page for current fees, payment relationships, and delivery options before launch. Confirm whether its hosted checkout solves the retailer's bottleneck, or whether a separate generator should handle design templates, variable binding, and batch output. Capabilities and pricing model checked, verification date: August 27, 2026.7. Shopify Gift Cards Shopify Gift Cards suit merchants already running a Shopify storefront and POS. From Shopify Admin, the business can create gift-card products, issue cards manually, and accept redemption through checkout or Shopify POS. Store reporting stays within the existing administration and analytics workflow. That native connection is the practical advantage. Staff can manage basic closed-loop store credit without learning another redemption platform. Shopify also supports configurable denominations, market and notification settings, plus Apple Wallet pass support through Liquid objects, subject to current documentation.Decide whether native is enough Shopify remains tied to the Shopify store. A retailer that needs multi-brand payouts or a broad third-party reward catalog should consider another platform. The same applies when customers need a highly designed PDF or image asset outside the storefront. Zandovi e-commerce templates can support that separate visual workflow. Review the storefront, POS requirements, artwork, spreadsheet batch volume, redemption destination, and whether cards must circulate outside Shopify. Native issuance and checkout are a good fit when the card functions as store credit inside one Shopify operation. Bulk production of personalized files is a different requirement. It may call for a template, variable-binding, and rendering workflow that Shopify does not replace. For example, a retailer distributing digital cards after spreadsheet imports should decide whether each card needs a downloadable file, hosted link, or only a code redeemable at checkout. That decision should come before selecting the platform, because Shopify's native workflow prioritizes store-based issuance and redemption. Fees and transaction details can change. Use the Shopify Help Center gift-card overview as the current reference before launch. Capabilities checked against the Shopify Help Center, verification date: August 27, 2026.Top 7 Gift Card Generators ComparisonProduct Implementation complexity Resource requirements Expected outcomes Ideal use cases Key advantagesZandovi Low for designers (visual editor); moderate for automation (batch/API) Visual editor access, spreadsheet for batches; Free 25 rows/job, Personal 100, Business 400; 300 DPI PDFs on every plan Pixel-identical, print-ready PDFs/images with per-card variables (amount, code, expiry, QR/barcode); ZIP per batch SMBs needing branded, batch-produced personalized cards for print or digital delivery WYSIWYG template editor + deterministic renderer; robust CSV/batch jobs; hosted links and stream deliveryVoucherify Higher, API-first development work required Engineering time for API/SDK integration and redemption channels; vendor pricing often sales-led Fine-grained issuance, validation and redemption with campaign/promotion rules and metadata Retailers needing complex promotion logic, multi-channel redemption and auditability Granular validation rules, unified promotion engine, audit-friendly separation of campaigns and codesTango (RaaS API) Medium, integrate ordering/delivery API and onboarding Integration work; catalog access and fulfillment; pricing/ margins typically negotiated; CC processing fees may apply Access to a large brand catalog, ordering, delivery tracking, and reporting for digital/prepaid/physical cards SaaS, marketplaces, research incentives or programs needing many brands and fulfillment handled One integration for many brands and payout types; mature RaaS with sandbox and production endpointsTremendous Low–medium, simple API or dashboard flows Funding methods (card/ACH/invoice), compliance for global payouts; prepare recipient lists Fast launch of global rewards with diverse payout methods and reporting International incentive programs or distributed reward operations Broad global coverage, multiple payout options, fast self-serve + API launchGiftbit Low, straightforward API and dashboard Basic integration or self-serve use; catalog availability varies by market Centralized brand discovery, issuance and reporting with simple cost model Small rewards programs and startups needing clear pricing and reporting Transparent pricing model, easy self-serve plus API, suitable for smaller programsGift Up! Very low, hosted checkout and dashboard, minimal dev No monthly fee option; connects to payment processors (Stripe); staff apps/checkout setup End-to-end selling, delivery (email/print/wallet) and redemption with per-card/transaction fees SMBs wanting hosted sales and redemption without building checkout or POS integration Quick launch, no monthly fee model, integrated checkout, mobile/staff tools for redemptionShopify Gift Cards (native) Low for existing Shopify merchants; minimal added work Active Shopify store, Admin access, possible POS integration Native issuance and redemption in checkout/Shopify POS; store-tied reporting Merchants already on Shopify who want integrated gift products and POS redemption No extra platform required; integrates with storefront, themes and POS for simple managementTurn One Approved Design Into Every Card The strongest workflow starts with the offer, not the software. A polished retail promotion needs a visual treatment that signals value and brand quality. A service voucher needs a clear service description and redemption instruction. A seasonal card needs timely artwork without making the underlying production process disposable. Once the design is chosen, create one reusable template and bind only the fields that change. Typical variables include the recipient, amount, expiry date, code, and a QR or barcode value. Every code should be unique, and every QR destination should be checked before distribution. The business should test one render first, scan the code, inspect the expiry text, verify the recipient data, and confirm that the card reads clearly at its intended size.Production sequence: Approve the design, bind the variables, render one card, upload a small CSV, inspect the ZIP, confirm print quality, then scale within the plan's row cap.For printed cards, the PDF should be prepared at 300 DPI at the final printed size, with embedded fonts and CMYK color where the print provider requires them. Screen assets prepared at 72 to 96 DPI can look blurry or pixelated in print, so a business shouldn't approve a file merely because it looks sharp on a laptop. Variable-data printing supports changing text, numbers, barcodes, and QR codes, which makes one approved design practical for serialized cards. The fraud risk deserves equal attention. The U.S. FTC reported nearly 40,000 gift-card and reload-card reports involving $147.8 million stolen in the first nine months of 2021, with gift cards accounting for 26.6% of money-loss reports from 2018 through 2021, according to the FTC data spotlight. Businesses should protect code files, restrict access to spreadsheets, rate-limit balance checks, monitor unusual issuance and redemption patterns, and create a support process for freezing or reissuing compromised cards. Automated usage should also be monitored. Zandovi stops automated rendering at the plan limit, with no rollover or overage billing. Server requests or HTTP request nodes for Zapier, Make, and n8n should come only after the visual and batch process is proven. The public API renders existing templates. It doesn't manage template creation, updates, or deletion.Choose one approved design and run a small test batch before the seasonal campaign opens. Start with Zandovi's live gift-card workflow, verify every code and redemption path, inspect both digital and print output, and expand the batch only when the card works for customers and staff alike.

Canva Bulk Create: The Limits, and What to Do When You Hit Them

Canva Bulk Create: The Limits, and What to Do When You Hit Them

We make a tool that competes with part of what Canva does, so weigh this accordingly. It's also true that most people reading this should probably stay where they are, and this post says where that line is. Canva's Bulk Create is a good feature. You build a design, connect a spreadsheet, map columns to text and image placeholders, and get a personalized copy per row. For name badges, social variants and simple certificates, it is often the fastest path from data to output, and if it's working for you there's no reason to change anything. But there's a specific set of walls people hit, and hitting one tends to send you searching. Here's what they are. Wall 1: rows per batch Bulk Create caps how many rows you can process in one go. Canva's help center documents the current figure, which has been in the low hundreds, and the cap applies per batch, so a larger dataset means splitting the file and repeating the process. The documented cap is usually not the real limit anyway. Each row becomes a page in a single Canva document, so a few hundred rows produces a few hundred pages in one file, and the editor gets progressively heavier to work with. In practice most people find their comfortable batch size well below the technical maximum. Not because it stops working, but because reviewing and exporting a 300-page document is its own chore. If you're generating a few hundred items a few times a year, splitting the file is genuinely fine. If it's a recurring weekly job, the splitting is the problem. Wall 2: it's a human-in-the-editor flow This is the bigger one, and it's structural rather than a number you can raise. Bulk Create is something a person does: open the design, connect the data, map the fields, generate, review, export. There is no version of it that fires when a form is submitted, when an order completes, or when a row lands in a database. Someone has to be at the keyboard. That's fine for campaign work. You sit down, you make the batch, you're done. It doesn't work at all for anything continuous. If your certificates should be issued the moment a learner finishes a course, or the voucher should be in the welcome email that goes out ninety seconds after signup, no amount of batch processing gets you there. You need something a server can call. Wall 3: programmatic access is gated high Canva does have a developer platform. The Connect APIs include autofill endpoints that populate a brand template from data programmatically, which is exactly the capability the previous section is asking for. The catch is the plan requirement. Per Canva's own documentation, using the Autofill APIs in production requires the integration to act on behalf of a user in a Canva Enterprise organization; users on other paid plans get limited access while an integration is under development. If you're a solo operator or a small team on Pro or Teams, that path isn't open to you at the price you're currently paying. So the honest summary is that automated generation exists in the Canva ecosystem, and it's priced for organizations rather than for the person with a spreadsheet and a deadline. Wall 4: the details that surface at scale Smaller than the first three, but they're what people actually complain about once volume goes up. No per-field validation before generating. Bulk Create maps whatever is in the cell. If row 88 has a malformed date or a code in the wrong format, you find out by looking at page 88. At twenty rows you'd notice. At three hundred you won't, and the error reaches whoever receives it. Unique codes per row need care. A single QR code on a design is easy. A different QR code per row, one encoding each recipient's own redemption or verification URL, is a different requirement, and it's worth testing on three rows before you commit a whole campaign to it. Print output. Canva exports print-quality PDFs, but if your requirement is a specific DPI, exact physical dimensions, and predictable behaviour when a print shop opens the file, this is worth verifying carefully rather than assuming. Long values break layouts. A name twice as long as your test data will overflow or wrap unless the text element is set up to handle it. This bites everyone, in every tool, and it's the single most common cause of a batch that has to be regenerated. Option A: stay, and split Worth saying plainly: if you generate a few hundred items a handful of times a year, splitting the spreadsheet costs you fifteen minutes per campaign. That is cheaper than migrating, cheaper than learning a new tool, and cheaper than adding a subscription. Canva's design capabilities and asset library are genuinely excellent, and none of the walls above are about design quality. Split by something meaningful, like cohort or date or region, rather than by arbitrary row ranges, and the resulting files stay organized on their own. Option B: write a script If you're comfortable with code, generating personalized images from a CSV is a solid afternoon of Python or Node. You get complete control and no subscription. You also get to own it. Font rendering, the PDF library's quirks, and the layout code all become yours to maintain, and the person who needs the design changed next quarter has to ask you rather than doing it themselves. That trade is worth it for some teams and clearly not for others. Option C: a tool built for the batch case The third option is a design editor whose batch and API paths aren't an afterthought. This is what we built Zandovi to be, and here's the concrete comparison rather than a pitch. Batch from a spreadsheet. Design once, download a CSV whose headers already match your template's variable names, fill it, upload it. Rows are validated against the template's rules before anything renders, so mismatched columns, missing required values, values outside a variable's allowed list and QR data that won't encode all get caught up front — along with an advisory flag on any column whose values run far longer than the design allows for. You fix them in the sheet and re-upload. Then you get a ZIP with one file per row, rather than a many-page document to export. Row caps per job are 25 on the free plan, 100 on Personal, 200 on Studio, 300 on Team and 400 on Business. So this is not an unlimited-rows story either, and large datasets still get split. What changes is the validation and the output shape. The same design, callable. The template you built for the batch flow is also an API endpoint: POST the variable values, get PNG, JPEG, WebP or PDF bytes back. And the batch flow itself is callable too: POST /api/v1/batch-jobs takes the same rows as the CSV tab, runs the same up-front validation, and returns the same ZIP, so "we need this automated" doesn't mean rebuilding the batch as a loop. Every paid plan includes full API access, with no enterprise tier standing between you and automating it. That's the wall-2 and wall-3 answer in one. Unique codes per row are the normal case. QR and barcode elements bind to variables like any text field, so each row can carry its own redemption link or verification URL without a workaround. Print output is explicit. DPI is a setting (96, 150 or 300), PDF costs the same as a PNG with no format multiplier, and the canvas can be set up in millimetres or inches from the start.Where Canva is still the better answer Being fair about this matters more than winning the comparison. Design breadth is the obvious one. The stock library, the font selection, the sheer number of starting points: that's Canva's moat, and it's a real one. So is familiarity. If four people need to edit the design and all four already use Canva, that's worth more than any feature comparison. Occasional, low-volume batches don't justify adding a tool either. A few hundred items twice a year is not a problem worth solving with a second subscription. And if you're already on Teams or Enterprise, the API question is settled and brand controls come with it. The case for moving is narrower than a vendor blog usually admits: you're generating regularly, the volume makes the manual flow tedious, you need validation or unique codes per row, or you need a server to trigger it and don't have Enterprise. Moving one design, if you do Don't migrate everything. Pick the single design causing the most repetitive work and rebuild just that one:Rebuild the layout on a canvas of the same dimensions. An hour, usually less. Mark the changing elements as variables, setting which are required and which have a fixed list of allowed values. This is the step with no Canva equivalent, and it's what stops bad rows from becoming bad output. Download the generated CSV template and paste your existing data under the headers. Run a batch of five rows first. Check the longest name, the shortest name, and anything with an accent or a non-Latin character. Then run the real batch.The free plan includes 100 renders a month with no card, which is enough to rebuild one design and test it properly before deciding anything.References: Canva Bulk Create help, Canva Connect Autofill API docs. Both were checked in July 2026. Canva's limits and plan requirements change, so confirm the current figures on their pages before making a decision.

What a Rendered Image Actually Costs: Image Generation API Pricing in 2026

What a Rendered Image Actually Costs: Image Generation API Pricing in 2026

We build one of the products in this category, so read this with that in mind. What follows is the comparison we had to do for ourselves, written down. Every number is from the vendor's own public pricing page, checked in July 2026, and linked so you can verify it. Linked also so you can catch it when it goes stale, because these pages change every few months. Why these pricing pages are hard to compare Five things make a straight comparison awkward, and only some of them are accidental. Credits are not renders. Some vendors charge one credit per image and some charge multiples for certain outputs. A PDF might cost two credits per page. A video costs by duration. If your workload is mostly PDFs, a plan advertising 5,000 credits might deliver 2,500 documents. Annual prices are shown as if they were monthly. The large number on the page is often the annual-billing rate divided by twelve. Paying month to month costs meaningfully more, commonly 15-25%. Check which toggle is selected before you write the number down. Some vendors meter per seat. A plan at $45 per seat with 450 credits per seat looks cheap next to a $149 flat plan until you have four people, at which point it isn't. Free tiers range from generous to decorative. "Free" sometimes means a recurring monthly allowance and sometimes means a one-time bundle of trial credits that never refills. Those are very different things when you're evaluating. What counts as a render varies. On most platforms, exporting an image by hand from the web editor consumes the same credit an API call would. On a few, it doesn't. If your team does a lot of manual design work alongside the automated pipeline, this is the difference that dominates the bill. The number to compare Ignore the plan names. Compute cost per 1,000 renders at the tier you'd actually be on. Not the cheapest tier, and not the enterprise one, but the one that covers your realistic monthly volume with maybe 30% headroom. Then check whether your specific output type carries a multiplier. Entry tiers, July 2026 Prices as listed on each vendor's public pricing page in July 2026. Where a vendor shows annual pricing by default, the monthly rate is noted.Product Entry plan Renders included ≈ Cost / 1,000 Free tierPlacid $19/mo 500 credits ~$38 Trial creditsBannerbear $49/mo 1,000 credits ~$49 30-credit trialTemplated $29/mo 1,000 credits ~$29 One-time 50 creditsAPITemplate.io $29/mo billed annually ($35 monthly) 1,500 renders ~$19-23 50/moZandovi $29/mo 5,000 renders ~$5.80 100/moAnd the higher tiers, where the per-render economics usually improve:Product Mid tier Renders ≈ Cost / 1,000Placid $39/mo 2,500 ~$16APITemplate.io $69/mo 9,000 ~$7.70Bannerbear $149/mo 10,000 ~$15Zandovi $79/mo 25,000 ~$3.20The part most comparisons leave out If you stop reading at the table above, you'll conclude that the established vendors are expensive and everything else is cheap. That's not quite the shape of the market in 2026, because there's a whole second group of products that compete purely on render economics. As of July 2026, that group includes Imejis (around $24.99 for 10,000 renders, with 100 free per month), Bannerify ($29 for 10,000, also with a recurring free tier), RenderForm (from about $9 for 250, with credit rollover), HTML/CSS to Image (around $14 for 1,000) and Switchboard (around $19 for 1,000). Look at those numbers next to the table and the honest conclusion is that on price per render alone, the budget group wins, and nobody in the established group beats them. That includes us. Bannerify sells 10,000 renders for the same $29 that buys 5,000 from Zandovi. We're saying this out loud because it's the thing you'd find in twenty minutes anyway, and because it points at the actual question. If cost per render were the only variable, this would be a one-line market and the cheapest vendor would have all of it. It isn't, so the useful question is what you give up at each price. What you're actually buying at each price point The budget group is typically API-first. You give it HTML/CSS or a simple template definition and it gives you an image, fast and cheap. What's usually thin or absent: a real visual editor a non-engineer can use, batch processing from a spreadsheet, print-ready output at a controlled DPI, team accounts with roles, and template management beyond a list. If your rendering need is well-defined, high-volume, and owned entirely by engineers, this group is very hard to argue against. The established group charges more per render and sells operational maturity: years of uptime history, mature integration ecosystems, video and GIF generation in Bannerbear's case, support you can escalate to. If you're integrating rendering into a product your customers depend on, that history is worth paying for and the per-render delta is probably noise in your budget. Seat-metered products like Abyssale price around teams rather than volume. If your usage is five designers each making a moderate number of assets, that model can work out cheaper than volume pricing. If it's one server making 100,000 calls, it won't. Six questions that change the answer more than the headline price How long does the hosted image live, and can you delete one? Almost every vendor here answers a render with a hosted URL, so the question isn't whether you get one — it's what happens to it afterwards, and that's where the documentation thins out. We checked in August 2026: APITemplate.io keeps paid renders indefinitely, HTML/CSS to Image keeps them while your account is active, RenderForm expires free-tier images after 14 days, Switchboard uses a flat seven days on every plan, and several others don't state a policy at all. Seven days versus indefinite is a completely different architecture on your side. Ask the same question about deletion — a documented DELETE endpoint is less common than you'd expect. (Ours expire on a plan-based window returned in every response, and revoke via DELETE /api/v1/shares/{shareId}; that's shorter retention than some vendors here, deliberately. Details in Your Render Came Back as a URL. How Long Does It Last?) One related thing genuinely is a higher-tier feature across this category: bring-your-own-storage, i.e. pointing the renderer at your own S3 bucket. Bannerbear puts it on Enterprise, APITemplate.io on Enterprise, Templated on Scale, Bannerify on Business, Switchboard on Agency. If you need renders landing in your own infrastructure, price that in — we don't offer it at all today. Does your output type carry a multiplier? If you generate PDFs, ask specifically. One credit per page versus two per page doubles your bill and appears nowhere in the headline number. What happens at the limit? Most of this category hard-stops when you exhaust your quota, and requests start failing until the reset. A few sell overage credits instead. Neither is wrong, but they fail differently. A hard stop means a broken feature and an upgrade decision at 2am, while overage means a surprise on the invoice. Know which one you've bought. Do editor exports count? If your team designs in the web editor and exports by hand, check whether those exports draw from the same pool as your API calls. On most platforms they do. Is the free tier recurring? A monthly allowance lets you build, test in CI, and run a small side project indefinitely. A one-time trial bundle lets you evaluate for an afternoon. Both are legitimate; only one is useful to develop against. How many templates can you have? Template caps exist on some entry plans and are a recurring complaint in reviews of this category. If you're generating across a dozen designs, a three-template cap ends the evaluation regardless of render price. A rough decision guide If you need images inside a product, at volume, and engineers own the whole pipeline, start with the budget group. The economics are genuinely better and the missing features are ones you may not need. If you need a track record, integrations that already exist, or video, Bannerbear and Placid are the incumbents for a reason. Pay the premium and stop thinking about it. If non-engineers need to own the designs, you need a real editor, and the field narrows sharply. Most cheap renderers are code-first by design. And if your workload is bursty and human-driven, a few hundred certificates after an event or a set of vouchers per campaign rather than steady API traffic, look for spreadsheet batch processing and check what a manual export costs you. Where we fit, stated plainly Zandovi is $29/month for 5,000 renders, with 100 free per month on a recurring basis. Against the category leaders that's several times more renders per dollar. Against the budget flank it isn't the cheapest, and we're not going to pretend otherwise. What we're actually built around is the combination: a full visual canvas editor where any text, image, QR code or barcode can be a variable; spreadsheet batch generation that outputs a ZIP; print-ready PDF at 300 DPI with no format multiplier; and unlimited manual editor exports on every paid plan, because metering someone's design work by the click never made sense to us. If you need none of that, buy renders from whoever sells them cheapest. That's a real answer, and for a lot of workloads it's the right one. Verify before you commit Every number here has a date on it and a link next to it, and that's deliberate. This category re-prices constantly: over the twelve months to July 2026 at least three of the products named above restructured their plans. Before you sign up for anything, open the linked pricing page and confirm the number yourself, paying attention to the annual/monthly toggle. And build a small proof of concept on the free tier before you commit to a year. Cost per render is easy to compare on a spreadsheet and rarely the thing that decides whether a tool works for you.Sources: Bannerbear pricing, Placid pricing, APITemplate.io pricing, Templated pricing, Zandovi pricing. All figures checked July 2026.

Designing Gift Cards People Actually Redeem

Designing Gift Cards People Actually Redeem

A gift card is an unusual product. Someone pays you today for something you owe later, to a person who didn't choose it. Every card that gets forgotten in a drawer looks like free revenue on this month's numbers and is really a promise sitting on your books, plus a customer who never came in. Breakage rates get quoted anywhere from a few percent to well into double digits, and the honest answer is that it depends entirely on the business. What isn't in doubt is the direction: the easier a card is to understand and use, the more of them come back through the door. A lot of that is design. So this covers what makes a card get redeemed, and then the mechanical part most guides skip: producing a whole set of denominations and codes without laying out each one by hand. Make the value unmissable The amount is the most important element on the card, and it should look like it. Give it more size and weight than anything else, including your logo. The failure mode is a card designed to be tasteful, where the value ends up as small grey text in a corner. Someone pulls it out of an envelope, can't immediately see what it's worth, and puts it back. Hold the design at arm's length. If the number isn't the first thing you read, the hierarchy is wrong. Contrast matters as much as size. A pale gold $50 on a cream background photographs beautifully and is genuinely hard to read in a dim restaurant. Make the redemption path obvious Every question a recipient has to ask costs you redemptions. The card needs to answer four things without anyone thinking about it: what it's worth, where it can be used, how to use it, and whether it expires. That last one deserves care. Gift card expiry is regulated in many places, with minimum validity periods and rules about fees, and the rules differ by country and by state. Check what applies to you rather than copying what another card does. If there's no expiry, saying so plainly is a feature worth printing. Keep the how-to-use line short and specific. "Present this card in store or enter the code at checkout" beats a paragraph of terms. If you need terms, put them on the back in small type where they belong. Design the set, not the card Here's where most gift card projects go wrong. You design a beautiful $25 card, then you need $50, $100 and $250. Then December arrives and you need a festive version of all four. Then a corporate client wants fifty with their logo on them. Designing each one separately means every future change is four to sixteen edits, and they drift apart. One gets the new logo, another keeps the old typography, and after a year your cards don't look like a family. The fix is one master template where the parts that change are variables:Variable Element Notesamount text Format it in the sheet exactly as it should print: $50, not 50.card_code text Mark it required, so a blank cell is caught rather than printing a codeless card.expires_at text Dates print exactly as written, so settle the format in the spreadsheet.occasion text Set its Allowed values to the occasions you actually produce.redeem_qr QR code Encodes the redemption URL for that specific card.Now a new denomination is a row in a spreadsheet, and a rebrand is one edit to one template.Codes that survive being typed by a human If your cards carry a code, someone will read it off a physical card and type it into a phone. Design for that. Drop ambiguous characters from your alphabet. 0 and O, 1 and I and l, 5 and S, 8 and B all cause support tickets, and you lose nothing by excluding them. Group the code so the eye can track it: H4T9-QK2M-7RVX is meaningfully easier to transcribe than H4T9QK2M7RVX. Set the code in a monospace font. Proportional fonts make similar characters harder to distinguish at a glance, and monospace signals "this is a code you type" without a label saying so. Then mark card_code required, so a batch with a blank code fails at upload rather than at the print shop. Generate the codes in the spreadsheet and check the first and last rows after filling down — an off-by-one there is invisible until someone tries to redeem. The QR code beside it does the same job with less friction. Bind a QR element to a variable and each card carries its own redemption link, so a phone can skip the typing entirely. Keep it at least 100×100 px and use the Print Safe button to get the quiet zone right, because a QR crowded against a card edge is a QR that doesn't scan. Match the occasion without forking the design A birthday card and a corporate thank-you shouldn't feel the same, but they should feel like they came from the same business. Handle this with the occasion variable and a swappable image element rather than separate templates. The layout, typography and logo placement stay fixed. The photograph and one or two colours change. Stock imagery is searchable inside the editor across Unsplash, Pexels and Pixabay, so sourcing a seasonal image doesn't mean leaving the app. The discipline is keeping the structure identical across occasions. That's what makes a set of cards read as a range rather than as four unrelated designs. Produce the whole set at once With the template built, the set is a spreadsheet. Download the CSV template from the Batch tab so the headers already match your variable names: amount,card_code,expires_at,occasion,redeem_qr $25,H4T9-QK2M-7RVX,31 Dec 2027,Birthday,https://example.com/gc/H4T9QK2M7RVX $50,P7WD-3NXA-K9TF,31 Dec 2027,Birthday,https://example.com/gc/P7WD3NXAK9TF $100,R2MK-8VQH-XD4N,31 Dec 2027,Thank You,https://example.com/gc/R2MK8VQHXD4NUpload it and every row is validated before anything renders. A missing card code, an occasion outside the allowed values you set on that variable, a column whose name doesn't match the template: all flagged with the row named, so you fix the sheet rather than the output. Then submit and download a ZIP with one file per row. Row caps per job are 25 on Free, 100 on Personal, 200 on Studio, 300 on Team and 400 on Business, so a run of 500 corporate cards gets split across a few jobs. Split them by denomination or by client and each ZIP is something you can hand over as it is.Print and digital are different exports For physical cards, export PDF at 300 DPI. Set the canvas up in millimetres or inches from the start rather than converting later, and pick the DPI before you design, since the options are fixed at 96, 150 and 300. There's no bleed or crop-mark support, so if your design runs colour to the edge, ask your printer what bleed they need and add it by oversizing the canvas yourself, keeping the trim area clear of anything important. Worth knowing before you send the file rather than after. For emailed cards, PNG at 2× scale is the right output. Same template, different export, so the digital and physical versions can't drift apart. What this doesn't do Zandovi generates the card. It doesn't track balances, mark a code as spent, or tell you whether card H4T9-QK2M-7RVX has already been used. That lives in your POS or your ecommerce platform, and it's the part that turns a printed code into a working gift card. Worth being clear about, because a beautifully produced set of cards with no system behind the codes is a set of cards anyone can spend twice. When the spreadsheet stops fitting Batch generation suits how most businesses actually buy gift cards: a run before the holidays, a corporate order, a restock. It stops fitting when cards are sold online and expected instantly. If someone buys a digital gift card at 11pm and wants it in their inbox, you want the same template called from your backend: one POST carrying that card's amount and code, PNG or PDF bytes back, attached to the delivery email. Same template, same variables, nobody at a keyboard. What this costs A run of 100 cards is 100 renders. The free plan's 100 renders a month covers a first batch or a proper test. Personal at $29/month for 5,000 renders covers a seasonal programme comfortably, and manual exports from the editor don't count against it on any paid plan.There are eleven gift card templates in the gallery to start from, and the batch generation guide walks through the upload and validation step by step.