Data Warehouse Connector

At a certain scale, the dashboard inside any platform stops being enough. Your analyst wants the raw data in the warehouse next to everything else your business runs on. Your finance team wants the conversion and payout data joined against the chart of accounts. Your data scientist wants the events in the same table store as the rest of the customer data, ready to join, transform, and model.

Routy's data warehouse connector pushes your data directly into your own database — Postgres or SQL Server — continuously, so the warehouse stays current with what's in Routy. No middle layer, no Zapier-style integration tax, no "we'll run a scheduled job once a week" workaround. The warehouse becomes a live copy of the data your team needs.

After configuring the connector, the following becomes available:

• Direct sync into your own warehouse — PostgreSQL or Microsoft SQL Server. The connection is direct from Routy to your database; nothing else sits in the path.
• Continuous updates so the data in your warehouse stays current. New events flow into the warehouse on a continuous schedule (typically several times an hour), so the time between an event firing in Routy and being available in your warehouse is short.
• All your tracking data — clicks, conversions, accounts, traffic sources, payouts, link metadata, affiliate data — modelled into tables and ready to join with the rest of your warehouse. The schema is documented and stable; it doesn't change without notice.
• Encrypted credentials stored securely. Passwords for the database connection are never returned in plain text once stored. Credential rotation can be done through the connector configuration without losing the sync history.
• Idempotent writes — events are upserted based on their event IDs, so retries from transient failures don't produce duplicates. The warehouse is a clean copy of what's in Routy, not a noisy log of every write attempt.

The data model in your warehouse mirrors Routy's internal schema closely. Each event type has a table, each dimensional entity (affiliate, traffic source, link, programme) has a corresponding table, and the foreign-key relationships are preserved. SQL queries that join across the tables in your warehouse work the same way they'd work if Routy's own database were directly accessible.

You add a connector with your database host, port, credentials, and engine type (Postgres or SQL Server). Routy tests the connection, confirms it has the right permissions, and runs the schema migrations needed to create the destination tables. The initial backfill of historical data happens once, after which incremental syncs run continuously.

A few practical notes:

• One active connector per account keeps the system simple. If you have multiple warehouses you want to sync to, the simplest approach is replicating between warehouses at the database layer rather than running multiple Routy connectors.
• Schema changes on Routy's side that affect the destination tables are versioned and rolled out with advance notice, so your warehouse stays compatible.
• The connector writes to dedicated tables in a schema you configure. Routy doesn't write to other schemas in your database, so the warehouse is safe to share with other data sources.
• Network reachability: the connector needs to reach your database from Routy's infrastructure. For databases behind a VPN or private network, IP allowlisting Routy's outbound IPs is the standard approach. For databases that aren't reachable from the public internet at all, the sync isn't currently supported.

The case for the warehouse connector is mostly about reaching a scale where your data needs to live next to the rest of your business's data. For small operations, the Routy dashboard plus the report builder plus the data export feature cover everything you'd realistically do. The warehouse connector becomes important when:

• You have a data analyst or scientist who wants to join Routy data against customer, financial, or product data in one place.
• You're running internal models (fraud detection, predictive LTV, audience scoring) that need the raw event stream as input.
• Your BI tool of choice (Looker, Tableau, Power BI) reads from your warehouse and you want Routy data available through the same interface as everything else.
• Compliance, audit, or governance requires the data to live in infrastructure you control.

For accounts hitting any of those, the warehouse connector is the right way to integrate Routy into the broader data stack. It's not the right feature for accounts that aren't yet at that scale — for those, the data export feature is the lighter-weight equivalent.

The competitive case against alternatives (manual CSV export, Zapier-style middleware, building a custom integration) is mostly about reliability and recency. Manual exports are stale by definition. Middleware adds another failure mode and another vendor relationship. Custom integrations need maintenance. The first-party connector is the path that doesn't break.