Offline Data Transfer
Offline transfer is how you send Athia data you already hold, on a schedule you control. It covers both the one-time historical backfill and the recurrent feed, and the two use the same path and the same specification.
There are two shapes, and the right one is whichever matches where your payments data already lives.
| Files | Warehouse or data lake | |
|---|---|---|
| What it is | You export files and deliver them to SFTP or S3 | You grant read access to named tables or views and Athia reads them |
| Who owns it | Your data team | Your warehouse admin |
| Best when | You have no warehouse, or payments data is not modelled in it | You already model payments in Snowflake, Databricks, BigQuery or Redshift |
| Effort per change | A change to the export job | A change to a view |
| Freshness | Per delivery, daily is typical | Per read, on an agreed cadence |
| Backfill | The same export, run once over history | Comes from the same grant, so there is no separate backfill to arrange |
If you already model payments in a warehouse or lake, that path is usually the least work for the most complete data: the joins between attempts, settlement, fees and disputes are already done, and history and the recurrent feed come from the same grant.
Offline against real time
Offline transfer is not the only way to get data into Athia, and the choice is about freshness rather than preference.
- Offline transfer, this page. Data arrives on the schedule you set. Right for history, for settlement and cost data that is produced in batches anyway, and for any feed where minutes do not matter.
- Provider connectors, where Athia polls your payment, anti-fraud and cost providers directly, or receives their webhooks. Closer to real time for transactional data, but bounded by what each provider actually produces and when.
- DEUNA orchestration, where the data exists as a by-product of processing and nothing has to be sent at all.
These combine. Athia deduplicates across them, so using more than one sharpens the answers rather than creating conflicts. A common shape is a warehouse grant for history and modelled data, plus connectors for the providers your warehouse does not cover.
What Athia does with every delivery
Whichever shape you choose, Athia validates what arrives against the mapping agreed for your account rather than against fixed column names, and returns a report naming rejected rows, missing required fields and type mismatches. You correct the export before the next run.
You do not need to rename your columns. Your Athia team maps them on ingest. The field specification is in Athia Data Dictionary.
Related
- Files (SFTP or S3), formats, naming, delivery and the validation loop.
- Warehouse to Warehouse, grants, change detection and what it costs.
- Integrating Athia, all the paths, and how much history to send.
Updated about 23 hours ago