Struct Client 

pub struct Client { /* private fields */ }

Client for Metronome

Version: 1.0.0

Implementations

impl Client

pub fn new(baseurl: &str) -> Self

Create a new client.

baseurl is the base URL provided to the internal reqwest::Client, and should include a scheme and hostname, as well as port and a path stem if applicable.

pub fn new_with_client(baseurl: &str, client: Client) -> Self

Construct a new client with an existing reqwest::Client, allowing more control over its configuration.

baseurl is the base URL provided to the internal reqwest::Client, and should include a scheme and hostname, as well as port and a path stem if applicable.

Examples found in repository

examples/ingest.rs (line 13)

fn build() -> Result<(Client, Vec<IngestV1BodyItem>), Box<dyn std::error::Error>> {
    let mut headers = reqwest::header::HeaderMap::new();
    let mut auth = reqwest::header::HeaderValue::from_str("Bearer x")?;
    auth.set_sensitive(true);
    headers.insert(reqwest::header::AUTHORIZATION, auth);
    let http = reqwest::Client::builder().default_headers(headers).build()?;
    let client = Client::new_with_client("https://api.metronome.com", http);

    let events = vec![IngestV1BodyItem {
        transaction_id: FromStr::from_str("txn-0001")?,
        customer_id: FromStr::from_str("cust_abc123")?,
        event_type: FromStr::from_str("api_request")?,
        timestamp: "2026-06-15T00:00:00Z".to_string(),
        properties: serde_json::json!({ "tokens": 4096 }).as_object().unwrap().clone(),
    }];
    Ok((client, events))
}

impl Client

pub async fn archive_alert_v1<'a>( &'a self, body: &'a ArchiveAlertV1Body, ) -> Result<ResponseValue<ArchiveAlertV1Response>, Error<ArchiveAlertV1Response>>

Archive a threshold notification

Permanently disable a threshold notification and remove it from active monitoring across all customers. Archived threshold notifications stop evaluating immediately and can optionally release their uniqueness key for reuse in future threshold notification configurations.

Use this endpoint to:

• Decommission threshold notifications that are no longer needed
• Clean up test or deprecated threshold notification configurations
• Free up uniqueness keys for reuse with new threshold notifications
• Stop threshold notification evaluations without losing historical configuration data
• Disable outdated monitoring rules during pricing model transitions

Key response fields:

• data: Object containing the archived threshold notification’s ID

Usage guidelines:

• Irreversible for evaluation: Archived threshold notifications cannot be re-enabled; create a new threshold notification to resume monitoring
• Uniqueness key handling: Set release_uniqueness_key : true to reuse the key in future threshold notifications
• Immediate effect: Threshold notification evaluation stops instantly across all customers
• Historical preservation: Archive operation maintains threshold notification history and configuration for compliance and auditing

Sends a POST request to /v1/alerts/archive

Arguments:

• body: The ID of the threshold notification to archive

pub async fn create_alert_v1<'a>( &'a self, body: &'a CreateAlertV1Body, ) -> Result<ResponseValue<CreateAlertV1Response>, Error<()>>

Create a threshold notification

Create a new threshold notification to monitor customer spending, balances, and billing metrics in real-time. Metronome’s notification system provides industry-leading speed with immediate evaluation capabilities, enabling you to proactively manage customer accounts and prevent revenue leakage.

This endpoint creates configurable threshold notifications that continuously monitor various billing thresholds including spend limits, credit balances, commitment utilization, and invoice totals. Threshold notifications can be configured globally for all customers or targeted to specific customer accounts.

Use this endpoint to:

• Proactively monitor customer spending patterns to prevent unexpected overages or credit exhaustion
• Automate notifications when customers approach commitment limits or credit thresholds
• Enable real-time intervention for accounts at risk of churn or payment issues
• Scale billing operations by automating threshold-based workflows and notifications

Key response fields:

A successful response returns a CustomerAlert object containing:

• The threshold notification configuration with its unique ID and current status
• The customer’s evaluation status (ok, in_alarm, or evaluating)
• Threshold notification metadata including type, threshold values, and update timestamps

Usage guidelines:

• Immediate evaluation: Set evaluate_on_create : true (default) for instant evaluation against existing customers
• Uniqueness constraints: Each threshold notification must have a unique uniqueness_key within your organization. Use release_uniqueness_key : true when archiving to reuse keys
• Notification type requirements: Different threshold notification types require specific fields (e.g., billable_metric_id for usage notifications, credit_type_id for credit-based threshold notifications)
• Webhook delivery: Threshold notifications trigger webhook notifications for real-time integration with your systems. Configure webhook endpoints before creating threshold notifications
• Performance at scale: Metronome’s event-driven architecture processes threshold notification evaluations in real-time as usage events stream in, unlike competitors who rely on periodic polling or batch evaluation cycles

Sends a POST request to /v1/alerts/create

Arguments:

• body: The details of the threshold notification to create

pub async fn create_billable_metric_v1_v1<'a>( &'a self, body: &'a CreateBillableMetricV1v1Body, ) -> Result<ResponseValue<CreateBillableMetricV1v1Response>, Error<()>>

Create a billable metric

Create billable metrics programmatically with this endpoint—an essential step in configuring your pricing and packaging in Metronome.

A billable metric is a customizable query that filters and aggregates events from your event stream. These metrics are continuously tracked as usage data enters Metronome through the ingestion pipeline. The ingestion process transforms raw usage data into actionable pricing metrics, enabling accurate metering and billing for your products.

Use this endpoint to:

• Create individual or multiple billable metrics as part of a setup workflow.
• Automate the entire pricing configuration process, from metric creation to customer contract setup.
• Define metrics using either standard filtering/aggregation or a custom SQL query.

Key response fields:

• The ID of the billable metric that was created
• The created billable metric will be available to be used in Products, usage endpoints, and alerts.

Usage guidelines:

• Metrics defined using standard filtering and aggregation are Streaming billable metrics, which have been optimized for ultra low latency and high throughput workflows.
• Use SQL billable metrics if you require more flexible aggregation options.

Sends a POST request to /v1/billable-metrics/create

Arguments:

• body: The details of the billable metric to create.

pub async fn archive_billable_metric_v1<'a>( &'a self, body: &'a ArchiveBillableMetricV1Body, ) -> Result<ResponseValue<ArchiveBillableMetricV1Response>, Error<ArchiveBillableMetricV1Response>>

Archive a billable metric

Use this endpoint to retire billable metrics that are no longer used. After a billable metric is archived, that billable metric can no longer be used in any new Products to define how that product should be metered. If you archive a billable metric that is already associated with a Product, the Product will continue to function as usual, metering based on the definition of the archived billable metric.

Archived billable metrics will be returned on the getBillableMetric and listBillableMetrics endpoints with a populated archived_at field.

Sends a POST request to /v1/billable-metrics/archive

Arguments:

• body: The ID of the billable metric to archive

pub async fn get_customer_alert_v1<'a>( &'a self, body: &'a GetCustomerAlertV1Body, ) -> Result<ResponseValue<GetCustomerAlertV1Response>, Error<GetCustomerAlertV1Response>>

Get a threshold notification

Retrieve the real-time evaluation status for a specific threshold notification-customer pair. This endpoint provides instant visibility into whether a customer has triggered a threshold notification condition, enabling you to monitor account health and take proactive action based on current threshold notification states.

Use this endpoint to:

• Check if a specific customer is currently violating an threshold notification (in_alarm status)
• Verify threshold notification configuration details and threshold values for a customer
• Monitor the evaluation state of newly created or recently modified threshold notification
• Build dashboards or automated workflows that respond to specific threshold notification conditions
• Validate threshold notification behavior before deploying to production customers
• Integrate threshold notification status checks into customer support tools or admin interfaces

Key response fields:

A CustomerAlert object containing:

• customer_status: The current evaluation state

• ok - Customer is within acceptable thresholds

• in_alarm - Customer has breached the threshold for the notification

• evaluating - Notification is currently being evaluated (typically during initial setup)

• null - Notification has been archived

• triggered_by: Additional context about what caused the notification to trigger (when applicable)

• alert: Complete threshold notification configuration including:

• Notification ID, name, and type

• Current threshold values and credit type information

• Notification status (enabled, disabled, or archived)

• Last update timestamp

• Any applied filters (credit grant types, custom fields, group values)

Usage guidelines:

• Customer status: Returns the current evaluation state, not historical data. For threshold notification history, use webhook notifications or event logs
• Required parameters: Both customer_id and alert_id must be valid UUIDs that exist in your organization
• Archived notifications: Returns null for customer_status if the notification has been archived, but still includes the notification configuration details
• Performance considerations: This endpoint queries live evaluation state, making it ideal for real-time monitoring but not for bulk status checks
• Integration patterns: Best used for on-demand status checks in response to user actions or as part of targeted monitoring workflows
• Error handling: Returns 404 if either the customer or alert_id doesn’t exist or isn’t accessible to your organization

Sends a POST request to /v1/customer-alerts/get

Arguments:

• body: The customer ID and notification ID of the threshold notification to get

pub async fn list_customer_alerts_v1<'a>( &'a self, next_page: Option<&'a str>, body: &'a ListCustomerAlertsV1Body, ) -> Result<ResponseValue<ListCustomerAlertsV1Response>, Error<()>>

Get all threshold notifications

Retrieve all threshold notification configurations and their current statuses for a specific customer in a single API call. This endpoint provides a comprehensive view of all threshold notification monitoring a customer account.

Use this endpoint to:

• Display all active threshold notifications for a customer in dashboards or admin panels
• Quickly identify which threshold notifications a customer is currently triggering
• Audit threshold notification coverage for specific accounts
• Filter threshold notifications by status (enabled, disabled, or archived)

Key response fields:

• data: Array of CustomerAlert objects, each containing:
• Current evaluation status (ok, in_alarm, evaluating, or null)
• Complete threshold notification configuration and threshold details
• Threshold notification metadata including type, name, and last update time
• next_page: Pagination cursor for retrieving additional results

Usage guidelines:

• Default behavior: Returns only enabled threshold notifications unless alert_statuses filter is specified
• Pagination: Use the next_page cursor to retrieve all results for customers with many notifications
• Performance: Efficiently retrieves multiple threshold notification statuses in a single request instead of making individual calls
• Filtering: Pass the alert_statuses array to include disabled or archived threshold notifications in results

Sends a POST request to /v1/customer-alerts/list

Arguments:

• next_page: Cursor that indicates where the next page of results should start.
• body: The threshold notifications query to run

pub async fn reset_customer_alerts_v1<'a>( &'a self, body: &'a ResetCustomerAlertsV1Body, ) -> Result<ResponseValue<()>, Error<()>>

Reset a threshold notification

Force an immediate re-evaluation of a specific threshold notification for a customer, clearing any previous state and triggering a fresh assessment against current thresholds. This endpoint ensures threshold notification accuracy after configuration changes or data corrections.

Use this endpoint to:

• Clear false positive threshold notifications after fixing data issues
• Re-evaluate threshold notifications after adjusting customer balances or credits
• Test threshold notification behavior during development and debugging
• Resolve stuck threshold notification that may be in an incorrect state
• Trigger immediate evaluation after threshold modifications

Key response fields:

• 200 Success: Confirmation that the threshold notification has been reset and re-evaluation initiated
• No response body is returned - the operation completes asynchronously

Usage guidelines:

• Immediate effect: Triggers re-evaluation instantly, which may result in new webhook notifications if thresholds are breached
• State clearing: Removes any cached evaluation state, ensuring a fresh assessment
• Use sparingly: Intended for exceptional cases, not routine operations
• Asynchronous processing: The reset completes immediately, but re-evaluation happens in the background

Sends a POST request to /v1/customer-alerts/reset

Arguments:

• body: The customer ID and notification ID of the threshold notification to reset

pub async fn list_credit_types_v1<'a>( &'a self, limit: Option<NonZeroU64>, next_page: Option<&'a str>, ) -> Result<ResponseValue<ListCreditTypesV1Response>, Error<()>>

List pricing units

List all pricing units. All fiat currency types (for example, USD or GBP) will be included, as well as any custom pricing units that were configured. Custom pricing units can be used to charge for usage in a non-fiat pricing unit, for example AI credits.

Note: The USD (cents) pricing unit is 2714e483-4ff1-48e4-9e25-ac732e8f24f2.

Sends a GET request to /v1/credit-types/list

Arguments:

• limit: Max number of results that should be returned
• next_page: Cursor that indicates where the next page of results should start.

pub async fn ingest_v1<'a>( &'a self, body: &'a Vec<IngestV1BodyItem>, ) -> Result<ResponseValue<()>, Error<()>>

Ingest events

The ingest endpoint is the primary method for sending usage events to Metronome, serving as the foundation for all billing calculations in your usage-based pricing model. This high-throughput endpoint is designed for real-time streaming ingestion, supports backdating 34 days, and is built to handle mission-critical usage data with enterprise-grade reliability. Metronome supports 100,000 events per second without requiring pre-aggregation or rollups and can scale up from there. See the Send usage events guide to learn more about usage events.

Use this endpoint to:

Create a customer usage pipeline into Metronome that drives billable metrics, credit drawdown, and invoicing. Track customer behavior, resource consumption, and feature usage

What happens when you send events:

• Events are validated and processed in real-time
• Events are matched to customers using customer IDs or customer ingest aliases
• Events are matched to billable metrics and are immediately available for usage and spend calculations

Usage guidelines:

• Historical events can be backdated up to 34 days and will immediately impact live customer spend
• Duplicate events are automatically detected and ignored (34-day deduplication window)

Event structure:

Usage events are simple JSON objects designed for flexibility and ease of integration:

{
 "transaction_id": "2021-01-01T00:00:00Z_cluster42",
 "customer_id": "team@example.com",
 "event_type": "api_request",
 "timestamp": "2021-01-01T00:00:00Z",
 "properties": {
   "endpoint": "/v1/users",
   "method": "POST",
   "response_time_ms": 45,
   "region": "us-west-2"
 }
}

Learn more about usage event structure definitions.

Transaction ID

The transaction_id serves as your idempotency key, ensuring events are processed exactly once. Metronome maintains a 34-day deduplication window - significantly longer than typical 12-hour windows - enabling robust backfill scenarios without duplicate billing.

• Best Practices:
  • Use UUIDs for one-time events: uuid4()
  • For heartbeat events, use deterministic IDs
  • Include enough context to avoid collisions across different event sources

Customer ID

Identifies which customer should be billed for this usage. Supports two identification methods:

• Metronome Customer ID: The UUID returned when creating a customer
• Ingest Alias: Your system’s identifier (email, account number, etc.)

Ingest aliases enable seamless integration without requiring ID mapping, and customers can have multiple aliases for flexibility.

Event Type:

Categorizes the event type for billable metric matching. Choose descriptive names that aligns with the product surface area.

Properties:

Flexible metadata also used to match billable metrics or to be used to serve as group keys to create multiple pricing dimensions or breakdown costs by novel properties for end customers or internal finance teams measuring underlying COGs.

Sends a POST request to /v1/ingest

pub async fn get_paged_usage_v1<'a>( &'a self, limit: Option<NonZeroU64>, next_page: Option<&'a str>, body: &'a GetPagedUsageV1Body, ) -> Result<ResponseValue<GetPagedUsageV1Response>, Error<()>>

Get usage data with paginated groupings

Retrieve granular usage data for a specific customer and billable metric, with the ability to break down usage by custom grouping dimensions. This endpoint enables deep usage analytics by segmenting data across attributes like region, user, model type, or any custom dimension defined in your billable metrics.

