How to Use the Mockupanda API Wallet to Forecast and Control Your Monthly Mockup Costs as Your POD Catalog Scales

Scaling a print-on-demand catalog is exciting right up until you open your mockup bill. If you are generating listing images programmatically, your spend is directly tied to your catalog size, your template count per design, and how often you refresh images. Without a clear model for how those numbers interact, costs can drift in ways that feel unpredictable.

The good news is that Mockupanda's API wallet makes this unusually straightforward to reason about. The pricing is flat, the wallet is prepaid, credits never expire, and there is a live balance endpoint you can query at any time. This post walks you through building a real cost forecast, using the wallet endpoint to monitor spend, structuring your API calls efficiently, and keeping your budget in control as your catalog grows from tens of designs to hundreds.

Understanding the Pricing Model Before You Forecast

Good forecasting starts with understanding the unit economics, and the Mockupanda API keeps them simple.

One credit, one mockup, one cent

Every mockup you generate costs exactly 1 credit, which equals $0.01 USD. That rate is flat regardless of how many you generate. There are no volume discounts and no bonus credits on larger top-ups: $10 buys 1,000 mockups, $25 buys 2,500 mockups, $100 buys 10,000 mockups, and every increment in between converts at the same rate.

This flat structure is actually a forecasting advantage. You never need to calculate tiered rates, figure out where you land in a pricing band, or worry about losing a discount if your volume dips one month. Your cost for any time period is simply: number of mockups generated multiplied by $0.01.

There is one more detail worth noting: failed requests cost zero credits. If a request fails before any processing happens, you are not charged. This means experimentation during development does not quietly drain your wallet.

What counts as one mockup

A single mockup is one rendered image from one template. A multi-frame template (a diptych or triptych with multiple artwork panels) still counts as one mockup if it is one template. So the unit of billing is the template render, not the number of artwork frames within it.

If you use Sets, the billing follows the same logic: a set of three templates costs the same as three template IDs passed directly. You are charged per rendered mockup, so a set of three costs three credits.

No subscription required for API access

The API wallet is completely separate from the web app subscription plans. You can use the API on a pay-as-you-go basis without any monthly fee. You top up a prepaid wallet from a minimum of $5.00 and use credits as you generate mockups. Credits never expire, so a top-up you make today is still valid months from now if your catalog grows more slowly than you expected.

Takeaway: Your base cost model is simply: (designs) x (templates per design) x $0.01. Lock that number in before you look at anything else.

Building a Cost Forecast for Your Catalog

With the unit economics clear, you can build a forecast that scales with your catalog size. The key variables are how many designs you have, how many mockup templates you apply per design, and how often you regenerate mockups.

Estimating initial catalog generation costs

Start with a static snapshot of your current or planned catalog. If you have 200 designs and you want to generate 10 mockup variations per design for listing images, that is 2,000 mockups. At $0.01 each, your one-time cost to populate the catalog is $20.

Scale that up: 500 designs at 10 templates each is 5,000 mockups, or $50. A thousand designs at 15 templates each is 15,000 mockups, or $150. These are one-time generation costs, not recurring monthly costs, which makes the initial investment easy to justify.

Here is a simple table to anchor your thinking:

Estimating ongoing costs from new listings

Once your catalog is live, your recurring spend comes from new designs entering the catalog. If you add 50 new designs per month and apply 10 templates to each, that is 500 new mockups per month, or $5.00. At 10 templates per design and 200 new designs per month, you are looking at $20 per month.

The number to watch is your monthly design intake rate multiplied by your templates-per-design target. That product, multiplied by $0.01, gives you a reliable monthly budget number you can revisit as your catalog strategy evolves.

Accounting for regeneration and testing

Beyond new listings, factor in two additional sources of mockup generation: testing and regeneration. During development and template selection, you will generate mockups you do not keep. Since failed requests cost zero credits, the only real cost here is successful test renders. Set aside a small buffer, perhaps 5 to 10 percent of your estimated production volume, to cover this.

Regeneration happens when you update a template, change your artwork, or refresh listings. If you periodically refresh all mockups for seasonal campaigns, those regeneration runs add to your monthly total. Build that cadence into your forecast explicitly rather than treating it as an afterthought.

Takeaway: Write down three numbers: initial catalog generation cost, monthly new-listing cost, and a regeneration buffer. Add them up and that is your starting budget for wallet top-ups.

