Skip to main content
Most integrations bring cost data into CostGraph. OpenMeter is the opposite direction: CostGraph reports each of your customers’ attributed cloud spend to your OpenMeter account every night as CloudEvents, and OpenMeter aggregates them for billing. OpenMeter is also the metering behind Kong Konnect, and an account there connects the same way - only the API URL differs. You resell or charge back cloud infrastructure; CostGraph decides who spent what, OpenMeter meters it.

​
How it fits together

  1. A virtual tag decides which customer each charge belongs to. You write the rules; every value the tag produces is an OpenMeter subject.
  2. A meter binds that tag key to one meter in your OpenMeter account. Each night CostGraph reports every customer’s attributed spend for each settled day as events of that meter’s event type.
  3. OpenMeter aggregates. The meter sums the reported values per subject, ready for your billing system or OpenMeter’s own billing to price.
Spend is reported in integer cents. Price per cent, or divide by 100 downstream, because OpenMeter does not know what unit the events carry.

​
Connect

1

Create a meter

In OpenMeter, create a meter with a sum aggregation whose value property is $.value. Note its event type - that is what CostGraph reports against.
2

Create an API token

Open your OpenMeter settings and copy an API token. On Kong Konnect this is a personal access token, which starts with kpat_.
3

Connect in CostGraph

Open Integrations, choose OpenMeter, and paste the token. Leave API URL empty for OpenMeter Cloud; set it when your meters live somewhere else. It is the API root including its version, not just the host: a self-hosted instance ends in /api/v1, and an account on Kong Konnect is https://{region}.api.konghq.com/v3/openmeter, with the region matching your Konnect organisation. CostGraph verifies the token before saving anything, and stores it encrypted.
4

Bind a meter

Bind a virtual tag key to one of your meters. CostGraph lists meters by their event type, which is what the events it sends carry.

​
Choose who gets billed

Create a virtual tag key named with an openmeter_ prefix, such as openmeter_subject. The prefix is required: it marks the key as billing-bound, and only prefixed keys can be bound to a meter. The value a rule assigns is the subject the spend is reported under - OpenMeter’s identifier for whoever the usage belongs to: Any field works as the match: a linked account per customer, a resource name prefix, a project, or an existing tag. See Virtual tags for the rule builder and how overlapping rules resolve. Spend the tag does not match is never reported.
OpenMeter creates a subject the first time it sees one, so a mistyped tag value quietly becomes a new metered subject. Check the tag’s values before binding it to a meter, and review what was reported after rule changes.
Because a bound tag key drives billing, CostGraph protects days that were already reported: rules on that key cannot be reordered, and new or edited rules must start from a date that has not been reported yet. Close an old rule with an end date instead of editing it in place.

​
What lands in OpenMeter

Each customer-day is one CloudEvent, with source set to costgraph, type set to the meter’s event type, and subject set to the tag value. The event id is derived from the day and the totals, so a retried run carries the same id and is deduplicated rather than counted twice. Its data carries: Aggregate on $.value with a sum, so that corrections - which are sent as the difference, and can be negative - settle to the right total.
Cloud providers restate recent spend, so CostGraph holds each day for two days before reporting it, then keeps reconciling the last 35 days. Each event is timestamped with the day it belongs to, so a correction lands in that day’s window rather than the day it was sent.

​
Day to day

  • The nightly run reports only what changed, so an unchanged day sends nothing.
  • A day is held back rather than reported wrong when its spend mixes currencies, or a quantity meter meets an unexpected unit. Each held day is recorded with its reason.
  • Deactivating a meter stops reporting but keeps its history, so reactivating resumes from what was already sent instead of double-counting the window.

​
Next steps

Virtual tags

Write the rules that decide which customer each charge belongs to.