Reporting Usage

Feature usage can be checked by calling tierClient.can(), and reported using tierClient.report().

In general, if can() returns false, then the user is over the limit or doesn't have access to the feature in their plan, so you should not give them the feature.

report() can be called right away, ahead of delivering the feature, or at any arbitrary time.

For example:

if (await tier.can('org:acme', 'feature:foo')) {
  consumeOneFoo('acme')
  await tier.report('org:acme', 'feature:foo')
} else {
  // suggest they buy a bigger plan, maybe?
  showUpgradePlanUX('acme')
}

Table of Contents

Counters

Tier of course has no idea what your actual features are, really. You could be shipping stamps, serving files, washing cars, anything.

Tier is, at its core, a series of timers and counters that your app uses to track the usage of whatever it is your app does.

Internally, there is a positive counter, and a negative counter, so that Tier can track each usage increase and decrease over time.

Overages

When usage puts an org beyond the last tier in their plan for that feature, they go into an "overage" state.

Overages are not billed, but they are reported.

If a feature isn't delivered, you can tier.report() with a negative number to roll it back.

Timing

Usage is counted against the phase in the org schedule corresponding to their effective date.

This "tallying up" of usage occurs at the end of the billing phase. Note that report() and appendPhase() both take a Date argument indicating when they are effective. (In both cases, the effective date defaults to "right now".)

More Usage Examples

See the SDK documentation for more examples of using the Tier client to decide who gets access to your app's features.