Custom Enterprise API Pricing with Private Plans

A deal lands in your inbox at a price your pricing page doesn’t have. A design partner wants to try your API for a quarter before committing. Your team is running a closed beta for exactly seven companies.

Your pricing page has three plans. This deal needs a fourth, visible only to the co-founder who signed it. The temptation is to wire something together: Stripe coupons, an off-platform invoice, a hidden plan with an obscure URL. Every one of those paths costs you metering visibility, audit trail, or the ability to scale.

Private plans in Zuplo are built for exactly this shape of problem: a plan that exists, bills, and meters like any other, but is invisible to everyone except the emails you invite.

Three scenarios that break your pricing page

Custom pricing requests arrive in three flavors, all landing at the same engineering problem.

• Enterprise deals. A signed contract at a negotiated rate, usually per-request pricing with a flat commit. Nothing on your public pricing table reflects it.
• Design partners. Early customers at a discount or free for a fixed window. You need them on the same metering infrastructure as paying customers so you get real usage data, but their billing sheet is different.
• Closed beta access. A new API surface you’re not ready to charge for, available only to a handpicked list. Same gateway, same meters, same developer portal, different visibility.

From the engineer’s seat, all three are identical: a plan that exists, bills correctly, and meters usage, but is invisible to everyone except a short list of emails. Teams that get this right have a portfolio of plans behind the scenes and a clean public pricing page. A few are written up in 5 API Monetization Success Stories.

Where the usual workarounds fall apart

These options seem reasonable on the first deal and fall apart by the third.

• Stripe coupons on a public plan. Gets you a discount, not a custom entitlement. Your enterprise customer still sees the public plan’s limits, and you have no clean way to offer a different feature set without cluttering the public tier.
• Off-platform manual invoicing. You skip Stripe and track usage in a spreadsheet. You lose every piece of metering visibility the gateway gives you: no usage dashboards, no overage alerts, no audit trail when the customer disputes a bill.
• Forked public plans. Clone Pro, rename it “Pro Enterprise”, tweak the price. By the fifth deal your pricing table is a mess and your developer portal shows four “Pro” variants to every signed-in user.

Each scales to approximately zero. Zuplo’s answer is the private plan.

Private plans in Zuplo

A private plan lives in your monetization configuration, bills through Stripe, and meters usage through the same gateway pipeline. The one difference: it’s invisible to anyone except users you explicitly invite by email.

You can set these up two ways. In the Zuplo portal UI, which is the fastest path if invites are the whole story and you just want the plan shipped. Or through the monetization API, which is the right choice when you’re building Zuplo more deeply into your own systems (an internal admin tool, CI/CD, infrastructure-as-code). Same primitive, same capability, different surface.

In the Zuplo portal

In your Zuplo project, head to Services → Monetization → Pricing and click Add Plan. Fill in the plan name and key, then flip the Private Plan toggle on.

Click Create Draft. From here, configure the plan exactly like you would a public one: pick the pricing (flat fee, usage-based tiers, or a combination), attach the features and entitlements for included units, and wire up the meter that feeds usage into the plan. Then publish.

Once published, the plan lands in the Plans list with a Private badge next to its name and an Invites action next to the status.

Click Invites to add customer emails one at a time. Each invite sends the customer a subscribe URL. Only invited users can use it.

With the monetization API

If you’d rather drive plan creation from code (to template it against signed contract terms, or to sit alongside the rest of your provisioning pipeline), the same flow is three API calls.

Before you start, grab two values from your Zuplo project: the ZUPLO_BUCKET_ID (your monetization bucket, available in the project’s Monetization settings) and a ZUPLO_API_KEY (created in project settings, treat it like any other server-side secret).

1. Create the plan with the private-plan flag. A plan becomes private when you set "zuplo_private_plan": "true" in its metadata field. Everything else works identically to a public plan: rate cards, features and entitlements, prorating, and Stripe Checkout. billingCadence uses ISO 8601 durations, so P1M means monthly.

Below is a realistic enterprise deal: a $10,000 monthly commit including 1 million requests, with $0.002 per request overage. featureKey values like monthly_fee and api reference features already defined in your monetization bucket, so adjust to match your keys.

