Skip to main content
Image
The Snowflake integration lets Vayu ingest usage data from Snowflake so that usage-based billing can be calculated inside Vayu. In this setup, Snowflake acts as the system where usage events are stored, while Vayu acts as the billing layer that reads, accepts, and processes that usage data. This integration replaces the legacy ERP Imports workflow. In practical terms, the integration is designed for teams that already collect usage data in a Snowflake data warehouse and want to use that data for billing and revenue operations. Rather than forcing teams to move their operational usage data into a separate system first, Vayu works with Snowflake as the source of truth and supports multiple ingestion paths depending on how much control the customer wants over timing, transformation, and delivery. This page explains how the Snowflake integration works, what data Vayu expects, and how to prepare a Snowflake environment for ingestion. It is useful both for teams that want Vayu to pull usage from Snowflake directly and for teams that prefer to push usage records into Vayu through the API.

How The Snowflake Integration Works

Snowflake is commonly used to store structured operational and analytical data, including product usage events, transaction logs, and billing-related measurements. The Snowflake integration allows Vayu to use that data as the basis for billing calculations without requiring Snowflake to stop serving as the customer’s warehouse of record. Vayu supports two ingestion models for Snowflake data. In the pull model, Vayu connects to Snowflake and reads usage records from a configured table or view. In the push model, the customer sends usage records from Snowflake to Vayu by calling the Usage Ingestion API.

Pull Model

In the pull model, usage events remain in Snowflake and Vayu connects using configured credentials. Vayu reads from a designated table or view at scheduled intervals and processes the data for billing. This model works best when Snowflake already serves as the central warehouse for metering data and a stable dataset is available for ingestion. To set it up, identify the table or view that should act as the billing source. Ensure the dataset contains one row per usage record and that column names and data types remain consistent over time. Then create or assign a Snowflake user or service account for Vayu. Grant USAGE on the relevant database and schema, and SELECT on the target table or view. Limit permissions to only what the integration requires.

Push Model

In the push model, the customer sends usage records from Snowflake to Vayu through the Usage Ingestion API. This typically runs through scheduled jobs, pipelines, or other orchestration layers. It is useful when you need control over when data is sent, how it is transformed, or how records are grouped before delivery. To set it up, extract the required usage records from Snowflake, transform them into the expected format if needed, and send them to Vayu’s ingestion endpoint. Monitor the pipeline to catch failed submissions, schema mismatches, or missing fields.

Data Requirements

For either ingestion model, Snowflake must contain structured usage records that match the schema Vayu expects. The exact source can be a table or a view, but the data should be stable, consistently typed, and suitable for repeated ingestion. At a minimum, each usage record should identify the customer or account, identify the metric or event being measured, include the usage quantity, and include a timestamp. Depending on the billing model, customers may also include related entity identifiers, contract references, or custom metadata that help enrich the billing context. Because Vayu uses this data for billing calculations, consistency matters as much as completeness. A table or view with inconsistent data types, missing identifiers, or irregular timestamp formats may ingest unpredictably or require additional transformation before it can be used safely.

Prepare The Snowflake Source

Before enabling the integration, prepare a Snowflake table or view for billing ingestion. A dedicated view is often preferred, as it allows you to normalize source data and expose only the fields required for billing. Each row should represent a single usage record, with stable column names and consistent data types. If your upstream pipeline produces multiple datasets or complex transformations, consolidate that logic before ingestion so Vayu reads from a clean, predictable source. Start by identifying or creating the table or view that will act as the usage source. Confirm that required billing fields are present and that records follow a consistent structure. If needed, create a dedicated view to handle transformation and field mapping within Snowflake rather than during ingestion.

Grant Access For The Pull Model

If you plan to use the pull model, Vayu must be able to connect to Snowflake and read from the selected source. This requires a Snowflake identity with the correct access to the target database, schema, and table or view. In most cases, a service account is the safest approach because it gives the integration a dedicated identity that can be managed separately from individual user accounts. That also makes auditing and permission control easier over time. Create or assign the Snowflake user or service account that Vayu will use. Grant USAGE on the target database and schema. Grant SELECT on the usage table or view. Review the permissions once they are in place and remove anything that is broader than the integration actually needs.

Next Steps

Once the Snowflake source is prepared, the next step is to configure the integration in Vayu according to the ingestion model you plan to use. For pull-based setups, connect Vayu to Snowflake and point it to the correct table or view. For push-based setups, prepare the process that sends usage records to the Usage Ingestion API. After the connection and source setup are complete, validate the ingestion flow with sample usage data before relying on it for production billing. This makes it easier to catch schema mismatches, missing fields, or permission issues before they affect invoices or revenue reporting.