# API plans, limits and uptime

URL: /products/api/plans-and-uptime · Id: `page:products/api/plans-and-uptime`

> How to package an API so developers can start free, grow without surprises, and buy an uptime promise once production depends on it.

An API plan is an [Offer](/business/nouns/offer) whose [Entitlements](/business/nouns/entitlement) name the calls it allows and whose [Limits](/business/nouns/limit) say how many. Most APIs need three plans and one uptime promise, on the largest.

## Three plans
Leaseline sells renewal dates by API. Its plans follow the shape most developer APIs settle on:

| Offer | Monthly | Calls | Past the cap | Rate |
| --- | --- | --- | --- | --- |
| `free` | $0 | 1,000 a month | Refused, naming `growth` | 5 a second |
| `growth` | $99 | 50,000 a month | A cent per call, through the [Meter](/business/nouns/meter) | 25 a second |
| `scale` | $499 | 500,000 a month | Half a cent per call | 100 a second, and 99.9% uptime |

The `free` plan is a [Price](/business/nouns/price) of zero, so every developer who takes a key becomes a [Customer](/business/nouns/customer) you can see and reach. Keep it big enough to build a working prototype, and small enough that production needs a paid plan.

Bundles beat pure metering once a customer's usage is steady. A developer can predict $99, and nobody can predict a meter.

## Quotas and rate limits
A quota caps calls per period and bills or refuses past it. A rate limit caps calls per second and protects the service. Both are Limits; they differ in period and in what happens past them.

| | Monthly or daily cap | Rate limit |
| --- | --- | --- |
| Window | A month or a day | A second or a minute |
| Resets | `calendar`, at the top of the period, so customers budget for it | `rolling`, so a burst cannot game the reset |
| Past it | The Offer's `atBound`: `stop`, `overage` or `upgrade` | 429 [`rate-limited`](/code/api/errors/rate-limited), with `Retry-After` |

Every response carries `RateLimit-Remaining` and `RateLimit-Reset`, and the [Portal](/business/nouns/portal) shows each quota against its reset. Use `overage` on paid plans, because a refused call in production costs your customer more than the cent. [Rate limits](/code/platform/rate-limits) covers the mechanism.

## Uptime
An uptime promise is a term on the Offer: the share of each month the API answers, and the credit owed below it.

```json
{
  "uptime": {
    "target": 99.9,
    "credits": [
      { "below": 99.9, "percent": 10 },
      { "below": 99, "percent": 25 }
    ]
  }
}
```

A [Monitor](/business/nouns/monitor) checks the API every minute from several regions, and the [status page](/systems/status-pages) shows the month so far. At month end, each Customer owed a credit gets a [Credit Grant](/business/nouns/credit-grant) on its next [Invoice](/business/nouns/invoice), with no claim to file.

Promise uptime only on plans a business depends on, and only what the last 90 days already show. Enterprise buyers ask for 99.9%; 99.99% allows about four minutes of downtime a month.

## Next
- [Promise uptime on a plan](/products/api/promise-uptime) and [cap usage on a plan](/products/offers/cap-usage-on-a-plan): the asks.
- [Your customers' API keys](/products/api/customer-keys): how each plan reaches a key.
- [Pricing models](/products/pricing/models): metered, bundled and credit plans side by side.