curl -X POST "https://dev.zuplo.com/v3/metering/${ZUPLO_BUCKET_ID}/plans" \
  -H "Authorization: Bearer ${ZUPLO_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{
    "key": "enterprise_acme",
    "name": "Acme Enterprise",
    "description": "Custom tier for Acme (negotiated 2026-04-16)",
    "billingCadence": "P1M",
    "currency": "USD",
    "metadata": {
      "zuplo_private_plan": "true"
    },
    "phases": [
      {
        "key": "default",
        "name": "Default",
        "duration": null,
        "rateCards": [
          {
            "key": "monthly_commit",
            "name": "Monthly Commit",
            "featureKey": "monthly_fee",
            "type": "flat_fee",
            "billingCadence": "P1M",
            "price": {
              "type": "flat",
              "amount": "10000.00",
              "paymentTerm": "in_advance"
            }
          },
          {
            "key": "api_requests",
            "name": "API Requests",
            "featureKey": "api",
            "type": "usage_based",
            "billingCadence": "P1M",
            "entitlementTemplate": {
              "type": "metered",
              "usagePeriod": "P1M",
              "issueAfterReset": 1000000,
              "isSoftLimit": true,
              "preserveOverageAtReset": false
            },
            "price": {
              "type": "tiered",
              "mode": "graduated",
              "tiers": [
                {
                  "upToAmount": "1000000",
                  "flatPrice": { "type": "flat", "amount": "0" },
                  "unitPrice": null
                },
                {
                  "flatPrice": null,
                  "unitPrice": { "type": "unit", "amount": "0.002" }
                }
              ]
            }
          }
        ]
      }
    ]
  }'

Save the id from the response. You need it for the next two calls.

2. Publish the draft. Plans are created as drafts. A draft plan can’t be subscribed to, so until you publish it, even an invited user sees nothing on the pricing page.

curl -X POST "https://dev.zuplo.com/v3/metering/${ZUPLO_BUCKET_ID}/plans/${PLAN_ID}/publish" \
  -H "Authorization: Bearer ${ZUPLO_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{}'

Once published, a plan can’t be modified. If terms change later, create a new plan, publish it, and invite the customer. In practice the customer schedules cancelation of the old subscription at period end and subscribes to the new one. Gateway traffic doesn’t interrupt; the cutover lands on the billing boundary.

3. Invite the user by email. The user doesn’t need to exist in your Zuplo tenant yet. The invite is by email and activates the first time they sign in with that address.

curl -X POST "https://dev.zuplo.com/v3/metering/${ZUPLO_BUCKET_ID}/plan-invites" \
  -H "Authorization: Bearer ${ZUPLO_API_KEY}" \
  -H "Content-Type: application/json" \
  -d "{
    \"email\": \"cto@acme.com\",
    \"planId\": \"${PLAN_ID}\"
  }"

That’s the whole flow. No quoting system (CPQ) to build, no coupon juggling, no off-platform invoice.

What each side actually sees

Uninvited users see your Free, Pro, and other published tiers. The Acme Enterprise plan doesn’t appear on the public pricing table, doesn’t surface in the API responses that back it, and isn’t visible to anyone who signs in without a matching invite.

Invited users: when cto@acme.com signs in to the developer portal, the Acme Enterprise tier appears alongside the public plans. They subscribe through the same Stripe Checkout flow, get an API key provisioned automatically, and usage flows through the same meters. If you’ve already built a developer portal for your public plans, nothing changes to support private ones. The full portal setup is covered in Building a Monetized API, Part 4.

Invites are managed through the same metering API, so fixing a typo or revoking access is another API call, not a support ticket.

A single email can be invited to multiple private plans (useful when an enterprise customer also gets beta access). Multiple emails can be invited to one plan, which is how you handle a customer with a team.

Stacking private and public plans

Private plans sit alongside public plans. A customer can hold multiple active subscriptions, and that matters for real enterprise deals.

A common pattern is an enterprise customer on a negotiated base plan (private, fixed commit plus overage) plus an add-on credit pack from your public pricing page (pay-as-you-go top-up). Two subscriptions, two sets of entitlements, one customer.

Each subscription gets its own API key by default, so traffic routes to the right bucket without the customer thinking about it. Usage is tracked independently, and invoices reflect the two separately.

For your side, this is a lever. You don’t need to invent a “private plan with bundled credit pack” frankenstein when a customer upgrades. Sell them the existing public credit pack as a second subscription and keep the private base plan clean. The full subscription state machine is in the subscription lifecycle doc.

Private plans, end to end

The full flow, in order:

• Create the plan with the Private Plan toggle on (portal UI) or metadata.zuplo_private_plan: "true" (API), with your rate card.
• Publish the plan to move it out of draft.
• Add invites for each customer email.
• Confirm that signing in with an invited email shows the private tier.
• Record the plan key and plan ID somewhere retrievable.

Custom enterprise pricing is one of the first places a growing API business starts needing shape it didn’t need on day one. Private plans are the primitive that covers it: same gateway, same meters, same Stripe billing path as your public tiers, with one piece of metadata that controls who sees them. The three scenarios this post opened with (enterprise deals, design partners, closed betas) all collapse to the same recipe above, so the next one, and the one after, don’t need a new system.