Analytics

Reporting across the enterprise account.

Dashboard stats

query {
  dashboardStats { ... }
}

Four headline figures: totalVouchers, activeVouchers, thisMonthUsage and totalSavings. It takes no arguments and covers the account as it stands, so there is no period to pass.

totalSavings is a list of Money — an amount and its currency — with one entry per currency your vouchers are denominated in. Savings in different currencies are never summed, so do not add the entries together either.

Requires enterprise:core:read — note this sits under core, not billing.

Usage summary

query {
  usageSummary(
    periodStart: "2026-07-01T00:00:00Z"
    periodEnd: "2026-08-01T00:00:00Z"
  ) { ... }
}

Volume over a period, not spend: totalUsers, totalVouchersCreated, totalVouchersRedeemed, totalApiCalls, totalWebhookDeliveries and storageUsedMb. No field on it is monetary, so it reconciles an invoice rather than pricing anything. Both periodStart and periodEnd are required — there is no all-time variant.

Requires enterprise:billing:read. See Billing.

Voucher analytics

query {
  voucherAnalytics(
    startDate: "2026-07-01T00:00:00Z"
    endDate: "2026-08-01T00:00:00Z"
  ) { ... }
}

How vouchers are actually being redeemed, and the one place the API breaks spending down by department — departmentBreakdown returns a department name with its usageCount, uniqueUsers and totalSavings, which is the basis for cost-centre allocation. Alongside it, voucherPerformance ranks individual vouchers, timeAnalysis buckets redemptions by hour of day, and usageSummary carries the headline totals.

Money comes back per currency here too. totalSavings on a department and totalSavings and averageSavingsPerUse on usageSummary are lists with one Money entry per currency. voucherPerformance[].totalSavings is a single Money, in that voucher's own currency.

Both dates are optional — omit for all time.

Per-voucher detail comes from voucherUsageStats(voucherId:). Requires enterprise:vouchers:read. See Vouchers.

Building a reporting job

There is no webhook or subscription on the Enterprise API — reporting is request-driven, so you schedule it.

Two things to get right:

Query per period, not per day-so-far. Pass explicit periodStart and periodEnd so a re-run produces the same answer.
Spread the schedule. A job that fires everything at midnight will burst through the rate limit. At 1000 requests per minute you have room, but not if every enterprise you manage syncs simultaneously.

Log x-request-id from each response so a discrepancy is traceable later.

Reference

Generated reference — every type, field and argument, built from the live schema.

Enterprise billing

Built with