Packaging API discovery checklist for brands

Start with the job the API must do

Before you compare endpoints, write the job in plain language. Which systems create demand, such as an ERP, ecommerce storefront, procurement tool or 3PL? Which events need to cross the boundary: catalog sync, quote request, order submission, shipment status, invoice or claim? Which decisions stay human, such as artwork approval, MOQ exceptions, address validation or substitution? Ask each vendor to map every event to an endpoint, webhook or manual step. A gap in that map is more important than a long feature list.

Document catalog, pricing and MOQ fields

A packaging API may expose fields such as product dimensions, material, print method, minimum order quantity, lead time and price breaks, but what each vendor exposes varies, so ask rather than assume. Ask for a field-level schema that states required and optional fields, units, null behavior, currency, tax and freight exclusions, and update frequency. Confirm whether a price response is a firm order price or a request for quote. Ask how MOQ changes when decoration, size or material changes. Do not assume a catalog field means the same thing across vendors.

• Ask for sample payloads for a simple SKU and a decorated SKU.
• Confirm how discontinued items and substitutions appear.
• Ask whether the API versions schemas and how long old versions remain.

Test the order lifecycle and failure paths

Request a sandbox and a written test script. Test draft creation, submission, cancellation, partial shipment, return and duplicate submission. Ask how idempotency keys work, how retries are scheduled, how webhooks are signed and replayed, and how dead-letter events are handled. Confirm what happens when price or inventory changes between quote and order. Ask for stable error codes and examples. A happy-path demo does not show whether your team can recover from a failed order. If the API exposes transit or package performance test data, ask which test procedure, test objective and distribution environment the data represents; ISTA guidance says protocol selection depends on the test objective and knowledge of the distribution environment. Treat such data as context for your own evaluation, not as a compliance determination.

Check artwork, barcode and prepress handoffs

If the API accepts artwork, ask which file formats and PDF/X settings the vendor expects, how color management is agreed, how spot colors are named and how proofs are approved. Adobe's packaging prepress material describes PDF rendering and spot color handling in prepress, so ask the vendor to explain its own PDF and spot color workflow rather than assuming a generic handoff. If the API returns barcode assets, ask whether a verification report exists. GS1 verification guidance lists symbol contrast and quiet zones among assessed parameters, so a generated barcode image is not the same as a verified barcode.

• Ask where dieline layers and printer marks should sit, following the converter's instructions.
• Ask who approves artwork versions and how changes are logged.
• Ask whether barcode reports include the parameters your channel checks.

Review security, data ownership and exit terms

Ask how authentication works, which scopes exist, how secrets rotate, whether IP allowlisting is available and what audit logs you can export. Confirm who owns catalog data, order history and artwork files, and how you export them at termination. Ask for incident notification, subprocessor review and retention terms. If a partner directory includes rankings, reviews or endorsements, ask how material connections are disclosed. The FTC rule source supports the principle that connections which might affect the weight of an endorsement can require clear disclosure when the audience would not expect them.

Run a hypothetical sandbox comparison

Here is a hypothetical sandbox comparison, not a vendor quote or market benchmark. A brand expects 1,200 packaging order lines per month. In a trial sized to one month of volume, Vendor A produces 24 failed submissions out of 1,200 attempts, a 2 percent failure rate. Vendor B produces 6 failures, a 0.5 percent rate. Assume each failure needs 10 minutes of manual review at an illustrative internal labor rate of 50 dollars per hour. Vendor A: 24 failures times 10 minutes equals 240 minutes, or 4 hours. Four hours times 50 dollars equals 200 dollars per month. Vendor B: 6 failures times 10 minutes equals 60 minutes, or 1 hour. One hour times 50 dollars equals 50 dollars per month. The illustrative review-labor difference is 150 dollars per month, before platform fees. This arithmetic does not validate either vendor or predict production results.

Use a decision table to compare vendors

Score each vendor against the same discovery areas. Keep the scoring visible so that a polished demo does not outweigh a missing failure path or an unclear export process.

Practical discovery checklist

Use this checklist as a working agenda for vendor calls and sandbox reviews. Adapt it to your own systems and keep the answers in one decision log.

• Write three must-have flows and one must-not-fail flow before you book a demo.
• Request sandbox credentials and a test data set.
• Ask for field-level catalog and pricing documentation.
• Test a duplicate submission with the same idempotency key.
• Test a price change between quote and order.
• Test a webhook replay and a failed webhook.
• Ask for artwork format, proof and version rules.
• Ask for a barcode verification sample if barcodes are in scope.
• Ask for data export and termination steps.
• Ask for incident notification and security evidence.
• Score each vendor against the must-have flows, not the feature count.
• Record assumptions and open questions in a shared decision log.

Scope limits and what this checklist does not decide

This checklist is Teal's editorial planning framework for evaluating third-party packaging APIs. It is not a description of a live Teal API program, a security certification, a legal opinion or a compliance determination. It does not replace your own security review, counsel review, contract review or sandbox testing. It does not decide channel requirements; confirm those in your own agreement. If products are regulated, hazardous, food-contact or child-resistant, add a review workflow with qualified reviewers. The cited sources support only the specific principles named in the source list, not the whole checklist.

Questions about Packaging API evaluation