Use this endpoint to:

• Analyze usage patterns broken down by specific attributes (region, user, department, etc.)
• Build detailed usage dashboards with dimensional filtering
• Identify high-usage segments for optimization opportunities

Request parameters

Use group_key and group_filters to group by one or more dimensions. This is required for compound group keys and recommended for all new integrations:

{
 "group_key": ["region", "team"],
 "group_filters": {
   "region": ["US-East", "US-West"]
 }
}

Important: For compound group keys, you must pass the complete set of keys that make up the compound key. Partial key combinations are not supported. For example, if your billable metric has a compound group key [region, team, environment], you must pass all three keys in group_key—you cannot pass just [region] or [region, team].

Key response fields:

An array of PagedUsageAggregate objects containing:

• starting_on and ending_before: Time window boundaries
• group: Object mapping group keys to their values
• For simple groups, this will be a map with a single key-value pair (e.g., {"region": "US-East"})
• For compound groups, this will be a map with multiple key-value pairs (e.g., {"region": "US-East", "team": "engineering"})
• value: Aggregated usage for this group and time window
• next_page: Pagination cursor for large datasets

Usage guidelines:

• Required parameters: Must specify customer_id, billable_metric_id, and window_size
• Time windows: Set window_size to hour, day, or none for different granularities
• Group filtering: Use group_key and group_filters to specify groups and group filters
• Limits: When using compound group keys (2+ keys in group_key), the default and max limit is 100
• Pagination: Use limit and next_page for large result sets
• Null handling: Group values may be null for events missing the group key property

Sends a POST request to /v1/usage/groups

Arguments:

• limit: Max number of results that should be returned
• next_page: Cursor that indicates where the next page of results should start.
• body: The usage query to run

pub async fn get_usage_batch_v1<'a>( &'a self, next_page: Option<&'a str>, body: &'a GetUsageBatchV1Body, ) -> Result<ResponseValue<GetUsageBatchV1Response>, Error<()>>

Get batched usage data

Retrieve aggregated usage data across multiple customers and billable metrics in a single query. This batch endpoint enables you to fetch usage patterns at scale, broken down by time windows, making it ideal for building analytics dashboards, generating reports, and monitoring platform-wide usage trends.

Use this endpoint to:

• Generate platform-wide usage reports for internal teams
• Monitor aggregate usage trends across your entire customer base
• Create comparative usage analyses between customers or time periods
• Support capacity planning with historical usage patterns

Key response fields:

An array of UsageBatchAggregate objects containing:

• customer_id: The customer this usage belongs to
• billable_metric_id and billable_metric_name: What was measured
• start_timestamp and end_timestamp: Time window for this data point
• value: Aggregated usage amount for the period
• groups (optional): Usage broken down by group keys with values
• next_page: Pagination cursor for large result sets

Usage guidelines:

• Time windows: Set window_size to hour, day, or none (entire period)
• Required parameters: Must specify starting_on, ending_before, and window_size
• Filtering options:
• customer_ids: Limit to specific customers (omit for all customers)
• billable_metrics: Limit to specific metrics (omit for all metrics)
• Pagination: Use next_page cursor to retrieve large datasets
• Null values: Group values may be null when no usage matches that group

Sends a POST request to /v1/usage

Arguments:

• next_page: Cursor that indicates where the next page of results should start.
• body: The usage query to run

pub async fn search_events_v1<'a>( &'a self, body: &'a SearchEventsV1Body, ) -> Result<ResponseValue<Vec<SearchEventsV1ResponseItem>>, Error<()>>

Search events

This endpoint retrieves events by transaction ID for events that occurred within the last 34 days. It is specifically designed for sampling-based testing workflows to detect revenue leakage. The Event Search API provides a critical observability tool that validates the integrity of your usage pipeline by allowing you to sample raw events and verify their matching against active billable metrics.

Why event observability matters for revenue leakage: Silent revenue loss occurs when events are dropped, delayed, or fail to match billable metrics due to:

• Upstream system failures
• Event format changes
• Misconfigured billable metrics

Use this endpoint to:

• Sample raw events and validate they match the expected billable metrics
• Build custom leakage detection alerts to prevent silent revenue loss
• Verify event processing accuracy during system changes or metric updates
• Debug event matching issues in real-time

Key response fields:

• Complete event details including transaction ID, customer ID, and properties
• Matched Metronome customer (if any)
• Matched billable metric information (if any)
• Processing status and duplicate detection flags

Usage guidelines:

⚠️ Important: This endpoint is heavily rate limited and designed for sampling workflows only. Do not use this endpoint to check every event in your system. Instead, implement a sampling strategy to randomly validate a subset of events for observability purposes.

Sends a POST request to /v1/events/search

Arguments:

• body: Search events request

pub async fn get_billable_metric_v1<'a>( &'a self, billable_metric_id: &'a Uuid, ) -> Result<ResponseValue<GetBillableMetricV1Response>, Error<GetBillableMetricV1Response>>

Get a billable metric

Retrieves the complete configuration for a specific billable metric by its ID. Use this to review billable metric setup before associating it with products. Returns the metric’s name, event_type_filter, property_filters, aggregation_type, aggregation_key, group_keys, custom fields, and SQL query (if it’s a SQL billable metric).

Important:

• Archived billable metrics will include an archived_at timestamp; they no longer process new usage events but remain accessible for historical reference.

Sends a GET request to /v1/billable-metrics/{billable_metric_id}

pub async fn update_billable_metric_v1<'a>( &'a self, billable_metric_id: &'a Uuid, body: &'a UpdateBillableMetricV1Body, ) -> Result<ResponseValue<UpdateBillableMetricV1Response>, Error<()>>

Update a billable metric

Updates only the display name of an existing billable metric. Use this to correct mistakes or apply standardized naming conventions across all billable metrics. Returns the billable metric ID to confirm the update.

Important: Only the name can be modified via this endpoint; configurations cannot be changed after creation.

Example workflow:

If you need to make changes to a streaming billable metric, for example, Metronome supports easily rolling out these changes using a simple workflow:

1. Duplicate the billable metric
2. Make required changes
3. Save the metric
4. Navigate to the product you have associated with the incorrect metric
5. Schedule the product to reference the newly created metric on the appropriate date

Sends a PUT request to /v1/billable-metrics/{billable_metric_id}

Arguments:

• billable_metric_id
• body: The billable metric to update

pub async fn list_all_billable_metrics_v1<'a>( &'a self, include_archived: Option<bool>, limit: Option<NonZeroU64>, next_page: Option<&'a str>, ) -> Result<ResponseValue<ListAllBillableMetricsV1Response>, Error<()>>

List all billable metrics

Retrieves all billable metrics with their complete configurations. Use this for programmatic discovery and management of billable metrics, such as associating metrics to products and auditing for orphaned or archived metrics. Important: Archived metrics are excluded by default; use include_archived=true parameter to include them.

Sends a GET request to /v1/billable-metrics

Arguments:

• include_archived: If true, the list of returned metrics will include archived metrics
• limit: Max number of results that should be returned
• next_page: Cursor that indicates where the next page of results should start.

pub async fn set_customer_billable_status_v1<'a>( &'a self, body: &'a SetCustomerBillableStatusV1Body, ) -> Result<ResponseValue<SetCustomerBillableStatusV1Response>, Error<SetCustomerBillableStatusV1Response>>

Set customer billable status

Set a customer’s billable status. This endpoint’s availability is dependent on your client’s configuration. Metronome 1.0 plan invoices are not supported.

Sends a POST request to /v1/customers/setBillableStatus

pub async fn archive_customer_v1<'a>( &'a self, body: &'a ArchiveCustomerV1Body, ) -> Result<ResponseValue<ArchiveCustomerV1Response>, Error<ArchiveCustomerV1Response>>

Archive a customer

Use this endpoint to archive a customer while preserving auditability. Archiving a customer will automatically archive all contracts as of the current date and void all corresponding invoices. Use this endpoint if a customer is onboarded by mistake.

Usage guidelines:

• Once a customer is archived, it cannot be unarchived.
• Archived customers can still be viewed through the API or the UI for audit purposes.
• Ingest aliases remain idempotent for archived customers. In order to reuse an ingest alias, first remove the ingest alias from the customer prior to archiving.
• Any notifications associated with the customer will no longer be triggered.

Sends a POST request to /v1/customers/archive

Arguments:

• body: The ID of the customer to archive

pub async fn get_customer_v1<'a>( &'a self, customer_id: &'a Uuid, ) -> Result<ResponseValue<GetCustomerV1Response>, Error<()>>

Get a customer

Get detailed information for a specific customer by their Metronome ID. Returns customer profile data including name, creation date, ingest aliases, configuration settings, and custom fields. Use this endpoint to fetch complete customer details for billing operations or account management.

Note: If searching for a customer billing configuration, use the /getCustomerBillingConfigurations endpoint.

Sends a GET request to /v1/customers/{customer_id}

pub async fn list_billable_metrics_v1<'a>( &'a self, customer_id: &'a Uuid, include_archived: Option<bool>, limit: Option<NonZeroU64>, next_page: Option<&'a str>, on_current_plan: Option<bool>, ) -> Result<ResponseValue<ListBillableMetricsV1Response>, Error<()>>

Get billable metrics for a customer

Get all billable metrics available for a specific customer. Supports pagination and filtering by current plan status or archived metrics. Use this endpoint to see which metrics are being tracked for billing calculations for a given customer.

Sends a GET request to /v1/customers/{customer_id}/billable-metrics

Arguments:

• customer_id
• include_archived: If true, the list of returned metrics will include archived metrics
• limit: Max number of results that should be returned
• next_page: Cursor that indicates where the next page of results should start.
• on_current_plan: If true, the list of metrics will be filtered to just ones that are on the customer’s current plan

pub async fn list_customers_v1<'a>( &'a self, customer_ids: Option<&'a Vec<String>>, ingest_alias: Option<&'a str>, limit: Option<NonZeroU64>, next_page: Option<&'a str>, only_archived: Option<bool>, salesforce_account_ids: Option<&'a Vec<String>>, ) -> Result<ResponseValue<ListCustomersV1Response>, Error<()>>

List customers

Gets a paginated list of all customers in your Metronome account. Use this endpoint to browse your customer base, implement customer search functionality, or sync customer data with external systems. Returns customer details including IDs, names, and configuration settings. Supports filtering and pagination parameters for efficient data retrieval.

Sends a GET request to /v1/customers

Arguments:

• customer_ids: Filter the customer list by customer_id. Up to 100 ids can be provided.
• ingest_alias: Filter the customer list by ingest_alias
• limit: Max number of results that should be returned
• next_page: Cursor that indicates where the next page of results should start.
• only_archived: Filter the customer list to only return archived customers. By default, only active customers are returned.
• salesforce_account_ids: Filter the customer list by salesforce_account_id. Up to 100 ids can be provided.

pub async fn create_customer_v1<'a>( &'a self, body: &'a CreateCustomerV1Body, ) -> Result<ResponseValue<CreateCustomerV1Response>, Error<CreateCustomerV1Response>>

Create a customer

Create a new customer in Metronome and optionally the billing configuration (recommended) which dictates where invoices for the customer will be sent or where payment will be collected.

Use this endpoint to:

Execute your customer provisioning workflows for either PLG motions, where customers originate in your platform, or SLG motions, where customers originate in your sales system.

Key response fields:

This end-point returns the customer_id created by the request. This id can be used to fetch relevant billing configurations and create contracts.

Example workflow:

• Generally, Metronome recommends first creating the customer in the downstream payment / ERP system when payment method is collected and then creating the customer in Metronome using the response (i.e. customer_id) from the downstream system. If you do not create a billing configuration on customer creation, you can add it later.
• Once a customer is created, you can then create a contract for the customer. In the contract creation process, you will need to add the customer billing configuration to the contract to ensure Metronome invoices the customer correctly. This is because a customer can have multiple configurations.
• As part of the customer creation process, set the ingest alias for the customer which will ensure usage is accurately mapped to the customer. Ingest aliases can be added or changed after the creation process as well.

Usage guidelines:

For details on different billing configurations for different systems, review the /setCustomerBillingConfiguration end-point.

Sends a POST request to /v1/customers

Arguments:

• body: The customer to create

pub async fn set_ingest_aliases_v1<'a>( &'a self, customer_id: &'a Uuid, body: &'a SetIngestAliasesV1Body, ) -> Result<ResponseValue<()>, Error<()>>

Create or update customer ingest aliases

Sets the ingest aliases for a customer. Use this endpoint to associate a Metronome customer with an internal ID for easier tracking between systems. Ingest aliases can be used in the customer_id field when sending usage events to Metronome.

Usage guidelines:

• This call is idempotent and fully replaces the set of ingest aliases for the given customer.
• Switching an ingest alias from one customer to another will associate all corresponding usage to the new customer.
• Use multiple ingest aliases to model child organizations within a single Metronome customer.

Sends a POST request to /v1/customers/{customer_id}/setIngestAliases

Arguments:

• customer_id
• body: The aliases to add

pub async fn set_customer_name_v1<'a>( &'a self, customer_id: &'a Uuid, body: &'a SetCustomerNameV1Body, ) -> Result<ResponseValue<SetCustomerNameV1Response>, Error<()>>

Update a customer name

Updates the display name for a customer record. Use this to correct customer names, update business names after rebranding, or maintain accurate customer information for invoicing and reporting. Returns the updated customer object with the new name applied immediately across all billing documents and interfaces.

Sends a POST request to /v1/customers/{customer_id}/setName

Arguments:

• customer_id
• body: The customer name

pub async fn update_customer_config_v1<'a>( &'a self, customer_id: &'a Uuid, body: &'a UpdateCustomerConfigV1Body, ) -> Result<ResponseValue<()>, Error<UpdateCustomerConfigV1Response>>

Update a customer configuration

Update configuration settings for a specific customer, such as external system integrations (e.g., Salesforce account ID) and other customer-specific billing parameters. Use this endpoint to modify customer configurations without affecting core customer data like name or ingest aliases.

Sends a POST request to /v1/customers/{customer_id}/updateConfig

Arguments:

• customer_id
• body: The configuration for a specific customer

pub async fn charge_seats_v1<'a>( &'a self, customer_id: &'a Uuid, body: &'a ChargeSeatsV1Body, ) -> Result<ResponseValue<ChargeSeatsV1Response>, Error<ChargeSeatsV1Response>>

Invoice seats

Creates an prorated invoice for a seat addition. As an alternative to this endpoint, you can elect to use automatic seat invoicing feature. Metronome will check for new seat usage every hour and automatically invoice for any new seats. For newly created active customer plans, there will be up to 4 hour delay before the first automatic seat invoice is generated.

Sends a POST request to /v1/customers/{customer_id}/invoices/invoice_seats

Arguments:

• customer_id
• body: Invoice seats parameters. List of seat charges and additional seats to charge for.

pub async fn list_invoices_v1<'a>( &'a self, customer_id: &'a Uuid, contract_id: Option<&'a Uuid>, credit_type_id: Option<&'a str>, ending_before: Option<&'a DateTime<Utc>>, limit: Option<NonZeroU64>, next_page: Option<&'a str>, skip_zero_qty_line_items: Option<bool>, sort: Option<ListInvoicesV1Sort>, starting_on: Option<&'a DateTime<Utc>>, status: Option<&'a str>, type_: Option<ListInvoicesV1Type>, webhook_notification_id: Option<&'a str>, ) -> Result<ResponseValue<ListInvoicesV1Response>, Error<ListInvoicesV1Response>>