Reading Your Wallet Balance and Transaction History

Forecasting is about projections. Monitoring is about reality. The Mockupanda API gives you a billing endpoint to check your actual balance and recent transactions so you can compare the two.

The GET /billing/wallet endpoint

You can query your wallet balance and transaction history using the GET /api/v1/billing/wallet endpoint:

curl -X GET https://www.mockupanda.com/api/v1/billing/wallet \
  -H "Authorization: Bearer YOUR_SUPABASE_ACCESS_TOKEN"

One important detail: this endpoint uses your logged-in dashboard session token, not an mk_ API key. Sending an API key returns a 401 error. This means the balance check cannot be called from a server-to-server integration using your standard API key. It is designed to be called from your dashboard session or a script that authenticates as your user account.

Interpreting the response

The response gives you everything you need to understand your wallet position:

{
  "wallet": {
    "balance_cents": 1250,
    "lifetime_topup_cents": 5000,
    "lifetime_spent_cents": 3750
  },
  "mockup_cost_cents": 1,
  "transactions": [
    {
      "type": "usage",
      "amount_cents": -1,
      "description": "Mockup generation (bedroom-poster-01)"
    },
    {
      "type": "topup",
      "amount_cents": 2500,
      "description": "Wallet top-up"
    }
  ]
}

The balance_cents field tells you your current balance in cents. Divide that by mockup_cost_cents (currently 1) to get the number of mockups remaining. In the example above, 1250 cents divided by 1 cent per mockup means 1,250 mockups left in the wallet.

The lifetime_topup_cents and lifetime_spent_cents fields let you calculate your all-time spend without keeping separate records. In the example, $50 topped up and $37.50 spent means 3,750 mockups generated since the account was created.

The transactions array gives you a chronological log with individual template IDs mentioned in each usage entry, which lets you audit which templates consumed the most credits.

What happens when credits run out

If a request would exceed your balance, the API returns an INSUFFICIENT_CREDITS error before any processing or charge occurs. This is a clean failure: you are not partially charged, and you know exactly why the request failed. Build handling for this error code into your integration so your pipeline surfaces it clearly rather than silently failing.

Takeaway: Query your wallet balance weekly or after large batch runs. Compare your lifetime_spent_cents against your forecast to catch drift early, while you still have time to adjust.

Structuring API Calls to Maximize Efficiency

Beyond tracking spend, you can reduce unnecessary credit consumption by structuring your API calls smartly. Two features make a significant difference at scale: batch mode and Sets.

Using batch mode to reduce overhead

Instead of sending one request per template, you can pass up to 12 template IDs in a single request using template_ids. This does not reduce your cost per mockup, since billing is still per rendered output, but it reduces the number of API round trips and makes your pipeline simpler to manage.

curl -X POST https://www.mockupanda.com/api/v1/mockups/generate \
  --http1.1 \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "template_ids": ["bedroom-poster-01", "frame-wall-02", "living-room-03"],
    "artwork_url": "https://example.com/art.jpg",
    "response_format": "json"
  }'

With 12 templates per request and a daily limit of 10,000 requests per API key, you can generate up to 120,000 mockups per day from a single key. If you need higher throughput, you can create multiple API keys since there is no limit on the number of active keys per account.

Using Sets to standardize your template groups

Sets are saved, named groups of templates you define once in the app and then reference by a set_id in your API calls. For cost forecasting, Sets have a useful property: they make your templates-per-design number stable and intentional.

When you define a set called, say, "wall-art-standard" with eight templates, every design you push through that set generates exactly eight mockups at exactly $0.08 per design. That predictability is valuable when you are budgeting across hundreds of designs.

Note that Sets count toward the same 12-template-per-request limit, so a set with more than 12 templates returns a TOO_MANY_TEMPLATE_IDS error. Keep your sets within that limit or split them across multiple requests.

One cost-saving detail: if a template in a set no longer exists (because you deleted it or it was removed), generation skips that ID and lists it in skipped_template_ids. You are only charged for templates that actually render. So stale set entries do not silently inflate your bill, though you should clean them up to keep your output consistent.

Staying within rate limits without burning credits

The API allows 100 requests per minute and 10,000 requests per day per key. If you exceed the per-minute limit, you get a 429 response with a retry_after field telling you how many seconds to wait. Implement exponential backoff or simply honor the retry_after value before retrying.

