Group Transactions API

Feature Requests Engine Features
1

The Problem
Right now, the Group Transactions API (/v2/groups/{groupId}/transactions) is a “black box” for financial data. The currency.amount field only shows the final Robux deposited into the group after fees.

Because the API doesn’t provide the original price paid by the user, it’s impossible to get a clear picture of total sales. We’re essentially seeing the “payout” but not the “sale,” which makes high-level accounting a nightmare.

The “Reverse-Math” Issue (Additional Context)
The common workaround is to try and reverse-calculate the gross amount (e.g., price the group gets / 70 * 100). However, this is fundamentally broken for two reasons:

  1. Rounding Errors: Because Roblox handles decimals/rounding internally during the fee deduction, multiplying the net value back up often results in a number that is slightly off from the actual sticker price.
  2. Inconsistency: If Roblox ever adjusts fee structures or introduces new transaction types, hardcoded math in our external dashboards will immediately become legacy debt and provide false data to stakeholders.

The Impact
If we had a grossAmount or a feePercentage field, it would drastically improve how we manage group-owned experiences:

  • Professional Analytics: I’m building a web portal for developers where “Gross vs. Net” is a standard KPI. Right now, I can only show what they earned, not what the game actually generated in total volume.
  • Team Transparency: For groups with multiple stakeholders, it’s hard to build trust when you can’t show exactly how much a user spent versus what the group kept.
  • A/B Testing & Sales: If I change a price from 500 to 450 Robux for a weekend sale, I can’t easily track that change in my historical data because the API only records the post-tax fragments.

Suggested Solution
It would be ideal if the transaction object included one of the following:

  • grossAmount: The total Robux spent by the customer.
  • feeApplied: The total Robux deducted by the platform.

Having even one of these would eliminate the guesswork and allow us to build much more robust financial tools.

Sincerely,
ConstructedDamage

1 Like