List invoices

Retrieves a paginated list of invoices for a specific customer, with flexible filtering options to narrow results by status, date range, credit type, and more. This endpoint provides a comprehensive view of a customer’s billing history and current charges, supporting both real-time billing dashboards and historical reporting needs.

Use this endpoint to:

• Display historical invoice details in customer-facing dashboards or billing portals.
• Retrieve current month draft invoices to show customers their month-to-date spend.
• Access finalized invoices for historical billing records and payment reconciliation.
• Validate customer pricing and credit applications for customer support queries.
• Generate financial reports by filtering invoices within specific date ranges

Key response fields:

Array of invoice objects containing:

• Invoice ID and status (DRAFT, FINALIZED, VOID)
• Invoice type (USAGE, SCHEDULED)
• Billing period start and end dates
• Issue date and due date
• Total amount, subtotal, and amount due
• Applied credits summary
• Contract ID reference
• External billing provider status (if integrated with Stripe, etc.)
• Pagination metadata next_page cursor

Usage guidelines:

• The endpoint returns invoice summaries; use the Get Invoice endpoint for detailed line items
• Draft invoices are continuously updated as new usage is reported and will show real-time spend
• Results are ordered by creation date descending by default (newest first)
• When filtering by date range, the filter applies to the billing period, not the issue date
• For customers with many invoices, implement pagination to ensure all results are retrieved External billing provider statuses (like Stripe payment status) are included when applicable
• Voided invoices are included in results by default unless filtered out by status

Sends a GET request to /v1/customers/{customer_id}/invoices

Arguments:

• customer_id
• contract_id: Only return invoices for the specified contract
• credit_type_id: Only return invoices for the specified credit type
• ending_before: RFC 3339 timestamp (exclusive). Invoices will only be returned for billing periods that end before this time.
• limit: Max number of results that should be returned
• next_page: Cursor that indicates where the next page of results should start.
• skip_zero_qty_line_items: If set, all zero quantity line items will be filtered out of the response
• sort: Invoice sort order by issued_at, e.g. date_asc or date_desc. Defaults to date_asc.
• starting_on: RFC 3339 timestamp (inclusive). Invoices will only be returned for billing periods that start at or after this time.
• status: Invoice status, e.g. DRAFT, FINALIZED, or VOID
• type_: Filter invoices by type. Defaults to returning all invoice types.
• webhook_notification_id: Indicates that this API request was triggered by a webhook notification with the provided ID.

pub async fn list_breakdown_invoices_v1<'a>( &'a self, customer_id: &'a Uuid, credit_type_id: Option<&'a str>, ending_before: &'a DateTime<Utc>, limit: Option<NonZeroU64>, next_page: Option<&'a str>, skip_zero_qty_line_items: Option<bool>, sort: Option<ListBreakdownInvoicesV1Sort>, starting_on: &'a DateTime<Utc>, status: Option<&'a str>, window_size: Option<&'a str>, ) -> Result<ResponseValue<ListBreakdownInvoicesV1Response>, Error<ListBreakdownInvoicesV1Response>>

List invoice breakdowns

Retrieve granular time-series breakdowns of invoice data at hourly or daily intervals. This endpoint transforms standard invoices into detailed timelines, enabling you to track usage patterns, identify consumption spikes, and provide customers with transparency into their billing details throughout the billing period.

Use this endpoint to:

• Build usage analytics dashboards showing daily or hourly consumption trends
• Identify peak usage periods for capacity planning and cost optimization
• Generate detailed billing reports for finance teams and customer success
• Troubleshoot billing disputes by examining usage patterns at specific times
• Power real-time cost monitoring and alerting systems

Key response fields:

An array of BreakdownInvoice objects, each containing:

• All standard invoice fields (ID, customer, commit, line items, totals, status)
• Line items with quantities and costs for that specific period
• breakdown_start_timestamp: Start of the specific time window
• breakdown_end_timestamp: End of the specific time window
• next_page: Pagination cursor for large result sets

Usage guidelines:

• Time granularity: Set window_size to hour or day based on your analysis needs
• Response limits: Daily breakdowns return up to 35 days; hourly breakdowns return up to 24 hours per request
• Date filtering: Use starting_on and ending_before to focus on specific periods
• Performance: For large date ranges, use pagination to retrieve all data efficiently
• Backdated usage: If usage events arrive after invoice finalization, breakdowns will reflect the updated usage
• Zero quantity filtering: Use skip_zero_qty_line_items=true to exclude periods with no usage

Sends a GET request to /v1/customers/{customer_id}/invoices/breakdowns

Arguments:

• customer_id
• credit_type_id: Only return invoices for the specified credit type
• ending_before: RFC 3339 timestamp. Breakdowns will only be returned for time windows that end on or before this time.
• limit: Max number of results that should be returned. For daily breakdowns, the response can return up to 35 days worth of breakdowns. For hourly breakdowns, the response can return up to 24 hours. If there are more results, a cursor to the next page is returned.
• next_page: Cursor that indicates where the next page of results should start.
• skip_zero_qty_line_items: If set, all zero quantity line items will be filtered out of the response
• sort: Invoice sort order by issued_at, e.g. date_asc or date_desc. Defaults to date_asc.
• starting_on: RFC 3339 timestamp. Breakdowns will only be returned for time windows that start on or after this time.
• status: Invoice status, e.g. DRAFT or FINALIZED
• window_size: The granularity of the breakdowns to return. Defaults to day.

pub async fn get_invoice_pdf_v1<'a>( &'a self, customer_id: &'a Uuid, invoice_id: &'a Uuid, ) -> Result<ResponseValue<ByteStream>, Error<GetInvoicePdfV1Response>>

Get an invoice PDF

Retrieve a PDF version of a specific invoice by its unique identifier. This endpoint generates a professionally formatted invoice document suitable for sharing with customers, accounting teams, or for record-keeping purposes.

Use this endpoint to:

• Provide customers with downloadable or emailable copies of their invoices
• Support accounting and finance teams with official billing documents
• Maintain accurate records of billing transactions for audits and compliance

Key response details:

• The response is a binary PDF file representing the full invoice
• The PDF includes all standard invoice information such as line items, totals, billing period, and customer details
• The document is formatted for clarity and professionalism, suitable for official use

Usage guidelines:

• Ensure the invoice_id corresponds to an existing invoice for the specified customer_id
• The PDF is generated on-demand; frequent requests for the same invoice may impact performance
• Use appropriate headers to handle the binary response in your application (e.g., setting Content-Type: application/pdf)

Sends a GET request to /v1/customers/{customer_id}/invoices/{invoice_id}/pdf

pub async fn get_invoice_v1<'a>( &'a self, customer_id: &'a Uuid, invoice_id: &'a Uuid, skip_zero_qty_line_items: Option<bool>, ) -> Result<ResponseValue<GetInvoiceV1Response>, Error<GetInvoiceV1Response>>

Get an invoice

Retrieve detailed information for a specific invoice by its unique identifier. This endpoint returns comprehensive invoice data including line items, applied credits, totals, and billing period details for both finalized and draft invoices.

Use this endpoint to:

• Display historical invoice details in customer-facing dashboards or billing portals.
• Retrieve current month draft invoices to show customers their month-to-date spend.
• Access finalized invoices for historical billing records and payment reconciliation.
• Validate customer pricing and credit applications for customer support queries.

Key response fields:

Invoice status (DRAFT, FINALIZED, VOID) Billing period start and end dates Total amount and amount due after credits Detailed line items broken down by:

• Customer and contract information
• Invoice line item type
• Product/service name and ID
• Quantity consumed
• Unit and total price
• Time period for usage-based charges
• Applied credits or prepaid commitments

Usage guidelines:

• Draft invoices update in real-time as usage is reported and may change before finalization
• The response includes both usage-based line items (e.g., API calls, data processed) and scheduled charges (e.g., monthly subscriptions, commitment fees)
• Credit and commitment applications are shown as separate line items with negative amounts
• For voided invoices, the response will indicate VOID status but retain all original line item details

Sends a GET request to /v1/customers/{customer_id}/invoices/{invoice_id}

Arguments:

• customer_id
• invoice_id
• skip_zero_qty_line_items: If set, all zero quantity line items will be filtered out of the response

pub async fn list_spend_breakdown_invoices_v1<'a>( &'a self, customer_id: &'a Uuid, include_list_prices: Option<bool>, body: &'a ListSpendBreakdownInvoicesV1Body, ) -> Result<ResponseValue<ListSpendBreakdownInvoicesV1Response>, Error<ListSpendBreakdownInvoicesV1Response>>

List spend invoice breakdowns

Granularly analyze customer spend patterns by dynamically slicing and dicing costs across any dimension. This endpoint empowers you to break down spending by granular properties like user, organization, model, region, or any custom event property—even if these aren’t the default groupings on your invoices. Unlike standard invoice breakdowns, this endpoint focuses purely on spend analysis, making helpful for building powerful cost analytics dashboards that show spend before credit/commit application.

Use this endpoint to:

• Identify cost drivers: Pinpoint which users, teams, or resources are driving the most spend
• Build usage analytics dashboards: Let customers explore their costs by any event property (user_id, org_id, model_id, region, etc.)
• Enable showback/chargeback: Allocate costs to specific departments, projects, or cost centers
• Detect anomalies: Find unexpected spending patterns by analyzing costs across different dimensions
• Optimize resource usage: Help customers identify underutilized or over-provisioned resources
• Support multi-tenancy: Show spending breakdowns for specific organizations within a single account
• Create custom reports: Generate executive dashboards with spending by any business-relevant dimension

Key response fields:

Spend-focused invoice data with:

• Pure spend information: No commits or credits—just raw spending data for cleaner analysis
• Dynamic grouping: Line items grouped by your specified group_keys (overriding default presentation groups)
• Filtered results: Only line items matching your group_filters criteria
• Flexible time windows: Daily, hourly, or full-period (none) breakdowns
• Complete line item details: Including quantities, unit prices, and custom presentation group values

Usage guidelines:

• Group key setup: All keys used in group_keys, group_filters, and pricing groups must exist in the same compound group key on the billable metric
• Supported window sizes: hour, day, or none (for full period analysis)
• Filtering power: Use group_filters to focus on specific values (e.g., only show data for specific user_ids)
• Override flexibility: Change how costs are grouped without affecting actual invoicing

Limitations:

• Cannot override group keys when using:
• MAX aggregation billable metrics
• Tiered pricing
• Quantity rounding
• Commit-specific overrides
• Overrides on presentation group values

Sends a POST request to /v1/customers/{customer_id}/invoices/spend-breakdowns

Arguments:

• customer_id
• include_list_prices: If set, list prices will be returned for each contract usage and subscription line item.
• body

pub async fn void_invoice_v1<'a>( &'a self, body: &'a VoidInvoiceV1Body, ) -> Result<ResponseValue<VoidInvoiceV1Response>, Error<()>>

Void an invoice

Permanently cancels an invoice by setting its status to voided, preventing collection and removing it from customer billing. Use this to correct billing errors, cancel incorrect charges, or handle disputed invoices that should not be collected. Returns the voided invoice ID with the status change applied immediately to stop any payment processing.

Sends a POST request to /v1/invoices/void

Arguments:

• body: The invoice id to void

pub async fn regenerate_invoice_v1<'a>( &'a self, body: &'a RegenerateInvoiceV1Body, ) -> Result<ResponseValue<RegenerateInvoiceV1Response>, Error<()>>

Regenerate an invoice

This endpoint regenerates a voided invoice and recalculates the invoice based on up-to-date rates, available balances, and other fees regardless of the billing period.

Use this endpoint to:

Recalculate an invoice with updated rate terms, available balance, and fees to correct billing disputes or discrepancies

Key response fields:

The regenerated invoice id, which is distinct from the previously voided invoice.

Usage guidelines:

If an invoice is attached to a contract with a billing provider on it, the regenerated invoice will be distributed based on the configuration.

Sends a POST request to /v1/invoices/regenerate

Arguments:

• body: The invoice id to regenerate

pub async fn preview_customer_events_v1<'a>( &'a self, customer_id: &'a Uuid, body: &'a PreviewCustomerEventsV1Body, ) -> Result<ResponseValue<PreviewCustomerEventsV1Response>, Error<PreviewCustomerEventsV1Response>>

Preview events

Preview how a set of events will affect a customer’s invoices. Generates draft invoices for a customer using their current contract configuration and the provided events. This is useful for testing how new events will affect the customer’s invoices before they are actually processed. Customers on contracts with SQL billable metrics are not supported.

Sends a POST request to /v1/customers/{customer_id}/previewEvents

Arguments:

• customer_id
• body: The events to preview

pub async fn set_up_billing_provider_v1<'a>( &'a self, body: &'a SetUpBillingProviderV1Body, ) -> Result<ResponseValue<SetUpBillingProviderV1Response>, Error<SetUpBillingProviderV1Response>>

Set up account-level billing provider

Set up account-level configuration for a billing provider. Once configured, individual contracts across customers can be mapped to this configuration using the returned delivery_method_id.

Sends a POST request to /v1/setUpBillingProvider

Arguments:

• body: Billing provider, delivery method and configuration to insert

pub async fn upsert_anrok_api_token_v1<'a>( &'a self, body: &'a UpsertAnrokApiTokenV1Body, ) -> Result<ResponseValue<UpsertAnrokApiTokenV1Response>, Error<UpsertAnrokApiTokenV1Response>>

Upsert Anrok API token

Set the Anrok API token for some specified delivery_method_ids, which can be found in the /listConfiguredBillingProviders response. This maps the Anrok key to the appropriate billing entity. These API tokens are only used for Threshold Billing workflows today.

Sends a POST request to /v1/upsertAnrokApiToken

Arguments:

• body: Set the Anrok API token for some specified delivery_method_ids

pub async fn upsert_avalara_credentials_v1<'a>( &'a self, body: &'a UpsertAvalaraCredentialsV1Body, ) -> Result<ResponseValue<Map<String, Value>>, Error<UpsertAvalaraCredentialsV1Response>>

Upsert Avalara credentials

Set the Avalara credentials for some specified delivery_method_ids, which can be found in the /listConfiguredBillingProviders response. This maps the Avalara credentials to the appropriate billing entity. These credentials are only used for PLG Invoicing today.

Sends a POST request to /v1/upsertAvalaraCredentials

Arguments:

• body: Set the Avalara credentials for some specified delivery_method_ids

pub async fn list_configured_billing_providers_v1<'a>( &'a self, body: &'a ListConfiguredBillingProvidersV1Body, ) -> Result<ResponseValue<ListConfiguredBillingProvidersV1Response>, Error<ListConfiguredBillingProvidersV1Response>>

List account-level billing providers

Lists all configured billing providers and their delivery method configurations for your account. Returns provider details, delivery method IDs, and configuration settings needed for mapping individual customer contracts to billing integrations.

Sends a POST request to /v1/listConfiguredBillingProviders

Arguments:

• body: Optional cursor to the next page of results

pub async fn get_customer_billing_provider_configurations_v1<'a>( &'a self, body: &'a GetCustomerBillingProviderConfigurationsV1Body, ) -> Result<ResponseValue<GetCustomerBillingProviderConfigurationsV1Response>, Error<GetCustomerBillingProviderConfigurationsV1Response>>

Fetch billing provider configurations for a customer

Returns all billing configurations previously set for the customer. Use during the contract provisioning process to fetch the billing_provider_configuration_id needed to set the contract billing configuration.

