Amberflo Metering / Billing

Amberflo (amberflo.io) is a usage metering and billing service. This policy allows you to meter API calls going through Zuplo and send them to your Amberflo account using your Amberflo API key.

Add the policy to each route you want to meter. Note you can specify the Meter API Name and Meter Value (meter increment) at the policy level.

Configuration#

{
  "name": "my-amberflo-metering-inbound-policy",
  "policyType": "amberflo-metering-inbound",
  "handler": {
    "module": "$import(@zuplo/runtime)",
    "export": "AmberfloMeteringInboundPolicy",
    "options": {
      "apiKey": "YOUR_API_KEY",
      "customerIdPropertyPath": ".data.accountNumber",
      "meterApiName": "api-calls",
      "meterValue": 1,
      "statusCodes": "200-299, 304"
    }
  }
}

Options#

  • name the name of your policy instance. This is used as a reference in your routes.
  • policyType the identifier of the policy. This is used by the Zuplo UI. Value should be amberflo-metering-inbound.
  • handler/export The name of the exported type. Value should be AmberfloMeteringInboundPolicy.
  • handler/module the module containing the policy. Value should be $import(@zuplo/runtime).
  • handler/options The options for this policy:
    • apiKey

      The API key to use when sending metering calls to Amberflo

    • meterApiName

      The name of the meter to use when sending metering calls to Amberflo (overridable in code)

    • meterValue

      The value to use when sending metering calls to Amberflo (overridable in code)

    • customerIdPropertyPath

      The path to the property on request.usercontains the customer ID. For example .data.accountNumber would read the request.user.data.accountNumber property.

    • customerId

      The default customerId for all metering calls - overridable in code and by customerIdPropertyPath

    • dimensions

      A dictionary of dimensions to be sent to Amberflo (extensible in code)

    • statusCodes

      A list of successful status codes and ranges "200-299, 304" that should trigger a metering call to Amberflo - defaults to result.ok (200-299) if not set.

    • url

      Optional, the URL to send metering events to (defaults to https://app.amberflo.io/ingest). This is useful for testing purposes.

You can set the customerId globally (not recommended) by setting it at the policy level or use the customerIdPropertyPath to read the customerId from the user object on each request. For example, if you're using API Key auth or JWT auth and want to use the sub property as the customerId, you would set the value as follows

"customerIdPropertyPath" : ".sub"

You can also dive into the properties of the metadata. Imagine the request.user property is as follows (either based on contents of a JWT token or API Key metadata)

{
  "sub": "bobby-tables",
  "data": {
    "email": "bob@example.com",
    "name": "Bobby Tables",
    "accountNumber": 1233423,
    "roles": ["admin"]
  }
}

You could access the accountNumber property as follows. Note the required preceding '.'.

"customerIdPropertyPath" : ".data.accountNumber"

You can also set many of the properties of the meter payload programmatically, either in a custom policy or handler. Here is some example code in a custom inbound policy:

import {
  AmberfloMeteringPolicy,
  ZuploContext,
  ZuploRequest,
} from "@zuplo/runtime";
 
export default async function (
  request: ZuploRequest,
  context: ZuploContext,
  options: MyPolicyOptionsType,
  policyName: string,
) {
  AmberfloMeteringPolicy.setRequestProperties(context, {
    customerId: request.user.sub,
    meterApiName: request.params.color,
  });
 
  return request;
}

Was this article helpful?

Do you have any questions?Contact us
Check out ourproduct changelog