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 beamberflo-metering-inbound
.handler/export
The name of the exported type. Value should beAmberfloMeteringInboundPolicy
.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.user
contains the customer ID. For example.data.accountNumber
would read therequest.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;
}