Sends a POST request to /v1/getCustomerBillingProviderConfigurations

Arguments:

• body: The customer id for which to fetch billing provider configurations

pub async fn get_customer_revenue_system_configurations_v1<'a>( &'a self, body: &'a GetCustomerRevenueSystemConfigurationsV1Body, ) -> Result<ResponseValue<GetCustomerRevenueSystemConfigurationsV1Response>, Error<GetCustomerRevenueSystemConfigurationsV1Response>>

Fetch revenue system configurations for a customer

Returns all revenue system configurations previously set for the customer.

Sends a POST request to /v1/getCustomerRevenueSystemConfigurations

Arguments:

• body: The customer id for which to fetch revenue system configurations

pub async fn set_customer_billing_provider_configurations_v1<'a>( &'a self, body: &'a SetCustomerBillingProviderConfigurationsV1Body, ) -> Result<ResponseValue<SetCustomerBillingProviderConfigurationsV1Response>, Error<SetCustomerBillingProviderConfigurationsV1Response>>

Set billing provider configurations for a customer

Create a billing configuration for a customer. Once created, these configurations are available to associate to a contract and dictates which downstream system to collect payment in or send the invoice to. You can create multiple configurations per customer. The configuration formats are distinct for each downstream provider.

Use this endpoint to:

• Add the initial configuration to an existing customer. Once created, the billing configuration can then be associated to the customer’s contract.
• Add a new configuration to an existing customer. This might be used as part of an upgrade or downgrade workflow where the customer was previously billed through system A (e.g. Stripe) but will now be billed through system B (e.g. AWS). Once created, the new configuration can then be associated to the customer’s contract.
• Multiple configurations can be added per destination. For example, you can create two Stripe billing configurations for a Metronome customer that each have a distinct collection_method.

Delivery method options:

• direct_to_billing_provider: Use when Metronome should send invoices directly to the billing provider’s API (e.g., Stripe, NetSuite). This is the most common method for automated billing workflows.
• tackle: Use specifically for AWS Marketplace transactions that require Tackle’s co-selling platform for partner attribution and commission tracking.
• aws_sqs: Use when you want invoice data delivered to an AWS SQS queue for custom processing before sending to your billing system.
• aws_sns: Use when you want invoice notifications published to an AWS SNS topic for event-driven billing workflows.

Key response fields:

The id for the customer billing configuration. This id can be used to associate the billing configuration to a contract.

Usage guidelines:

Must use the delivery_method_id if you have multiple Stripe accounts connected to Metronome.

Sends a POST request to /v1/setCustomerBillingProviderConfigurations

Arguments:

• body: The details of the billing provider configurations to insert

pub async fn archive_customer_billing_provider_configurations_v1<'a>( &'a self, body: &'a ArchiveCustomerBillingProviderConfigurationsV1Body, ) -> Result<ResponseValue<ArchiveCustomerBillingProviderConfigurationsV1Response>, Error<ArchiveCustomerBillingProviderConfigurationsV1Response>>

Archive billing provider configurations for a customer

Deprecate an existing billing configuration for a customer to handle churn or billing and collection preference changes. Archiving a billing configuration takes effect immediately. If there are active contracts using the configuration, Metronome will archive the configuration on the contract and immediately stop metering to downstream systems.

Use this endpoint to:

• Remove billing provider customer data and configurations when no longer needed
• Clean up test or deprecated billing provider configurations
• Free up uniqueness keys for reuse with new billing provider configurations
• Disable threshold recharge configurations associated with archived billing providers

Key response fields:

A successful response returns:

• success: Boolean indicating the operation completed successfully
• error: Null on success, error message on failure

Usage guidelines:

• Archiving a contract configuration during a grace period will result in the invoice not being sent to the customer
• Automatically disables both spend-based and credit-based threshold recharge configurations for contracts using the archived billing provider
• You can archive multiple configurations for a single customer in a single request, but any validation failures for an individual configuration will prevent the entire operation from succeeding

Sends a POST request to /v1/archiveCustomerBillingProviderConfigurations

Arguments:

• body: The ids of the billing provider configurations to archive

pub async fn set_customer_revenue_system_configurations_v1<'a>( &'a self, body: &'a SetCustomerRevenueSystemConfigurationsV1Body, ) -> Result<ResponseValue<SetCustomerRevenueSystemConfigurationsV1Response>, Error<SetCustomerRevenueSystemConfigurationsV1Response>>

Set revenue system configurations for a customer

Create a revenue system configuration for a customer. Once created, these configurations are available to associate to a contract and dictates which downstream system to use for revenue workflows. The configuration formats are distinct for each downstream provider.

Use this endpoint to:

• Add the initial configuration to an existing customer. Once created, the revenue system configuration can then be associated to the customer’s contract.
• Add a new configuration to an existing customer.

Key response fields:

Returns the inserted configuration objects, including the id of the revenue system configuration(s). These ids can be used to associate a revenue system to a contract.

Sends a POST request to /v1/setCustomerRevenueSystemConfigurations

Arguments:

• body: The details of the revenue system configurations to insert

pub async fn archive_customer_revenue_system_configurations_v1<'a>( &'a self, body: &'a ArchiveCustomerRevenueSystemConfigurationsV1Body, ) -> Result<ResponseValue<ArchiveCustomerRevenueSystemConfigurationsV1Response>, Error<ArchiveCustomerRevenueSystemConfigurationsV1Response>>

Archive revenue system configurations for a customer

Archive existing revenue system configurations for a customer. Archiving a revenue system configuration takes effect immediately.

Use this endpoint to:

• Remove revenue system configurations when no longer needed
• Clean up test or deprecated revenue system configurations

Key response fields:

A successful response returns:

• customer_id: The customer ID the configurations belong to
• customer_revenue_system_configuration_ids: The archived configuration IDs

Sends a POST request to /v1/archiveCustomerRevenueSystemConfigurations

Arguments:

• body: The ids of the revenue system configurations to archive

pub async fn embeddable_dashboard_v1<'a>( &'a self, body: &'a EmbeddableDashboardV1Body, ) -> Result<ResponseValue<EmbeddableDashboardV1Response>, Error<EmbeddableDashboardV1Response>>

Get an embeddable customer dashboard

Generate secure, embeddable dashboard URLs that allow you to seamlessly integrate Metronome’s billing visualizations directly into your application. This endpoint creates authenticated iframe-ready URLs for customer-specific dashboards, providing a white-labeled billing experience without building custom UI.

Use this endpoint to:

• Embed billing dashboards directly in your customer portal or admin interface
• Provide self-service access to invoices, usage data, and credit balances
• Build white-labeled billing experiences with minimal development effort

Key response fields:

• A secure, time-limited URL that can be embedded in an iframe
• The URL includes authentication tokens and configuration parameters
• URLs are customer-specific and respect your security settings

Usage guidelines:

• Dashboard types: Choose from invoices, usage, or commits_and_credits
• Customization options:
  • dashboard_options: Configure whether you want invoices to show zero usage line items
  • color_overrides: Match your brand’s color palette
  • bm_group_key_overrides: Customize how dimensions are displayed (for the usage embeddable dashboard)
• Iframe implementation: Embed the returned URL directly in an iframe element
• Responsive design: Dashboards automatically adapt to container dimensions

Sends a POST request to /v1/dashboards/getEmbeddableUrl

Arguments:

• body: The details of the dashboard to retrieve

pub async fn get_audit_logs_v1<'a>( &'a self, ending_before: Option<&'a DateTime<Utc>>, limit: Option<NonZeroU64>, next_page: Option<&'a str>, resource_id: Option<&'a str>, resource_type: Option<&'a str>, sort: Option<GetAuditLogsV1Sort>, starting_on: Option<&'a DateTime<Utc>>, ) -> Result<ResponseValue<GetAuditLogsV1Response>, Error<()>>

Get audit logs

Get a comprehensive audit trail of all operations performed in your Metronome account, whether initiated through the API, web interface, or automated processes. This endpoint provides detailed logs of who did what and when, enabling compliance reporting, security monitoring, and operational troubleshooting across all interaction channels.

Use this endpoint to:

• Monitor all account activity for security and compliance purposes
• Track configuration changes regardless of source (API, UI, or system)
• Investigate issues by reviewing historical operations

Key response fields:

An array of AuditLog objects containing:

• id: Unique identifier for the audit log entry
• timestamp: When the action occurred (RFC 3339 format)
• actor: Information about who performed the action
• request: Details including request ID, IP address, and user agent
• resource_type: The type of resource affected (e.g., customer, contract, invoice)
• resource_id: The specific resource identifier
• action: The operation performed
• next_page: Cursor for continuous log retrieval

Usage guidelines:

• Continuous retrieval: The next_page token enables uninterrupted log streaming—save it between requests to ensure no logs are missed
• Empty responses: An empty data array means no new logs yet; continue polling with the same next_page token
• Date filtering:
  • starting_on: Earliest logs to return (inclusive)
  • ending_before: Latest logs to return (exclusive)
  • Cannot be used with next_page
• Resource filtering: Must specify both resource_type and resource_id together
• Sort order: Default is date_asc; use date_desc for newest first

Sends a GET request to /v1/auditLogs

Arguments:

• ending_before: RFC 3339 timestamp (exclusive). Cannot be used with ‘next_page’.
• limit: Max number of results that should be returned
• next_page: Cursor that indicates where the next page of results should start.
• resource_id: Optional parameter that can be used to filter which audit logs are returned. If you specify resource_id, you must also specify resource_type.
• resource_type: Optional parameter that can be used to filter which audit logs are returned. If you specify resource_type, you must also specify resource_id.
• sort: Sort order by timestamp, e.g. date_asc or date_desc. Defaults to date_asc.
• starting_on: RFC 3339 timestamp of the earliest audit log to return. Cannot be used with ‘next_page’.

pub async fn get_services_v1<'a>( &'a self, ) -> Result<ResponseValue<GetServicesV1Response>, Error<()>>

Get services

Gets Metronome’s service registry with associated IP addresses for security allowlisting and firewall configuration. Use this endpoint to maintain an up-to-date list of IPs that your systems should trust for Metronome communications. Returns service names and their current IP ranges, with new IPs typically appearing 30+ days before first use to ensure smooth allowlist updates.

Sends a GET request to /v1/services

pub async fn add_custom_field_key_v1<'a>( &'a self, body: &'a AddCustomFieldKeyV1Body, ) -> Result<ResponseValue<()>, Error<()>>

Create a custom field key

Creates a new custom field key for a given entity (e.g. billable metric, contract, alert).

Custom fields are properties that you can add to Metronome objects to store metadata like foreign keys or other descriptors. This metadata can get transferred to or accessed by other systems to contextualize Metronome data and power business processes. For example, to service workflows like revenue recognition, reconciliation, and invoicing, custom fields help Metronome know the relationship between entities in the platform and third-party systems.

Use this endpoint to:

• Create a new custom field key for Customer objects in Metronome. You can then use the Set Custom Field Values endpoint to set the value of this key for a specific customer.
• Specify whether the key should enforce uniqueness. If the key is set to enforce uniqueness and you attempt to set a custom field value for the key that already exists, it will fail.

Usage guidelines:

• Custom fields set on commits, credits, and contracts can be used to scope alert evaluation. For example, you can create a spend threshold alert that only considers spend associated with contracts with custom field key contract_type and value paygo
• Custom fields set on products can be used in the Stripe integration to set metadata on invoices.
• Custom fields for customers, contracts, invoices, products, commits, scheduled charges, and subscriptions are passed down to the invoice.

Sends a POST request to /v1/customFields/addKey

Arguments:

• body: Add a key to the allow list for an entity

pub async fn disable_custom_field_key_v1<'a>( &'a self, body: &'a DisableCustomFieldKeyV1Body, ) -> Result<ResponseValue<()>, Error<()>>

Delete a custom field key

Removes a custom field key from the allowlist for a specific entity type, preventing future use of that key across all instances of the entity. Existing values for this key on entity instances will no longer be accessible once the key is removed.

Sends a POST request to /v1/customFields/removeKey

Arguments:

• body: Remove a key from the allow list for an entity

pub async fn set_custom_fields_v1<'a>( &'a self, body: &'a SetCustomFieldsV1Body, ) -> Result<ResponseValue<()>, Error<()>>

Set custom field values

Sets custom field values on a specific Metronome entity instance. Overwrites existing values for matching keys while preserving other fields. All updates are transactional—either all values are set or none are. Custom field values are limited to 200 characters each.

Sends a POST request to /v1/customFields/setValues

Arguments:

• body: The custom field values to set

pub async fn delete_custom_fields_v1<'a>( &'a self, body: &'a DeleteCustomFieldsV1Body, ) -> Result<ResponseValue<()>, Error<()>>

Delete custom fields

Remove specific custom field values from a Metronome entity instance by specifying the field keys to delete. Use this endpoint to clean up unwanted custom field data while preserving other fields on the same entity. Requires the entity type, entity ID, and array of keys to remove.

Sends a POST request to /v1/customFields/deleteValues

Arguments:

• body: Delete one or more custom fields

pub async fn list_custom_field_keys_v1<'a>( &'a self, next_page: Option<&'a str>, body: &'a ListCustomFieldKeysV1Body, ) -> Result<ResponseValue<ListCustomFieldKeysV1Response>, Error<()>>

List custom field keys

Retrieve all your active custom field keys, with optional filtering by entity type (customer, contract, product, etc.). Use this endpoint to discover what custom field keys are available before setting values on entities or to audit your custom field configuration across different entity types.

Sends a POST request to /v1/customFields/listKeys

Arguments:

• next_page: Cursor that indicates where the next page of results should start.
• body

pub async fn get_product_v1<'a>( &'a self, body: &'a GetProductV1Body, ) -> Result<ResponseValue<GetProductV1Response>, Error<GetProductV1Response>>

Get a product

Retrieve a product by its ID, including all metadata and historical changes.

Sends a POST request to /v1/contract-pricing/products/get

Arguments:

• body: The ID of the product to get

pub async fn list_products_v1<'a>( &'a self, limit: Option<NonZeroU64>, next_page: Option<&'a str>, body: &'a ListProductsV1Body, ) -> Result<ResponseValue<ListProductsV1Response>, Error<()>>

List products

Get a paginated list of all products in your organization with their complete configuration, version history, and metadata. By default excludes archived products unless explicitly requested via the archive_filter parameter.

Sends a POST request to /v1/contract-pricing/products/list

Arguments:

• limit: Max number of results that should be returned
• next_page: Cursor that indicates where the next page of results should start.
• body: Get list of products

pub async fn create_product_v1<'a>( &'a self, body: &'a CreateProductV1Body, ) -> Result<ResponseValue<CreateProductV1Response>, Error<CreateProductV1Response>>

Create a product

Create a new product object. Products in Metronome represent your company’s individual product or service offerings. A Product can be thought of as the basic unit of a line item on the invoice. This is analogous to SKUs or items in an ERP system. Give the product a meaningful name as they will appear on customer invoices.

Sends a POST request to /v1/contract-pricing/products/create

Arguments:

• body: Create a new product

pub async fn update_product_v1<'a>( &'a self, body: &'a UpdateProductV1Body, ) -> Result<ResponseValue<UpdateProductV1Response>, Error<UpdateProductV1Response>>

Update a product

Updates a product’s configuration while maintaining billing continuity for active customers. Use this endpoint to modify product names, metrics, pricing rules, and composite settings without disrupting ongoing billing cycles. Changes are scheduled using the starting_at timestamp, which must be on an hour boundary—set future dates to schedule updates ahead of time, or past dates for retroactive changes. Returns the updated product ID upon success.