From a cost perspective, rate limit errors cost zero credits, so hitting the limit does not drain your wallet. The risk is pipeline stalls that slow down your catalog generation. Pace large batch jobs to stay comfortably below 100 requests per minute, especially if you are sharing an API key across multiple processes.

Takeaway: Use batch mode with up to 12 templates per request to reduce API calls, use Sets to lock in a stable templates-per-design count, and respect rate limits to keep your pipeline running smoothly without unexpected pauses.

Topping Up Strategically as Your Catalog Scales

Since credits never expire and there is no auto-recharge, your top-up strategy is a simple planning exercise rather than an automated system.

How to add credits

Top-ups are done manually through the dashboard. Log in, navigate to Dashboard, then Billing, enter an amount between $5.00 and $1,000.00, and complete payment via Stripe. Credits are added as soon as payment is confirmed. Stripe accepts Visa, Mastercard, American Express, debit cards, Apple Pay, and Google Pay.

Programmatic top-up via the API is not currently supported, so you cannot automate wallet refills from your code. That means you need to monitor your balance proactively and top up before you run dry, rather than relying on automatic recharge.

Choosing your top-up amount

Since the conversion rate is flat across all top-up amounts, the only reason to choose a larger top-up is convenience: fewer manual refill actions. If your monthly mockup spend is around $20, a $100 top-up covers roughly five months of operation without any further action. If you are running a large initial catalog generation of $150, top up for the full amount in one go rather than topping up repeatedly mid-run.

The maximum single top-up is $1,000, which covers 100,000 mockups. For most POD sellers, a single large top-up at catalog launch followed by smaller monthly top-ups as new designs are added is a comfortable operating pattern.

Monitoring spend against budget without billing alerts

Billing alerts and auto-recharge are not currently supported, so your monitoring strategy needs to be manual or script-assisted. The most practical approach is to query the wallet endpoint periodically and compare your current balance against a threshold you set based on your forecast.

For example, if your monthly generation rate is 2,000 mockups and you want at least two months of runway in the wallet at all times, keep your balance above $40. When the balance drops toward that threshold, top up. You can run a simple daily or weekly script that fetches the wallet endpoint with your dashboard session token and logs the balance alongside your projected runway.

Takeaway: Top up proactively based on your forecast rather than waiting for failures. Since credits never expire, topping up generously for an initial catalog build is always safe, and the funds carry forward indefinitely.

Putting It All Together: A Practical Scaling Checklist

As your catalog grows, the mechanics stay the same but the numbers get larger. Here is a practical checklist you can revisit each time you expand.

Before launching a new batch of designs

First, calculate your expected generation cost: number of new designs multiplied by templates per design multiplied by $0.01. Then check your current wallet balance using the GET /billing/wallet endpoint. If your balance is less than twice your expected cost (leaving runway for ongoing operations), top up before you start the batch.

Group your templates into Sets with a consistent count, so every design goes through the same set and your cost per design is fixed. Use batch mode with up to 12 templates per request to process designs efficiently without hitting rate limits.

After each major batch run

Query the wallet endpoint again and compare your lifetime_spent_cents against your pre-run forecast. If actual spend exceeded your estimate, find out why: were there more successful renders than planned, or did some designs run through extra template groups? Adjust your forecast model accordingly.

Review the transaction log for any unexpected usage patterns, like a template being rendered far more times than expected, which could indicate a bug in your pipeline sending duplicate requests.

As your catalog reaches the hundreds of designs

At catalog scale, your monthly generation cost from new listings is stable and predictable. The wildcard is regeneration: seasonal refreshes, template updates, or A/B testing of new mockup styles. Track these separately in your forecast so they do not surprise you.

If your volume reaches a point where the $1,000 maximum single top-up feels constraining, the documentation mentions a High Volume section for situations where standard top-up amounts are insufficient.

Mockupanda is built around the idea that listing image generation should be fast, clean, and cost-transparent. At $0.01 per mockup with no subscription, no volume tiers, and credits that never expire, the wallet model is genuinely one of the simpler billing systems you will encounter in the POD tooling space. The main discipline it requires from you is proactive monitoring and intentional top-up timing, since there is no automated safety net. Build that habit early, anchor it to your forecast, and your mockup costs will scale as smoothly as your catalog does.