@meistrari/metering

Metering client used to publish consumption events.

Transport selection

Inngest is still the default transport. When transport is omitted, the client selects the transport from the available credentials:

| Available credentials | Selected transport | | --- | --- | | Inngest only | Inngest | | Trigger.dev only | Trigger.dev | | Inngest and Trigger.dev | Inngest | | None | Inngest |

This keeps the migration safe: Trigger.dev is only selected automatically when it is the only configured transport.

To send events through Trigger.dev explicitly, enable the Trigger transport:

import { useMetering } from '@meistrari/metering'

const metering = useMetering('tela-api', {
  transport: 'trigger',
})

The client resolves credentials in this order:

| Option | Environment fallback | Required | | --- | --- | --- | | eventKey | INNGEST_EVENT_KEY | For Inngest publishing | | signingKey | INNGEST_SIGNING_KEY | No | | triggerSecretKey | METERING_TRIGGER_SECRET_KEY | Only for Trigger.dev |

The metering client intentionally uses METERING_TRIGGER_SECRET_KEY instead of the generic TRIGGER_SECRET_KEY. This prevents a host project that already uses Trigger.dev from accidentally sending metering events to its own Trigger.dev project.

When the Trigger.dev transport is used, the metering client passes its credentials only for the metering task trigger call. It does not call Trigger.dev's global configure(), so it will not replace or reuse a Trigger.dev client already configured by the host project.

You can also pass the values explicitly:

const metering = useMetering('tela-api', {
  transport: 'trigger',
  triggerSecretKey: env.METERING_TRIGGER_SECRET_KEY,
})

If transport: 'trigger' is enabled and neither triggerSecretKey nor METERING_TRIGGER_SECRET_KEY is available, the client throws before triggering the task.