Usage guidance:

• Product type cannot be changed after creation. For incorrect product types, create a new product and archive the original instead.

Sends a POST request to /v1/contract-pricing/products/update

Arguments:

• body: Updates a product’s configuration while maintaining billing continuity for active customers. Use this endpoint to modify product names, metrics, pricing rules, and composite settings without disrupting ongoing billing cycles. Changes are scheduled using the starting_at timestamp, which must be on an hour boundary–set future dates to schedule updates ahead of time, or past dates for retroactive changes. Returns the updated product ID upon success.

Usage guidance: Product type cannot be changed after creation. For incorrect product types, create a new product and archive the original instead.

pub async fn archive_product_list_item_v1<'a>( &'a self, body: &'a ArchiveProductListItemV1Body, ) -> Result<ResponseValue<ArchiveProductListItemV1Response>, Error<ArchiveProductListItemV1Response>>

Archive a product

Archive a product. Any current rate cards associated with this product will continue to function as normal. However, it will no longer be available as an option for newly created rates. Once you archive a product, you can still retrieve it in the UI and API, but you cannot unarchive it.

Sends a POST request to /v1/contract-pricing/products/archive

Arguments:

• body: Archive a product

pub async fn get_rate_schedule_v1<'a>( &'a self, limit: Option<NonZeroU64>, next_page: Option<&'a str>, body: &'a GetRateScheduleV1Body, ) -> Result<ResponseValue<GetRateScheduleV1Response>, Error<()>>

Get a rate schedule

A rate card defines the prices that you charge for your products. Rate cards support scheduled changes over time, to allow you to easily roll out pricing changes and new product launches across your customer base. Use this endpoint to understand the rate schedule starting_at a given date, optionally filtering the list of rates returned based on product id or pricing group values. For example, you may want to display a schedule of upcoming price changes for a given product in your product experience - use this endpoint to fetch that information from its source of truth in Metronome.

If you want to understand the rates for a specific customer’s contract, inclusive of contract-level overrides, use the getContractRateSchedule endpoint.

Sends a POST request to /v1/contract-pricing/rate-cards/getRateSchedule

Arguments:

• limit: Max number of results that should be returned
• next_page: Cursor that indicates where the next page of results should start.
• body: Rate schedule filter options.

pub async fn get_rates_v1<'a>( &'a self, limit: Option<NonZeroU64>, next_page: Option<&'a str>, body: &'a GetRatesV1Body, ) -> Result<ResponseValue<GetRatesV1Response>, Error<()>>

Get rates

Understand the rate schedule at a given timestamp, optionally filtering the list of rates returned based on properties such as product_id and pricing_group_values. For example, you may want to display the current price for a given product in your product experience - use this endpoint to fetch that information from its source of truth in Metronome.

If you want to understand the rates for a specific customer’s contract, inclusive of contract-level overrides, use the getContractRateSchedule endpoint.

Sends a POST request to /v1/contract-pricing/rate-cards/getRates

Arguments:

• limit: Max number of results that should be returned
• next_page: Cursor that indicates where the next page of results should start.
• body: Rate schedule filter options.

pub async fn get_rate_card_v1<'a>( &'a self, body: &'a GetRateCardV1Body, ) -> Result<ResponseValue<GetRateCardV1Response>, Error<GetRateCardV1Response>>

Get a rate card

Return details for a specific rate card including name, description, and aliases. This endpoint does not return rates - use the dedicated getRates or getRateSchedule endpoints to understand the rates on a rate card.

Sends a POST request to /v1/contract-pricing/rate-cards/get

Arguments:

• body: The ID of the rate card to get

pub async fn list_rate_cards_v1<'a>( &'a self, limit: Option<NonZeroU64>, next_page: Option<&'a str>, body: &'a ListRateCardsV1Body, ) -> Result<ResponseValue<ListRateCardsV1Response>, Error<()>>

List rate cards

List all rate cards. Returns rate card IDs, names, descriptions, aliases, and other details. To view the rates associated with a given rate card, use the getRates or getRateSchedule endpoints.

Sends a POST request to /v1/contract-pricing/rate-cards/list

Arguments:

• limit: Max number of results that should be returned
• next_page: Cursor that indicates where the next page of results should start.
• body

pub async fn create_rate_card_v1<'a>( &'a self, body: &'a CreateRateCardV1Body, ) -> Result<ResponseValue<CreateRateCardV1Response>, Error<CreateRateCardV1Response>>

Create a rate card

In Metronome, the rate card is the central location for your pricing. Rate cards were built with new product launches and pricing changes in mind - you can update your products and pricing in one place, and that change will be automatically propagated across your customer cohorts. Most clients need only maintain one or a few rate cards within Metronome.

Use this endpoint to:

• Create a rate card with a name and description
• Define the rate card’s single underlying fiat currency, and any number of conversion rates between that fiat currency and custom pricing units. You can then add products and associated rates in the fiat currency or custom pricing unit for which you have defined a conversion rate.
• Set aliases for the rate card. Aliases are human-readable names that you can use in the place of the id of the rate card when provisioning a customer’s contract. By using an alias, you can easily create a contract and provision a customer by choosing the paygo rate card, without storing the rate card id in your internal systems. This is helpful when launching a new rate card for paygo customers, you can update the alias for paygo to be scheduled to be assigned to the new rate card without updating your code.

Key response fields:

• The ID of the rate card you just created

Usage guidelines:

• After creating a rate card, you can now use the addRate or addRates endpoints to add products and their prices to it
• A rate card alias can only be used by one rate card at a time. If you create a contract with a rate card alias that is already in use by another rate card, the original rate card’s alias schedule will be updated. The alias will reference the rate card to which it was most recently assigned.

Sends a POST request to /v1/contract-pricing/rate-cards/create

Arguments:

• body: In Metronome, the rate card is the central location for your pricing. Rate cards were built with new product launches and pricing changes in mind - you can update your products and pricing in one place, and that change will be automatically propagated across your customer cohorts. Most clients need only maintain one or a few rate cards within Metronome.

Use this endpoint to:

• Create a rate card with a name and description
• Define the rate card’s single underlying fiat currency, and any number of conversion rates between that fiat currency and custom pricing units. You can then add products and associated rates in the fiat currency or custom pricing unit for which you have defined a conversion rate.
• Set aliases for the rate card. Aliases are human-readable names that you can use in the place of the id of the rate card when provisioning a customer’s contract. By using an alias, you can easily create a contract and provision a customer by choosing the paygo rate card, without storing the rate card id in your internal systems. This is helpful when launching a new rate card for paygo customers, you can update the alias for paygo to be scheduled to be assigned to the new rate card without updating your code.

Key response fields:

• The ID of the rate card you just created

Usage guidelines:

• After creating a rate card, you can now use the addRate or addRates endpoints to add products and their prices to it
• A rate card alias can only be used by one rate card at a time. If you create a contract with a rate card alias that is already in use by another rate card, the original rate card’s alias schedule will be updated. The alias will reference the rate card to which it was most recently assigned.

pub async fn update_rate_card_v1<'a>( &'a self, body: &'a UpdateRateCardV1Body, ) -> Result<ResponseValue<UpdateRateCardV1Response>, Error<UpdateRateCardV1Response>>

Update a rate card

Update the metadata properties of an existing rate card, including its name, description, and aliases. This endpoint is designed for managing rate card identity and reference aliases rather than modifying pricing rates.

Modifies the descriptive properties and alias configuration of a rate card without affecting the underlying pricing rates or schedules. This allows you to update how a rate card is identified and referenced throughout your system.

Use this endpoint to:

• Rate card renaming: Update display names or descriptions for organizational clarity
• Alias management: Add, modify, or schedule alias transitions for seamless rate card migrations
• Documentation updates: Keep rate card descriptions current with business context
• Self-serve provisioning setup: Configure aliases to enable code-free rate card transitions

Active contract impact:

• Alias changes: Already-created contracts continue using their originally assigned rate cards.
• Other changes made using this endpoint will only impact the Metronome UI.

Grandfathering existing PLG customer pricing:

• Rate card aliases support scheduled transitions, enabling seamless rate card migrations for new customers, allowing existing customers to be grandfathered into their existing prices without code. Note that there are multiple mechanisms to support grandfathering in Metronome.

How scheduled aliases work for PLG grandfathering:

Initial setup:

• Add alias to current rate card: Assign a stable alias (e.g., “standard-pricing”) to your active rate card
• Reference alias during contract creation: Configure your self-serve workflow to create contracts using rate_card_alias instead of direct rate_card_id
• Automatic resolution: New contracts referencing the alias automatically resolve to the rate card associated with the alias at the point in time of provisioning

Grandfathering process:

• Create new rate card: Build your new rate card with updated pricing structure
• Schedule alias transition: Add the same alias to the new rate card with a starting_at timestamp
• Automatic cutover: Starting at the scheduled time, new contracts created in your PLG workflow using that alias will automatically reference the new rate card

Sends a POST request to /v1/contract-pricing/rate-cards/update

Arguments:

• body: Update a rate card. Must provide at least one of name or description.

pub async fn archive_rate_card_v1<'a>( &'a self, body: &'a ArchiveRateCardV1Body, ) -> Result<ResponseValue<ArchiveRateCardV1Response>, Error<ArchiveRateCardV1Response>>

Archive a rate card

Permanently disable a rate card by archiving it, preventing use in new contracts while preserving existing contract pricing. Use this when retiring old pricing models, consolidating rate cards, or removing outdated pricing structures. Returns the archived rate card ID and stops the rate card from appearing in contract creation workflows.

Sends a POST request to /v1/contract-pricing/rate-cards/archive

Arguments:

• body: The ID of the rate card to archive

pub async fn add_rate_v1<'a>( &'a self, body: &'a AddRateV1Body, ) -> Result<ResponseValue<AddRateV1Response>, Error<AddRateV1Response>>

Add a rate

Add a new rate

This endpoint is heavily rate limited. For adding multiple rates, using the addRates endpoint is strongly encouraged.

Sends a POST request to /v1/contract-pricing/rate-cards/addRate

Arguments:

• body: Add a new rate

pub async fn add_rates_v1<'a>( &'a self, body: &'a AddRatesV1Body, ) -> Result<ResponseValue<AddRatesV1Response>, Error<AddRatesV1Response>>

Add rates

Add new rates

Sends a POST request to /v1/contract-pricing/rate-cards/addRates

Arguments:

• body: Add new rates

pub async fn set_rate_card_products_order_v1<'a>( &'a self, body: &'a SetRateCardProductsOrderV1Body, ) -> Result<ResponseValue<SetRateCardProductsOrderV1Response>, Error<SetRateCardProductsOrderV1Response>>

Set the rate card products order

The ordering of products on a rate card determines the order in which the products will appear on customers’ invoices. Use this endpoint to set the order of products on the rate card.

Sends a POST request to /v1/contract-pricing/rate-cards/setRateCardProductsOrder

Arguments:

• body: New rate card product ordering

pub async fn move_rate_card_products_v1<'a>( &'a self, body: &'a MoveRateCardProductsV1Body, ) -> Result<ResponseValue<MoveRateCardProductsV1Response>, Error<MoveRateCardProductsV1Response>>

Update the rate card products order

The ordering of products on a rate card determines the order in which the products will appear on customers’ invoices. Use this endpoint to set the order of specific products on the rate card by moving them relative to their current location.

Sends a POST request to /v1/contract-pricing/rate-cards/moveRateCardProducts

Arguments:

• body: New rate card product ordering

pub async fn get_contract_v1<'a>( &'a self, body: &'a GetContractV1Body, ) -> Result<ResponseValue<GetContractV1Response>, Error<GetContractV1Response>>

Get a contract (v1)

This is the v1 endpoint to get a contract. New clients should implement using the v2 endpoint.

Sends a POST request to /v1/contracts/get

Arguments:

• body: Contract and customer IDs

pub async fn list_contracts_v1<'a>( &'a self, body: &'a ListContractsV1Body, ) -> Result<ResponseValue<ListContractsV1Response>, Error<ListContractsV1Response>>

List customer contracts (v1)

Retrieves all contracts for a specific customer, including pricing, terms, credits, and commitments. Use this to view a customer’s contract history and current agreements for billing management. Returns contract details with optional ledgers and balance information.

⚠️ Note: This is the legacy v1 endpoint - new integrations should use the v2 endpoint for enhanced features.

Sends a POST request to /v1/contracts/list

Arguments:

• body: List all contracts for a customer

pub async fn create_contract_v1<'a>( &'a self, body: &'a CreateContractV1Body, ) -> Result<ResponseValue<CreateContractV1Response>, Error<CreateContractV1Response>>

Create a contract

Contracts define a customer’s products, pricing, discounts, access duration, and billing configuration. Contracts serve as the central billing agreement for both PLG and Enterprise customers. You can automatically grant customers access to your products and services directly from your product or CRM.

Use this endpoint to:

• PLG onboarding: Automatically provision new self-serve customers with contracts when they sign up.
• Enterprise sales: Push negotiated contracts from Salesforce with custom pricing and commitments
• Promotional pricing: Implement time-limited discounts and free trials through overrides

Key components:

Contract Term and Billing Schedule

• Set contract duration using starting_at and ending_before fields. PLG contracts typically use perpetual agreements (no end date), while Enterprise contracts have fixed end dates which can be edited over time in the case of co-term upsells.

Rate Card

If you are offering usage based pricing, you can set a rate card for the contract to reference through rate_card_id or rate_card_alias. The rate card is a store of all of your usage based products and their centralized pricing. Any new products or price changes on the rate card can be set to automatically propagate to all associated contracts - this ensures consistent pricing and product launches flow to contracts without manual updates and migrations. The usage_statement_schedule determines the cadence on which Metronome will finalize a usage invoice for the customer. This defaults to monthly on the 1st, with options for custom dates, quarterly, or annual cadences. Note: Most usage based billing companies align usage statements to be evaluated aligned to the first of the month. Read more about Rate Cards.

Overrides and discounts

Customize pricing on the contract through time-bounded overrides that can target specific products, product families, or complex usage scenarios. Overrides enable two key capabilities:

• Discounts: Apply percentage discounts, fixed rate reductions, or quantity-based pricing tiers
• Entitlements: Provide special pricing or access to specific products for negotiated deals

Read more about Contract Overrides.

Commits and Credits

Using commits, configure prepaid or postpaid spending commitments where customers promise to spend a certain amount over the contract period paid in advance or in arrears. Use credits to provide free spending allowances. Under the hood these are the same mechanisms, however, credits are typically offered for free (SLA or promotional) or as a part of an allotment associated with a Subscription.

In Metronome, you can set commits and credits to only be applicable for a subset of usage. Use applicable_product_ids or applicable_product_tags to create product or product-family specific commits or credits, or you can build complex boolean logic specifiers to target usage based on pricing and presentation group values using override_specifiers.

These objects can also also be configured to have a recurrence schedule to easily model customer packaging which includes recurring monthly or quarterly allotments.

Commits support rollover settings (rollover_fraction) to transfer unused balances between contract periods, either entirely or as a percentage.

Read more about Credits and Commits.

Subscriptions

You can add a fixed recurring charge to a contract, like monthly licenses or seat-based fees, using the subscription charge. Subscription charges are defined on your rate card and you can select which subscription is applicable to add to each contract. When you add a subscription to a contract you need to:

• Define whether the subscription is paid for in-advance or in-arrears (collection_schedule)
• Define the proration behavior (proration)
• Specify an initial quantity (initial_quantity)
• Define which subscription rate on the rate card should be used (subscription_rate)

Read more about Subscriptions.

Scheduled Charges

Set up one-time, recurring, or entirely custom charges that occur on specific dates, separate from usage-based billing or commitments. These can be used to model non-recurring platform charges or professional services.

Threshold Billing

Metronome allows you to configure automatic billing triggers when customers reach spending thresholds to prevent fraud and manage risk. You can use spend_threshold_configuration to trigger an invoice to cover current charges whenever the threshold is reached or you can ensure the customer maintains a minimum prepaid balance using the prepaid_balance_configuration.

Read more about Spend Threshold and Prepaid Balance Thresholds.

Usage guidelines:

• You can always Edit Contracts after it has been created, using the editContract endpoint. Metronome keeps track of all edits, both in the audit log and over the getEditHistory endpoint.
• Customers in Metronome can have multiple concurrent contracts at one time. Use usage_filters to route the correct usage to each contract. Read more about usage filters.

Sends a POST request to /v1/contracts/create

Arguments:

• body: Create a new contract

pub async fn amend_contract_v1<'a>( &'a self, body: &'a AmendContractV1Body, ) -> Result<ResponseValue<AmendContractV1Response>, Error<AmendContractV1Response>>

Amend a contract

Amendments will be replaced by Contract editing. New clients should implement using the editContract endpoint. Read more about the migration to contract editing here and reach out to your Metronome representative for more details. Once contract editing is enabled, access to this endpoint will be removed.

Sends a POST request to /v1/contracts/amend

Arguments:

• body: Amend a contract

pub async fn archive_contract_v1<'a>( &'a self, body: &'a ArchiveContractV1Body, ) -> Result<ResponseValue<ArchiveContractV1Response>, Error<ArchiveContractV1Response>>

Archive a contract

Permanently end and archive a contract along with all its terms. Any draft invoices will be canceled, and all upcoming scheduled invoices will be voided–also all finalized invoices can optionally be voided. Use this in the event a contract was incorrectly created and needed to be removed from a customer.

Impact on commits and credits:

When archiving a contract, all associated commits and credits are also archived. For prepaid commits with active segments, Metronome automatically generates expiration ledger entries to close out any remaining balances, ensuring accurate accounting of unused prepaid amounts. These ledger entries will appear in the commit’s transaction history with type PREPAID_COMMIT_EXPIRATION.

Archived contract visibility:

Archived contracts remain accessible for historical reporting and audit purposes. They can be retrieved using the ListContracts endpoint by setting the include_archived parameter to true or in the Metronome UI when the “Show archived” option is enabled.

Sends a POST request to /v1/contracts/archive

Arguments:

• body: Permanently end and archive a contract along with all its terms. Any draft invoices will be canceled, and all upcoming scheduled invoices will be voided–also all finalized invoices can optionally be voided. Use this in the event a contract was incorrectly created and needed to be removed from a customer.

Impact on commits and credits: When archiving a contract, all associated commits and credits are also archived. For prepaid commits with active segments, Metronome automatically generates expiration ledger entries to close out any remaining balances, ensuring accurate accounting of unused prepaid amounts. These ledger entries will appear in the commit’s transaction history with type PREPAID_COMMIT_EXPIRATION.

Archived contract visibility: Archived contracts remain accessible for historical reporting and audit purposes. They can be retrieved using the ListContracts endpoint by setting the include_archived parameter to true or in the Metronome UI when the “Show archived” option is enabled.

pub async fn set_usage_filter_v1<'a>( &'a self, body: &'a SetUsageFilterV1Body, ) -> Result<ResponseValue<()>, Error<SetUsageFilterV1Response>>

Set a contract usage filter

If a customer has multiple contracts with overlapping rates, the usage filter routes usage to the appropriate contract based on a predefined group key.

As an example, imagine you have a customer associated with two projects. Each project is associated with its own contract. You can create a usage filter with group key project_id on each contract, and route usage for project_1 to the first contract and project_2 to the second contract.

Use this endpoint to:

• Support enterprise contracting scenarios where multiple contracts are associated to the same customer with the same rates.
• Update the usage filter associated with the contract over time.

Usage guidelines:

To use usage filters, the group_key must be defined on the billable metrics underlying the rate card on the contracts.

Sends a POST request to /v1/contracts/setUsageFilter

Arguments:

• body: Set usage filter for contract

pub async fn add_manual_balance_ledger_entry_v1<'a>( &'a self, body: &'a AddManualBalanceLedgerEntryV1Body, ) -> Result<ResponseValue<()>, Error<AddManualBalanceLedgerEntryV1Response>>

Add a manual balance entry

Manually adjust the available balance on a commit or credit. This entry is appended to the commit ledger as a new event. Optionally include a description that provides the reasoning for the entry.

Use this endpoint to:

• Address incorrect usage burn-down caused by malformed usage or invalid config
• Decrease available balance to account for outages where usage may have not been tracked or sent to Metronome
• Issue credits to customers in the form of increased balance on existing commit or credit

Usage guidelines:

Manual ledger entries can be extremely useful for resolving discrepancies in Metronome. However, most corrections to inaccurate billings can be modified upstream of the commit, whether that is via contract editing, rate editing, or other actions that cause an invoice to be recalculated.

Sends a POST request to /v1/contracts/addManualBalanceLedgerEntry

Arguments:

• body: Add a manual ledger entry to a balance

pub async fn update_invoice_issue_date_v1<'a>( &'a self, body: &'a UpdateInvoiceIssueDateV1Body, ) -> Result<ResponseValue<UpdateInvoiceIssueDateV1Response>, Error<UpdateInvoiceIssueDateV1Response>>

Update invoice issue date

Updates the issue date of a specific DRAFT invoice within a contract. Use this endpoint to reschedule when an invoice should be issued without affecting future billing cycles or the underlying contract terms. Only works with invoices still in DRAFT status, and the new issue date cannot be later than the contract’s end date.

Usage guidelines:

This only changes the individual invoice’s issue date - it does not modify the recurring invoice schedule of associated charges or commits. To update both the issue date and future billing schedule, use the ‘edit contract’ or ‘edit commit’ endpoints instead.

Sends a POST request to /v1/contracts/updateInvoiceIssueDate

Arguments:

• body: The invoice_id and new issue_date

pub async fn update_contract_end_date_v1<'a>( &'a self, body: &'a UpdateContractEndDateV1Body, ) -> Result<ResponseValue<UpdateContractEndDateV1Response>, Error<UpdateContractEndDateV1Response>>

Update the contract end date

Update or add an end date to a contract. Ending a contract early will impact draft usage statements, truncate any terms, and remove upcoming scheduled invoices. Moving the date into the future will only extend the contract length. Terms and scheduled invoices are not extended. In-advance subscriptions will not be extended. Use this if a contract’s end date has changed or if a perpetual contract ends.

Sends a POST request to /v1/contracts/updateEndDate

Arguments:

• body: Update the end date of a contract

pub async fn get_contract_rate_schedule_v1<'a>( &'a self, limit: Option<NonZeroU64>, next_page: Option<&'a str>, body: &'a GetContractRateScheduleV1Body, ) -> Result<ResponseValue<GetContractRateScheduleV1Response>, Error<()>>

Get the rate schedule for a contract

For a specific customer and contract, get the rates at a specific point in time. This endpoint takes the contract’s rate card into consideration, including scheduled changes. It also takes into account overrides on the contract.

For example, if you want to show your customer a summary of the prices they are paying, inclusive of any negotiated discounts or promotions, use this endpoint. This endpoint only returns rates that are entitled.

Sends a POST request to /v1/contracts/getContractRateSchedule

Arguments:

• limit: Max number of results that should be returned
• next_page: Cursor that indicates where the next page of results should start.
• body: Contract rate schedule filter options.

pub async fn get_subscription_quantity_history_v1<'a>( &'a self, body: &'a GetSubscriptionQuantityHistoryV1Body, ) -> Result<ResponseValue<GetSubscriptionQuantityHistoryV1Response>, Error<GetSubscriptionQuantityHistoryV1Response>>

Get subscription quantity history

Get the history of subscription quantities and prices over time for a given subscription_id. This endpoint can be used to power an in-product experience where you show a customer their historical changes to seat count. Future changes are not included in this endpoint - use the getContract endpoint to view the future scheduled changes to a subscription’s quantity.

Subscriptions are used to model fixed recurring fees as well as seat-based recurring fees. To model changes to the number of seats in Metronome, you can increment or decrement the quantity on a subscription at any point in the past or future.

Sends a POST request to /v1/contracts/getSubscriptionQuantityHistory

pub async fn get_subscription_seats_history_v1<'a>( &'a self, body: &'a GetSubscriptionSeatsHistoryV1Body, ) -> Result<ResponseValue<GetSubscriptionSeatsHistoryV1Response>, Error<GetSubscriptionSeatsHistoryV1Response>>

Get subscription seats history

Get the history of subscription seats schedule over time for a given subscription_id. This endpoint provides information about seat assignments and total quantities for different time periods, allowing you to track how seat assignments have changed over time.

Use this endpoint to:

• Track changes to seat assignments over time
• Get seat schedule for a specific date using the covering_date parameter
• Get seat schedule history with optional date range filtering using starting_at and ending_before

Key response fields:

• data: array of seat schedule entries with time periods, quantity, and assignments
• next_page: cursor for pagination to retrieve additional results

Usage guidelines:

• Use covering_date to get the active seats for a specific point in time. covering_date cannot be used with starting_at or ending_before.
• Use starting_at and ending_before to filter results by time range. starting_at and ending_before cannot be used with covering_date.
• Maximum limit is 10 seat schedule entries per request
• Results are ordered by starting_at timestamp

Sends a POST request to /v1/contracts/getSubscriptionSeatsHistory

pub async fn list_customer_commits_v1<'a>( &'a self, body: &'a ListCustomerCommitsV1Body, ) -> Result<ResponseValue<ListCustomerCommitsV1Response>, Error<()>>

List commits

Retrieve all commit agreements for a customer, including both prepaid and postpaid commitments. This endpoint provides comprehensive visibility into contractual spending obligations, enabling you to track commitment utilization and manage customer contracts effectively.

Use this endpoint to:

• Display commitment balances and utilization in customer dashboards
• Track prepaid commitment drawdown and remaining balances
• Monitor postpaid commitment progress toward minimum thresholds
• Build commitment tracking and forecasting tools
• Show commitment history with optional ledger details
• Manage rollover balances between contract periods

Key response fields:

An array of Commit objects containing:

• Commit type: PREPAID (pay upfront) or POSTPAID (pay at true-up)
• Rate type: COMMIT_RATE (discounted) or LIST_RATE (standard pricing)
• Access schedule: When commitment funds become available
• Invoice schedule: When the customer is billed
• Product targeting: Which product(s) usage is eligible to draw from this commit
• Optional ledger entries: Transaction history (if include_ledgers=true)
• Balance information: Current available amount (if include_balance=true)
• Rollover settings: Fraction of unused amount that carries forward

Usage guidelines:

• Pagination: Results limited to 25 commits per page; use ‘next_page’ for more
• Date filtering options:
  • covering_date: Commits active on a specific date
  • starting_at: Commits with access on/after a date
  • effective_before: Commits with access before a date (exclusive)
• Scope options:
  • include_contract_commits: Include contract-level commits (not just customer-level)
  • include_archived: Include archived commits and commits from archived contracts
• Performance considerations:
  • include_ledgers: Adds detailed transaction history (slower)
  • include_balance: Adds current balance calculation (slower)
• Optional filtering: Use commit_id to retrieve a specific commit

Sends a POST request to /v1/contracts/customerCommits/list

Arguments:

• body: List all commits for a customer

pub async fn create_customer_commit_v1<'a>( &'a self, body: &'a CreateCustomerCommitV1Body, ) -> Result<ResponseValue<CreateCustomerCommitV1Response>, Error<CreateCustomerCommitV1Response>>

Create a commit

Creates customer-level commits that establish spending commitments for customers across their Metronome usage. Commits represent contracted spending obligations that can be either prepaid (paid upfront) or postpaid (billed later).

Note: In most cases, you should add commitments directly to customer contracts using the contract/create or contract/edit APIs.

Use this endpoint to:

Use this endpoint when you need to establish customer-level spending commitments that can be applied across multiple contracts or scoped to specific contracts. Customer-level commits are ideal for:

• Enterprise-wide minimum spending agreements that span multiple contracts
• Multi-contract volume commitments with shared spending pools
• Cross-contract discount tiers based on aggregate usage

Commit type Requirements:

• You must specify either “prepaid” or “postpaid” as the commit type:
• Prepaid commits: Customer pays upfront; invoice_schedule is optional (if omitted, creates a commit without an invoice)
• Postpaid commits: Customer pays when the commitment expires (the end of the access_schedule); invoice_schedule is required and must match access_schedule totals.

Billing configuration:

• invoice_contract_id is required for postpaid commits and for prepaid commits with billing (only optional for free prepaid commits) unless do_not_invoice is set to true
• For postpaid commits: access_schedule and invoice_schedule must have matching amounts
• For postpaid commits: only one schedule item is allowed in both schedules.

Scoping flexibility:

Customer-level commits can be configured in a few ways:

• Contract-specific: Use the applicable_contract_ids field to limit the commit to specific contracts
• Cross-contract: Leave applicable_contract_ids empty to allow the commit to be used across all of the customer’s contracts

Product targeting:

Commits can be scoped to specific products using applicable_product_ids, applicable_product_tags, or specifiers, or left unrestricted to apply to all products.

Priority considerations:

When multiple commits are applicable, the one with the lower priority value will be consumed first. If there is a tie, contract level commits and credits will be applied before customer level commits and credits. Plan your priority scheme carefully to ensure commits are applied in the desired order.

Usage guidelines:

⚠️ Preferred Alternative: In most cases, you should add commits directly to contracts using the create contract or edit contract APIs instead of creating customer-level commits. Contract-level commits provide better organization and are the recommended approach for standard use cases.

Sends a POST request to /v1/contracts/customerCommits/create

Arguments:

• body: Create a commit

pub async fn update_commit_end_date_v1<'a>( &'a self, body: &'a UpdateCommitEndDateV1Body, ) -> Result<ResponseValue<UpdateCommitEndDateV1Response>, Error<UpdateCommitEndDateV1Response>>

Update the commit end date

Shortens the end date of a prepaid commit to terminate it earlier than originally scheduled. Use this endpoint when you need to cancel or reduce the duration of an existing prepaid commit. Only works with prepaid commit types and can only move the end date forward (earlier), not extend it.

Usage guidelines:

To extend commit end dates or make other comprehensive edits, use the ‘edit commit’ endpoint instead.

Sends a POST request to /v1/contracts/customerCommits/updateEndDate

Arguments:

• body: Update the access or invoice end date of a commit

pub async fn release_external_payment_gate_threshold_commit_v1<'a>( &'a self, body: &'a ReleaseExternalPaymentGateThresholdCommitV1Body, ) -> Result<ResponseValue<()>, Error<()>>

Release external payment gate threshold commit

If using threshold billing with an external payment gateway, Metronome does not facilitate the payment gating process on behalf of the client. As a result, clients must facilitate the transaction themselves. This end-point is used to either release or cancel the commit pending on the outcome of the external payment attempt.

To release the commit, you must pass the workflow_id provided in the payment_gate.external_initiate webhook.

Use this endpoint to:

