Skip to content

feat(billing): add invoice_item_types to LineItemDetails #295

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dashed wants to merge 2 commits into
base: main
Choose a base branch
from
Open

feat(billing): add invoice_item_types to LineItemDetails #295

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
29dbd82
feat(billing): add invoice_item_types to LineItemDetails
dashed Jun 5, 2026
872267d
chore: Regenerate Rust bindings
getsantry[bot] Jun 5, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Cargo.lock
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

19 changes: 19 additions & 0 deletions proto/sentry_protos/billing/v1/common/v1/line_item_details.proto
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,9 @@ message LineItemDetails {
// Unique identifier for the line item.
string uid = 1;

// InvoiceItemType identifiers for this SKU, keyed by billing context.
InvoiceItemTypes invoice_item_types = 2;

// Customer-facing display name for the line item.
string customer_facing_name = 3;

Expand All @@ -22,3 +25,19 @@ message LineItemDetails {
// Defines how usage data is transformed into this line item.
BillableMetric billable_metric = 6;
}

// InvoiceItemType identifiers for a single SKU, split by billing context.

@volokluev volokluev Jun 8, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is a SKU? Have we defined it somewhere?

// Reserved, on-demand, and activated usage of the same SKU can each settle as a
// distinct InvoiceItemType, so every context carries its own identifier instead
// of collapsing into one. Contexts are optional because some SKUs (e.g. Seer)
// fold their usage irregularly and do not populate every context.
message InvoiceItemTypes {

@volokluev volokluev Jun 8, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's not clear to me why we would need to expose this in the proto as anything but an enum. We already have the billable_metric, the customer_facing_name, why would we also need to add reserved_errors, reserved_trace_metric_bytes etc to the list? Why not just an enum of

enum InvoiceItemType {
    INVOICE_ITEM_TYPE_RESERVED = 1;
    INVOICE_ITEM_TYPE_PAYG = 2;
    INVOICE_ITEM_TYPE_ACTIVATED = 2;
}

I don't see why downstream services which need to generate a string like reserved_errors for their own purposes need that to be exposed in the lineitem proto

// Type for reserved (prepaid) usage of this SKU.
optional string reserved = 1;
Comment thread
dashed marked this conversation as resolved.

// Type for on-demand (pay-as-you-go) usage of this SKU.
optional string ondemand = 2;

@volokluev volokluev Jun 8, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

according to the changelog, ondemand has been replaced with payg, can we keep this consistent?


// Type for activated usage of this SKU.
optional string activated = 3;
Comment on lines +41 to +42

@volokluev volokluev Jun 8, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is "activated usage"? what are the example values for it?

}
20 changes: 20 additions & 0 deletions rust/src/sentry_protos.billing.v1.common.v1.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -224,6 +224,9 @@ pub struct LineItemDetails {
/// Unique identifier for the line item.
#[prost(string, tag = "1")]
pub uid: ::prost::alloc::string::String,
/// InvoiceItemType identifiers for this SKU, keyed by billing context.
#[prost(message, optional, tag = "2")]
pub invoice_item_types: ::core::option::Option<InvoiceItemTypes>,
/// Customer-facing display name for the line item.
#[prost(string, tag = "3")]
pub customer_facing_name: ::prost::alloc::string::String,
Expand All @@ -237,6 +240,23 @@ pub struct LineItemDetails {
#[prost(message, optional, tag = "6")]
pub billable_metric: ::core::option::Option<BillableMetric>,
}
/// InvoiceItemType identifiers for a single SKU, split by billing context.
/// Reserved, on-demand, and activated usage of the same SKU can each settle as a
/// distinct InvoiceItemType, so every context carries its own identifier instead
/// of collapsing into one. Contexts are optional because some SKUs (e.g. Seer)
/// fold their usage irregularly and do not populate every context.
#[derive(Clone, PartialEq, Eq, Hash, ::prost::Message)]
pub struct InvoiceItemTypes {
/// Type for reserved (prepaid) usage of this SKU.
#[prost(string, optional, tag = "1")]
pub reserved: ::core::option::Option<::prost::alloc::string::String>,
/// Type for on-demand (pay-as-you-go) usage of this SKU.
#[prost(string, optional, tag = "2")]
pub ondemand: ::core::option::Option<::prost::alloc::string::String>,
/// Type for activated usage of this SKU.
#[prost(string, optional, tag = "3")]
pub activated: ::core::option::Option<::prost::alloc::string::String>,
}
/// Stripe-specific payment information for an organization.
#[derive(Clone, PartialEq, Eq, Hash, ::prost::Message)]
pub struct StripePaymentData {
Expand Down
Loading