public-data-docs

❄️ Snowflake Data Inventory

📌 Notes & Conventions

Timestamps are stored in UTC unless otherwise specified.
Nullability: Most fields are nullable unless explicitly noted.
Field Naming Conventions: Snake_case is used across all fields.
Refresh Frequency: Most tables will be updated every 2 hours.
Enum Fields: For each enum field there is a companion column with _name appended to the name holding the string representation of the enum (e.g. state → state_name).
Per-tenant share: Each customer connects to their own schema ({Tenant ID}_CORE), which is already filtered to that tenant. The tables therefore do not contain a tenant_id column.

How to Access Data

There are currently two options to get access to the data. Depending on needs and use-case one of the options is activated by Data Engineering Team.

Wunder will create a Snowflake share, customer will see the shared database in Snowflake UI/Snowpipe in Data Products → Private Sharing.

Direct Access with external Tools

⚠️ Network Level Security

We are using Network Level Policies to restrict access to Snowflake, with that access method, to have an additional layer of security to protect data of our customers. We would need the public IPs, which you will use to connect to Snowflake. This will typically be something like IPs of the Office, Data Center (where they generate the reports), VPN outbreak, …

There are plenty of tools/drivers available which can connect to Snowflake.

You will receive Tenant ID and Password through Wunder Support or an direct communication channel.

The following is a list of options on how to configure it:

Option	Value
Host	`GZNXIDS-WUNDER.snowflakecomputing.com`
Authentication	Username & Password
User	`TENANT_{Tenant ID}`
Password	You will receive that.
Role	`TENANT_{Tenant ID}`
Database	`PRO_DATA_SHARING`
Schema	`{Tenant ID}_CORE`
Warehouse	`TENANT_{Tenant ID}`

Audit tables (`_aud`)

Some tables track field-level change history via Hibernate Envers audit tables, named <table>_aud — one row per revision of the source row (whenever any tracked field changes), in addition to the current-state table. Today the only one exposed in the customer share is vehicles_aud, alongside its companion revision registry revinfo.

The most common mistake: <table>_aud.created_at is not the timestamp of the audit row — it’s copied from the row’s original creation time and stays frozen across every revision. To find out when a specific revision actually happened, join to revinfo on rev and read revinfo.revtstmp (epoch milliseconds):

SELECT a.*, TO_TIMESTAMP(r.revtstmp, 3) AS revision_at
FROM vehicles_aud a
JOIN revinfo r ON a.rev = r.rev
ORDER BY r.revtstmp DESC;

Always order an audit-table timeline by rev (monotonic), never by created_at. See vehicles_aud for the full column reference and a worked example.

Recently removed tables

The following tables were removed from the customer share in August 2026. All three contained zero rows for every operator — they were never populated, so no data is lost:

Table	Reason
`branch_areas`	Never written by the platform.
`voucher_uses`	Deprecated at source since 2020-06-19; superseded by `vouchers` and `rentals_vouchers`.
`payment_history`	Never written by the platform; use `payments` and `payment_attempts`.