Facilitate payment gating workflows for threshold billing if using a payment gateway Metronome does not support today.

Usage guidelines:

Ensure that you are set up to consume the payment_gate.external_initiate webhook and save the workflow_id.

Sends a POST request to /v1/contracts/commits/threshold-billing/release

Arguments:

• body: Information to identify the workflow that is in progress to release the commit, and what action we should take to complete the workflow.

pub async fn disable_commit_trueup_v1<'a>( &'a self, body: &'a DisableCommitTrueupV1Body, ) -> Result<ResponseValue<DisableCommitTrueupV1Response>, Error<DisableCommitTrueupV1Response>>

Disable trueup for commit

Disable the true-up invoice for a postpaid commit. If used, the true-up invoice will not be generated.

For postpaid commits, usage during the access period is paid for in arrears. If the total amount paid during the access period is less than the committed amount, there’s a final true-up invoice on the invoice_date.

Sends a POST request to /v1/contracts/commits/disableTrueup

Arguments:

• body: Information to identify the commit

pub async fn list_customer_credits_v1<'a>( &'a self, body: &'a ListCustomerCreditsV1Body, ) -> Result<ResponseValue<ListCustomerCreditsV1Response>, Error<()>>

List credits

Retrieve a detailed list of all credits available to a customer, including promotional credits and contract-specific credits. This endpoint provides comprehensive visibility into credit balances, access schedules, and usage rules, enabling you to build credit management interfaces and track available funding.

Use this endpoint to:

• Display all available credits in customer billing dashboards
• Show credit balances and expiration dates
• Track credit usage history with optional ledger details
• Build credit management and reporting tools
• Monitor promotional credit utilization • Support customer inquiries about available credits

Key response fields:

An array of Credit objects containing:

• Credit details: Name, priority, and which applicable products/tags it applies to
• Product ID: The product_id of the credit. This is for external mapping into your quote-to-cash stack, not the product it applies to.
• Access schedule: When credits become available and expire
• Optional ledger entries: Transaction history (if include_ledgers=true)
• Balance information: Current available amount (if include_balance=true)
• Metadata: Custom fields and usage specifiers

Usage guidelines:

• Pagination: Results limited to 25 commits per page; use next_page for more
• Date filtering options:
  • covering_date: Credits active on a specific date
  • starting_at: Credits with access on/after a date
  • effective_before: Credits with access before a date (exclusive)
• Scope options:
  • include_contract_credits: Include contract-level credits (not just customer-level)
  • include_archived: Include archived credits and credits from archived contracts
• Performance considerations:
  • include_ledgers: Adds detailed transaction history (slower)
  • include_balance: Adds current balance calculation (slower)
• Optional filtering: Use credit_id to retrieve a specific commit

Sends a POST request to /v1/contracts/customerCredits/list

Arguments:

• body: List all credits for a customer

pub async fn create_customer_credit_v1<'a>( &'a self, body: &'a CreateCustomerCreditV1Body, ) -> Result<ResponseValue<CreateCustomerCreditV1Response>, Error<CreateCustomerCreditV1Response>>

Create a credit

Creates customer-level credits that provide spending allowances or free credit balances for customers across their Metronome usage. Note: In most cases, you should add credits directly to customer contracts using the contract/create or contract/edit APIs.

Use this endpoint to:

Use this endpoint when you need to provision credits directly at the customer level that can be applied across multiple contracts or scoped to specific contracts. Customer-level credits are ideal for:

• Customer onboarding incentives that apply globally
• Flexible spending allowances that aren’t tied to a single contract
• Migration scenarios where you need to preserve existing customer balances

Scoping flexibility:

Customer-level credits can be configured in two ways:

• Contract-specific: Use the applicable_contract_ids field to limit the credit to specific contracts
• Cross-contract: Leave applicable_contract_ids empty to allow the credit to be used across all of the customer’s contracts

Product Targeting:

Credits can be scoped to specific products using applicable_product_ids or applicable_product_tags, or left unrestricted to apply to all products.

Priority considerations:

When multiple credits are applicable, the one with the lower priority value will be consumed first. If there is a tie, contract level commits and credits will be applied before customer level commits and credits. Plan your priority scheme carefully to ensure credits are applied in the desired order.

Access Schedule Required:

You must provide an access_schedule that defines when and how much credit becomes available to the customer over time. This usually is aligned to the contract schedule or starts immediately and is set to expire in the future.

Usage Guidelines:

⚠️ Preferred Alternative: In most cases, you should add credits directly to contracts using the contract/create or contract/edit APIs instead of creating customer-level credits. Contract-level credits provide better organization, and are easier for finance teams to recognize revenue, and are the recommended approach for most use cases.

Sends a POST request to /v1/contracts/customerCredits/create

Arguments:

• body: Create a credit

pub async fn update_credit_end_date_v1<'a>( &'a self, body: &'a UpdateCreditEndDateV1Body, ) -> Result<ResponseValue<UpdateCreditEndDateV1Response>, Error<UpdateCreditEndDateV1Response>>

Update the credit end date

Shortens the end date of an existing customer credit to terminate it earlier than originally scheduled. Only allows moving end dates forward (earlier), not extending them.

Note: To extend credit end dates or make comprehensive edits, use the ‘edit credit’ endpoint instead.

Sends a POST request to /v1/contracts/customerCredits/updateEndDate

Arguments:

• body: Update the access end date of a credit

pub async fn list_customer_balances_v1<'a>( &'a self, body: &'a ListCustomerBalancesV1Body, ) -> Result<ResponseValue<ListCustomerBalancesV1Response>, Error<()>>

List balances

Retrieve a comprehensive view of all available balances (commits and credits) for a customer. This endpoint provides real-time visibility into prepaid funds, postpaid commitments, promotional credits, and other balance types that can offset usage charges, helping you build transparent billing experiences.

Use this endpoint to:

• Display current available balances in customer dashboards
• Verify available funds before approving high-usage operations
• Generate balance reports for finance teams
• Filter balances by contract or date ranges

Key response fields:

An array of balance objects (all credits and commits) containing:

• Balance details: Current available amount for each commit or credit
• Metadata: Product associations, priorities, applicable date ranges
• Optional ledger entries: Detailed transaction history (if include_ledgers=true)
• Balance calculations: Including pending transactions and future-dated entries
• Custom fields: Any additional metadata attached to balances

Usage guidelines:

• Use the getNetBalance endpoint to retrieve a single combined current balance
• Date filtering: Use effective_before to include only balances with access before a specific date (exclusive)
• Set include_balance=true for calculated balance amounts on each commit or credit
• Set include_ledgers=true for full transaction history
• Set include_contract_balances = true to see contract level balances
• Balance logic: Reflects currently accessible amounts, excluding expired/future segments
• Manual adjustments: Includes all manual ledger entries, even future-dated ones

Sends a POST request to /v1/contracts/customerBalances/list

Arguments:

• body: List all balances (commits and credits) for a customer

pub async fn get_net_balance_v1<'a>( &'a self, body: &'a GetNetBalanceV1Body, ) -> Result<ResponseValue<GetNetBalanceV1Response>, Error<GetNetBalanceV1Response>>

Get the net balance of a customer

Retrieve the combined current balance across any grouping of credits and commits for a customer in a single API call.

• Display real-time available balance to customers in billing dashboards
• Build finance dashboards showing credit utilization across customer segments
• Validate expected vs. actual balance during billing reconciliation

Key response fields:

• balance: The combined net balance available to use at this moment across all matching commits and credits
• credit_type_id: The credit type (fiat or custom pricing unit) the balance is denominated in

Filtering options:

Balance filters allow you to scope the calculation to specific subsets of commits and credits. When using multiple filter objects, they are OR’d together — if a commit or credit matches any filter, it’s included in the net balance. Within a single filter object, all specified conditions are AND’d together.

• Balance types: Include any combination of PREPAID_COMMIT, POSTPAID_COMMIT, and CREDIT (e.g., ["PREPAID_COMMIT", "CREDIT"] to exclude postpaid commits). If not specified, all balance types are included.
• Specific IDs: Target exact commit or credit IDs for precise balance queries
• Custom fields: Filter by custom field key-value pairs; when multiple pairs are provided, commits must match all of them

Example: To get the balance of all free-trial credits OR all signup-promotion commits, you’d pass two filter objects — one filtering for CREDIT with custom field campaign: free-trial, and another filtering for PREPAID_COMMIT with custom field campaign: signup-promotion.

Usage guidelines:

• Balance ledger details: Use the listBalances endpoint instead to understand detailed ledger drawdowns for each individual balance
• Draft invoice handling: Use invoice_inclusion_mode to control whether pending draft invoice deductions are included (FINALIZED_AND_DRAFT, the default) or excluded (FINALIZED) from the balance calculation
• Account hierarchies: When querying a child customer, shared commits from parent contracts are not included — query the parent customer directly to see shared commit balances
• Negative balances: Manual ledger entries can cause negative segment balances; these are treated as zero when calculating the net balance
• Credit types: If credit_type_id is not specified, the balance defaults to USD (cents)

Sends a POST request to /v1/contracts/customerBalances/getNetBalance

Arguments:

• body: Get the combined net balance for any grouping of credits and commits.

pub async fn list_seat_balances_v1<'a>( &'a self, body: &'a ListSeatBalancesV1Body, ) -> Result<ResponseValue<ListSeatBalancesV1Response>, Error<ListSeatBalancesV1Response>>

List seat balances

Retrieve detailed balance for seat-based credits and commits from the contract’s subscriptions, broken down by individual seats.

Use this endpoint to:

• Display per-seat balance information in customer dashboards
• Filter balance data by subscription or specific seats

Key response fields:

An array of seat balance objects containing:

• Seat id
• Balance: current total balance across all commits and credits

Usage guidelines:

• Date filtering: use covering_date OR starting_at/ending_before to filter balance data by time range
• Set include_credits_and_commits=true for detailed commits and credits breakdown per seat
• Set include_ledgers=true for detailed transaction history per commit/credit per seat

Sends a POST request to /v1/contracts/seatBalances/list

Arguments:

• body: List seat-level balances for commits and credits.

pub async fn schedule_pro_services_invoice_v1<'a>( &'a self, body: &'a ScheduleProServicesInvoiceV1Body, ) -> Result<ResponseValue<ScheduleProServicesInvoiceV1Response>, Error<ScheduleProServicesInvoiceV1Response>>

Schedule ProService invoice

Create a new scheduled invoice for Professional Services terms on a contract. This endpoint’s availability is dependent on your client’s configuration.

Sends a POST request to /v1/contracts/scheduleProServicesInvoice

Arguments:

• body: schedule an invoice for the specified Professional Services terms on a contract

pub async fn create_historical_contract_usage_invoices_v1<'a>( &'a self, body: &'a CreateHistoricalContractUsageInvoicesV1Body, ) -> Result<ResponseValue<CreateHistoricalContractUsageInvoicesV1Response>, Error<CreateHistoricalContractUsageInvoicesV1Response>>

Create historical invoices

Create historical usage invoices for past billing periods on specific contracts. Use this endpoint to generate retroactive invoices with custom usage line items, quantities, and date ranges. Supports preview mode to validate invoice data before creation. Ideal for billing migrations or correcting past billing periods.

Sends a POST request to /v1/contracts/createHistoricalInvoices

Arguments:

• body: Create a historical usage invoice for a contract

pub async fn create_customer_with_contract_v1<'a>( &'a self, body: &'a CreateCustomerWithContractV1Body, ) -> Result<ResponseValue<CreateCustomerWithContractV1Response>, Error<CreateCustomerWithContractV1Response>>

Create a customer and provision a contract

Create a new customer and provision a contract. This endpoint’s availability is dependent on your client’s configuration.

Sends a POST request to /v1/composite/createCustomerWithContract

Arguments:

• body: The customer and contract details to create

pub async fn get_customer_named_schedule_v1<'a>( &'a self, body: &'a GetCustomerNamedScheduleV1Body, ) -> Result<ResponseValue<GetCustomerNamedScheduleV1Response>, Error<()>>

Get a customer’s named schedule

Get a named schedule for the given customer. This endpoint’s availability is dependent on your client’s configuration.

Sends a POST request to /v1/customers/getNamedSchedule

Arguments:

• body: Which customer, schedule name, and date to retrieve.

pub async fn update_customer_named_schedule_v1<'a>( &'a self, body: &'a UpdateCustomerNamedScheduleV1Body, ) -> Result<ResponseValue<()>, Error<()>>

Update a customer’s named schedule

Update a named schedule for the given customer. This endpoint’s availability is dependent on your client’s configuration.

Sends a POST request to /v1/customers/updateNamedSchedule

Arguments:

• body: The customer, schedule name, date range, and value to set.

pub async fn get_contract_named_schedule_v1<'a>( &'a self, body: &'a GetContractNamedScheduleV1Body, ) -> Result<ResponseValue<GetContractNamedScheduleV1Response>, Error<()>>

Get a contract’s named schedule

Get a named schedule for the given contract. This endpoint’s availability is dependent on your client’s configuration.

Sends a POST request to /v1/contracts/getNamedSchedule

Arguments:

• body: Which customer, contract, schedule name, and date to retrieve.

pub async fn list_contracts_named_schedules_v1<'a>( &'a self, body: &'a ListContractsNamedSchedulesV1Body, ) -> Result<ResponseValue<ListContractsNamedSchedulesV1Response>, Error<()>>

List contract named schedules

List contract-level named schedules for a customer, optionally scoped to a single contract.

Sends a POST request to /v1/contracts/listNamedSchedules

Arguments:

• body: Specify which customer and optional filters to use when listing contract named schedules.

pub async fn update_contract_named_schedule_v1<'a>( &'a self, body: &'a UpdateContractNamedScheduleV1Body, ) -> Result<ResponseValue<()>, Error<()>>

Update a contract’s named schedule

Update a named schedule for the given contract. This endpoint’s availability is dependent on your client’s configuration.

Sends a POST request to /v1/contracts/updateNamedSchedule

Arguments:

• body: The customer, contract, schedule name, date range, and value to set.

pub async fn get_rate_card_named_schedule_v1<'a>( &'a self, body: &'a GetRateCardNamedScheduleV1Body, ) -> Result<ResponseValue<GetRateCardNamedScheduleV1Response>, Error<()>>

Get a rate card’s named schedule

Get a named schedule for the given rate card. This endpoint’s availability is dependent on your client’s configuration.

Sends a POST request to /v1/contract-pricing/rate-cards/getNamedSchedule

Arguments:

• body: Which rate card, schedule name, and date to retrieve.

pub async fn update_rate_card_named_schedule_v1<'a>( &'a self, body: &'a UpdateRateCardNamedScheduleV1Body, ) -> Result<ResponseValue<()>, Error<()>>

Update a rate card’s named schedule

Update a named schedule for the given rate card. This endpoint’s availability is dependent on your client’s configuration.

Sends a POST request to /v1/contract-pricing/rate-cards/updateNamedSchedule

Arguments:

• body: The rate card, schedule name, date range, and value to set.

pub async fn create_package_v1<'a>( &'a self, body: &'a CreatePackageV1Body, ) -> Result<ResponseValue<CreatePackageV1Response>, Error<CreatePackageV1Response>>

Create a package

Create a package that defines a set of reusable, time-relative contract terms that can be used across cohorts of customers. Packages provide an abstraction layer on top of rate cards to provide an easy way to provision customers with standard pricing.

Use this endpoint to:

• Model standard pay-as-you-go pricing packages that can be easily reused across customers
• Define standardized contract terms and discounting for sales-led motions
• Set aliases for the package to facilitate easy package transition. Aliases are human-readable names that you can use in the place of the id of the package when provisioning a customer’s contract. By using an alias, you can easily create a contract and provision a customer by choosing the “Starter Plan” package, without storing the package ID in your internal systems. This is helpful when launching terms for a package, as you can create a new package with the “Starter Plan” alias scheduled to be assigned without updating your provisioning code.

Key input fields:

• starting_at_offset: Starting date relative to contract start. Generates the starting_at date when a contract is provisioned using a package.
• duration: Duration starting from starting_at_offset. Generates the ending_before date when a contract is provisioned using a package.
• date_offset: Date relative to contract start. Used for point-in-time dates without a duration.
• aliases: Human-readable name to use when provisioning contracts with a package.

Usage guidelines:

• Use packages for standard self-serve use cases where customers have consistent terms. For customers with negotiated custom contract terms, use the createContract endpoint for maximum flexibility.
• Billing provider configuration can be set when creating a package by using billing_provider and delivery_method. To provision a customer successfully with a package, the customer must have one and only one billing provider configuration that matches the billing provider configuration set on the package.
• A package alias can only be used by one package at a time. If you create a new package with an alias that is already in use by another package, the original package’s alias schedule will be updated. The alias will reference the package to which it was most recently assigned.
• Terms can only be specified using times relative to the contract start date. Supported granularities are: days, weeks, months, years
• Packages cannot be edited once created. Use the rate card to easily add new rates across all of your customers or make direct edits to a contract after provisioning with a package. Edited contracts will still be associated with the package used during provisioning.

Sends a POST request to /v1/packages/create

Arguments:

• body: Create a new package

pub async fn get_package_v1<'a>( &'a self, body: &'a GetPackageV1Body, ) -> Result<ResponseValue<GetPackageV1Response>, Error<GetPackageV1Response>>

Get a package

Gets the details for a specific package, including name, aliases, duration, and terms. Use this endpoint to understand a package’s alias schedule, or display a specific package’s details to end customers.

Sends a POST request to /v1/packages/get

Arguments:

• body: Package ID

pub async fn list_packages_v1<'a>( &'a self, limit: Option<NonZeroU64>, next_page: Option<&'a str>, body: &'a ListPackagesV1Body, ) -> Result<ResponseValue<ListPackagesV1Response>, Error<()>>

List all packages

Lists all packages with details including name, aliases, duration, and terms. To view contracts on a specific package, use the listContractsOnPackage endpoint.

Sends a POST request to /v1/packages/list

Arguments:

• limit: The maximum number of packages to return. Defaults to 10.
• next_page: Cursor that indicates where the next page of results should start.
• body

pub async fn archive_package_v1<'a>( &'a self, body: &'a ArchivePackageV1Body, ) -> Result<ResponseValue<ArchivePackageV1Response>, Error<ArchivePackageV1Response>>

Archive a package

Archive a package. Archived packages cannot be used to create new contracts. However, existing contracts associated with the package will continue to function as normal. Once you archive a package, you can still retrieve it in the UI and API, but you cannot unarchive it.

Sends a POST request to /v1/packages/archive

pub async fn list_contracts_on_package_v1<'a>( &'a self, limit: Option<NonZeroU64>, next_page: Option<&'a str>, body: &'a ListContractsOnPackageV1Body, ) -> Result<ResponseValue<ListContractsOnPackageV1Response>, Error<ListContractsOnPackageV1Response>>

List contracts associated with a package

For a given package, returns all contract IDs and customer IDs associated with the package over a specific time period.

Use this endpoint to:

• Understand which customers are provisioned on a package at any given time for internal cohort management
• Manage customer migrations to a new package. For example, to migrate all active customers to a new package, call this endpoint, end contracts, and provision customers on a new package.

Usage guidelines:

Use the starting_at, covering_date, and include_archived parameters to filter the list of returned contracts. For example, to list only currently active contracts, pass covering_date equal to the current time.

Sends a POST request to /v1/packages/listContractsOnPackage

Arguments:

• limit: Max number of results that should be returned
• next_page: Cursor that indicates where the next page of results should start.
• body: Package ID and optional filters

pub async fn get_contract_v2<'a>( &'a self, body: &'a GetContractV2Body, ) -> Result<ResponseValue<GetContractV2Response>, Error<GetContractV2Response>>

Get a contract (v2)

Gets the details for a specific contract, including contract term, rate card information, credits and commits, and more.

Use this endpoint to:

• Check the duration of a customer’s current contract
• Get details on contract terms, including access schedule amounts for commitments and credits
• Understand the state of a contract at a past time. As you can evolve the terms of a contract over time through editing, use the as_of_date parameter to view the full contract configuration as of that point in time.

Usage guidelines:

• Optionally, use the include_balance and include_ledger fields to include balances and ledgers in the credit and commit responses. Using these fields will cause the query to be slower.

Sends a POST request to /v2/contracts/get

Arguments:

• body: Contract and customer IDs

pub async fn get_contract_edit_history_v2<'a>( &'a self, body: &'a GetContractEditHistoryV2Body, ) -> Result<ResponseValue<GetContractEditHistoryV2Response>, Error<GetContractEditHistoryV2Response>>

Get contract edit history

List all the edits made to a contract over time. In Metronome, you can edit a contract at any point after it’s created to fix mistakes or reflect changes in terms. Metronome stores a full history of all edits that were ever made to a contract, whether through the UI, editContract endpoint, or other endpoints like updateContractEndDate.

Use this endpoint to:

• Understand what changes were made to a contract, when, and by who

Key response fields:

• An array of every edit ever made to the contract
• Details on each individual edit - for example showing that in one edit, a user added two discounts and incremented a subscription quantity.

Sends a POST request to /v2/contracts/getEditHistory

Arguments:

• body: Contract ID

pub async fn list_contracts_v2<'a>( &'a self, body: &'a ListContractsV2Body, ) -> Result<ResponseValue<ListContractsV2Response>, Error<ListContractsV2Response>>

List customer contracts (v2)

For a given customer, lists all of their contracts in chronological order.

Use this endpoint to:

• Check if a customer is provisioned with any contract, and at which tier
• Check the duration and terms of a customer’s current contract
• Power a page in your end customer experience that shows the customer’s history of tiers (e.g. this customer started out on the Pro Plan, then downgraded to the Starter plan).

Usage guidelines:

Use the starting_at, covering_date, and include_archived parameters to filter the list of returned contracts. For example, to list only currently active contracts, pass covering_date equal to the current time.

Sends a POST request to /v2/contracts/list

Arguments:

• body: Customer ID and optional filters

pub async fn edit_contract_v2<'a>( &'a self, body: &'a EditContractV2Body, ) -> Result<ResponseValue<EditContractV2Response>, Error<EditContractV2Response>>

Edit a contract

The ability to edit a contract helps you react quickly to the needs of your customers and your business.

Use this endpoint to:

• Encode mid-term commitment and discount changes
• Fix configuration mistakes and easily roll back packaging changes

Key response fields:

• The id of the edit
• Complete edit details. For example, if you edited the contract to add new overrides and credits, you will receive the IDs of those overrides and credits in the response.

Usage guidelines:

• When you edit a contract, any draft invoices update immediately to reflect that edit. Finalized invoices remain unchanged - you must void and regenerate them in the UI or API to reflect the edit.
• Contract editing must be enabled to use this endpoint. Reach out to your Metronome representative to learn more.

Sends a POST request to /v2/contracts/edit

Arguments:

• body: Contract and customer IDs and fields to update

pub async fn edit_commit_v2<'a>( &'a self, body: &'a EditCommitV2Body, ) -> Result<ResponseValue<EditCommitV2Response>, Error<EditCommitV2Response>>

Edit a commit

Edit specific details for a contract-level or customer-level commit. Use this endpoint to modify individual commit access schedules, invoice schedules, applicable products, invoicing contracts, or other fields.

Usage guidelines:

• As with all edits in Metronome, draft invoices will reflect the edit immediately, while finalized invoices are untouched unless voided and regenerated.
• If a commit’s invoice schedule item is associated with a finalized invoice, you cannot remove or update the invoice schedule item.
• If a commit’s invoice schedule item is associated with a voided invoice, you cannot remove the invoice schedule item.
• You cannot remove an commit access schedule segment that was applied to a finalized invoice. You can void the invoice beforehand and then remove the access schedule segment.

Sends a POST request to /v2/contracts/commits/edit

Arguments:

• body: Commit and customer IDs and fields to update

pub async fn edit_credit_v2<'a>( &'a self, body: &'a EditCreditV2Body, ) -> Result<ResponseValue<EditCreditV2Response>, Error<EditCreditV2Response>>

Edit a credit

Edit details for a contract-level or customer-level credit.

Use this endpoint to:

• Extend the duration or the amount of an existing free credit like a trial
• Modify individual credit access schedules, applicable products, priority, or other fields.

Usage guidelines:

• As with all edits in Metronome, draft invoices will reflect the edit immediately, while finalized invoices are untouched unless voided and regenerated.
• You cannot remove an access schedule segment that was applied to a finalized invoice. You can void the invoice beforehand and then remove the access schedule segment.

Sends a POST request to /v2/contracts/credits/edit

Arguments:

• body: Credit and customer IDs and fields to update

pub async fn archive_commit_v2<'a>( &'a self, body: &'a ArchiveCommitV2Body, ) -> Result<ResponseValue<ArchiveCommitV2Response>, Error<ArchiveCommitV2Response>>

Archive a commit

Archive a contract-level or customer-level commit. Use this endpoint to deactivate a commit while preserving historical records. You will not be able to archive a commit until all of the finalized usage invoices the commit has been applied to are voided, and all of the finalized invoices for commit payment have been voided.

Example workflow: The customer was provisioned a prepaid commit erroneously. It was applied to their most recent finalized usage invoice.

• First, void the finalized invoice that the commit was applied to. Also, void the finalized invoice associated with the commit payment.
• Then, use the archiveCommit endpoint to deactivate the commit.
• Finally, regenerate the voided invoice. The invoice will be regenerated without the application of the commit, which has now been archived.

Usage guidelines:

• Once a commit has been archived, it will no longer appear by default on the endpoints listCustomerCommits or listCustomerBalances. Use the include_archived parameter to choose to fetch the details.
• Once a commit has been archived, it has a null ledger and 0 remaining balance.
• Archiving a commit fully deactivates the entire access schedule. If you want to reduce the amount granted in a commit, consider editing the access schedule using the editCommit endpoint, or adding a manual ledger entry using the addManualBalanceLedgerEntry endpoint.

Sends a POST request to /v2/contracts/commits/archive

Arguments:

• body: Customer ID and Commit ID to archive

pub async fn archive_credit_v2<'a>( &'a self, body: &'a ArchiveCreditV2Body, ) -> Result<ResponseValue<ArchiveCreditV2Response>, Error<ArchiveCreditV2Response>>

Archive a credit

Archive a contract-level or customer-level credit. Use this endpoint to deactivate a credit while preserving historical records. You will not be able to archive a credit until all of the finalized invoices the credit has been applied to are voided.

Example workflow: The customer was granted a free credit erroneously. It was applied to their most recent finalized invoice.

• First, void the finalized invoice that the credit was applied to.
• Then, use the archiveCredit endpoint to deactivate the credit.
• Finally, regenerate the voided invoice. The invoice will be regenerated without the application of the credit, which has now been archived.

Usage guidelines:

• Once a credit has been archived, it will no longer appear by default on the endpoints listCustomerCredits or listCustomerBalances. Use the include_archived parameter to choose to fetch the details.
• Once a credit has been archived, it has a null ledger and 0 remaining balance.
• Archiving a credit fully deactivates the entire access schedule. If you want to reduce the amount granted in a credit, consider editing the access schedule using the editCredit endpoint, or adding a manual ledger entry using the addManualBalanceLedgerEntry endpoint.

Sends a POST request to /v2/contracts/credits/archive

Arguments:

• body: Customer ID and Credit ID to archive

pub async fn create_notification_config_v2<'a>( &'a self, body: &'a CreateNotificationConfigV2Body, ) -> Result<ResponseValue<CreateNotificationConfigV2Response>, Error<CreateNotificationConfigV2Response>>

Create an offset lifecycle event notification configuration

Create an offset lifecycle event notification configuration. The lifecycle event type is inferred from the policy.type field.

Sends a POST request to /v2/notifications/create

Arguments:

• body: Notification configuration details

pub async fn get_notification_config_v2<'a>( &'a self, body: &'a GetNotificationConfigV2Body, ) -> Result<ResponseValue<GetNotificationConfigV2Response>, Error<GetNotificationConfigV2Response>>

Get an offset lifecycle event notification configuration

Retrieve a specific offset lifecycle event notification configuration by ID.

Sends a POST request to /v2/notifications/get

Arguments:

• body: Offset notification configuration ID

pub async fn list_offset_notification_configs_v2<'a>( &'a self, body: &'a ListOffsetNotificationConfigsV2Body, ) -> Result<ResponseValue<ListOffsetNotificationConfigsV2Response>, Error<()>>

List offset lifecycle event notification configurations

List offset lifecycle event notification configurations. These are user-created notifications that trigger at a specified time offset relative to lifecycle events. Returns a maximum of 400 results per request.

Sends a POST request to /v2/notifications/offset/list

Arguments:

• body: Optional pagination and filtering parameters

pub async fn list_system_notification_configs_v2<'a>( &'a self, ) -> Result<ResponseValue<ListSystemNotificationConfigsV2Response>, Error<()>>

List system notification event types

List available system lifecycle event types for notifications. These are read-only event types that can be used when creating offset notifications.

Sends a POST request to /v2/notifications/system/list

pub async fn edit_notification_config_v2<'a>( &'a self, body: &'a EditNotificationConfigV2Body, ) -> Result<ResponseValue<EditNotificationConfigV2Response>, Error<EditNotificationConfigV2Response>>

Edit an offset lifecycle event notification configuration

Edit an existing offset lifecycle event notification configuration.

Sends a POST request to /v2/notifications/edit

Arguments:

• body: Offset notification configuration updates

pub async fn archive_notification_config_v2<'a>( &'a self, body: &'a ArchiveNotificationConfigV2Body, ) -> Result<ResponseValue<ArchiveNotificationConfigV2Response>, Error<ArchiveNotificationConfigV2Response>>

Archive an offset lifecycle event notification configuration

Archive an offset lifecycle event notification configuration. Archived notifications are not processed.

Sends a POST request to /v2/notifications/archive

Arguments:

• body: Offset notification configuration ID to archive

Trait Implementations

impl ClientHooks for &Client

async fn pre<E>( &self, request: &mut Request, info: &OperationInfo, ) -> Result<(), Error<E>>

Runs prior to the execution of the request. This may be used to modify the request before it is transmitted.

async fn post<E>( &self, result: &Result<Response, Error>, info: &OperationInfo, ) -> Result<(), Error<E>>

Runs after completion of the request.

async fn exec( &self, request: Request, info: &OperationInfo, ) -> Result<Response, Error>

Execute the request. Note that for almost any reasonable implementation this will include code equivalent to this:

impl ClientInfo<()> for Client

fn api_version() -> &'static str

Get the version of this API.

fn baseurl(&self) -> &str

Get the base URL to which requests are made.

fn client(&self) -> &Client

Get the internal reqwest::Client used to make requests.

fn inner(&self) -> &()

Get the inner value of type T if one is specified.

impl Clone for Client

fn clone(&self) -> Client

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Client

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.