ingestr 0.9.2__tar.gz → 0.9.4__tar.gz

{ingestr-0.9.2 → ingestr-0.9.4}/.gitignore

@@ -15,3 +15,4 @@ docs/.vitepress/dist
 docs/.vitepress/cache
 node_modules
 *.duckdb
+*.db

ingestr-0.9.4/.vale.ini

@@ -0,0 +1,16 @@
+StylesPath = styles
+
+MinAlertLevel = suggestion
+
+Packages = Google
+
+Vocab = bruin
+
+
+[*]
+BasedOnStyles = Vale, Google, bruin
+Google.We = NO
+Google.Passive = NO
+Google.Will = NO
+Google.Latin = NO
+Google.Contractions = NO

{ingestr-0.9.2 → ingestr-0.9.4}/Dockerfile

@@ -28,10 +28,10 @@ ENV VIRTUAL_ENV=/usr/local
 ADD --chmod=755 https://astral.sh/uv/install.sh /install.sh
 RUN /install.sh && rm /install.sh
 
-RUN /root/.cargo/bin/uv pip install --system --no-cache -r requirements.txt
+RUN $HOME/.local/bin/uv pip install --system --no-cache -r requirements.txt
 
 COPY . /app
 
-RUN pip3 install -e .
+RUN pip3 install -e . && pip3 install pyodbc
 
 ENTRYPOINT ["ingestr"]

{ingestr-0.9.2 → ingestr-0.9.4}/Makefile

@@ -30,6 +30,9 @@ lint-ci:
 lint: venv
 	. venv/bin/activate; $(MAKE) lint-ci
 
+lint-docs:
+	vale docs --glob='!**/.vitepress/**'
+
 tl: test lint
 
 build:

{ingestr-0.9.2 → ingestr-0.9.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.3
 Name: ingestr
-Version: 0.9.2
+Version: 0.9.4
 Summary: ingestr is a command-line application that ingests data from various sources and stores them in any database.
 Project-URL: Homepage, https://github.com/bruin-data/ingestr
 Project-URL: Issues, https://github.com/bruin-data/ingestr/issues
@@ -51,7 +51,7 @@ Description-Content-Type: text/markdown
 
 <div align="center">
     <img src="https://github.com/bruin-data/ingestr/blob/main/resources/ingestr.svg?raw=true" width="500" />
-    <p>Ingest & copy data from any source to any destination without any code</p>
+    <p>Copy data from any source to any destination without any code</p>
     <img src="https://github.com/bruin-data/ingestr/blob/main/resources/demo.gif?raw=true" width="750" />
 </div>
 
@@ -63,7 +63,7 @@ Description-Content-Type: text/markdown
 
 ---
 
-Ingestr is a command-line application that allows you to ingest data from any source into any destination using simple command-line flags, no code necessary.
+ingestr is a command-line app that allows you to ingest data from any source into any destination using simple command-line flags, no code necessary.
 
 - ✨ copy data from your database into any destination
 - ➕ incremental loading: `append`, `merge` or `delete+insert`
@@ -89,10 +89,10 @@ ingestr ingest \
 
 That's it.
 
-This command will:
+This command:
 
-- get the table `public.some_data` from the Postgres instance.
-- upload this data to your BigQuery warehouse under the schema `ingestr` and table `some_data`.
+- gets the table `public.some_data` from the Postgres instance.
+- uploads this data to your BigQuery warehouse under the schema `ingestr` and table `some_data`.
 
 ## Documentation
 
@@ -102,7 +102,7 @@ You can see the full documentation [here](https://bruin-data.github.io/ingestr/g
 
 Join our Slack community [here](https://join.slack.com/t/bruindatacommunity/shared_invite/zt-2dl2i8foy-bVsuMUauHeN9M2laVm3ZVg).
 
-## Supported Sources & Destinations
+## Supported sources & destinations
 
 <table>
     <tr>
@@ -256,7 +256,7 @@ Join our Slack community [here](https://join.slack.com/t/bruindatacommunity/shar
     </tr>
 </table>
 
-More to come soon!
+Feel free to create an issue if you'd like to see support for another source or destination.
 
 ## Acknowledgements
 

{ingestr-0.9.2 → ingestr-0.9.4}/README.md

@@ -1,6 +1,6 @@
 <div align="center">
     <img src="https://github.com/bruin-data/ingestr/blob/main/resources/ingestr.svg?raw=true" width="500" />
-    <p>Ingest & copy data from any source to any destination without any code</p>
+    <p>Copy data from any source to any destination without any code</p>
     <img src="https://github.com/bruin-data/ingestr/blob/main/resources/demo.gif?raw=true" width="750" />
 </div>
 
@@ -12,7 +12,7 @@
 
 ---
 
-Ingestr is a command-line application that allows you to ingest data from any source into any destination using simple command-line flags, no code necessary.
+ingestr is a command-line app that allows you to ingest data from any source into any destination using simple command-line flags, no code necessary.
 
 - ✨ copy data from your database into any destination
 - ➕ incremental loading: `append`, `merge` or `delete+insert`
@@ -38,10 +38,10 @@ ingestr ingest \
 
 That's it.
 
-This command will:
+This command:
 
-- get the table `public.some_data` from the Postgres instance.
-- upload this data to your BigQuery warehouse under the schema `ingestr` and table `some_data`.
+- gets the table `public.some_data` from the Postgres instance.
+- uploads this data to your BigQuery warehouse under the schema `ingestr` and table `some_data`.
 
 ## Documentation
 
@@ -51,7 +51,7 @@ You can see the full documentation [here](https://bruin-data.github.io/ingestr/g
 
 Join our Slack community [here](https://join.slack.com/t/bruindatacommunity/shared_invite/zt-2dl2i8foy-bVsuMUauHeN9M2laVm3ZVg).
 
-## Supported Sources & Destinations
+## Supported sources & destinations
 
 <table>
     <tr>
@@ -205,7 +205,7 @@ Join our Slack community [here](https://join.slack.com/t/bruindatacommunity/shar
     </tr>
 </table>
 
-More to come soon!
+Feel free to create an issue if you'd like to see support for another source or destination.
 
 ## Acknowledgements
 

ingestr-0.9.4/docs/commands/example-uris.md

@@ -0,0 +1,5 @@
+# `ingestr example-uris`
+
+This command serves as a guide for the user to understand the various URI formats that `ingestr` supports. The command provides a list of supported sources and destinations, along with the URI format for each of them.
+
+For the detailed documentation, please refer to the Sources & Destinations section on the sidebar.

{ingestr-0.9.2 → ingestr-0.9.4}/docs/commands/ingest.md

@@ -1,6 +1,6 @@
 # `ingestr ingest`
 
-The `ingest` command is a core functionality of the `ingestr` tool, allowing users to transfer data from a source to a destination with optional support for incremental updates.
+The `ingest` command is a core feature of the `ingestr` tool, allowing users to transfer data from a source to a destination with optional support for incremental updates.
 
 ## Example
 
@@ -13,13 +13,13 @@ ingestr ingest
    --dest-uri '<your-destination-uri-here>'
 ```
 
-## Required Options
+## Required flags
 
-- `--source-uri TEXT`: Specifies the URI of the data source. This parameter is required.
-- `--dest-uri TEXT`: Specifies the URI of the destination where data will be ingested. This parameter is required.
-- `--source-table TEXT`: Defines the source table to fetch data from. This parameter is required.
+- `--source-uri TEXT`: Required. Specifies the URI of the data source.
+- `--dest-uri TEXT`: Required. Specifies the URI of the destination where data will be ingested.
+- `--source-table TEXT`: Required. Defines the source table to fetch data from.
 
-## Optional Options
+## Optional flags
 
 - `--dest-table TEXT`: Designates the destination table to save the data. If not specified, defaults to the value of `--source-table`.
 - `--incremental-key TEXT`: Identifies the key used for incremental data strategies. Defaults to `None`.
@@ -38,7 +38,7 @@ The `interval-start` and `interval-end` options support various datetime formats
 > [!INFO]
 > For the details around the incremental key and the various strategies, please refer to the [Incremental Loading](../getting-started/incremental-loading.md) section.
 
-## General Options
+## General flags
 
 - `--help`: Displays the help message and exits the command.
 

{ingestr-0.9.2 → ingestr-0.9.4}/docs/getting-started/core-concepts.md

@@ -5,8 +5,8 @@ outline: deep
 # Core Concepts
 ingestr has a few simple concepts that you should understand before you start using it.
 
-## Source & Destination URIs
-The source and destination are the two main components of ingestr. The source is the place from where you want to ingest the data, hence the name "source", and the destination is the place where you want to store the data.
+## Source & destination URIs
+The source and destination are the two main components of ingestr. The source is the place from where you want to ingest the data, hence the name "source" and the destination is the place where you want to store the data.
 
 The sources and destinations are identified with [URIs](https://en.wikipedia.org/wiki/Uniform_Resource_Identifier). A URI is a simple string that contains the credentials used to connect to the source or destination.
 
@@ -27,13 +27,13 @@ ingestr can connect to any source or destination using this structure across all
 > [!NOTE]
 > ingestr uses [dlt](https://github.com/dlt-hub/dlt) & [SQLAlchemy](https://www.sqlalchemy.org/) libraries internally, which means you can get connection URIs by following their documentation as well, they are supposed to work right away in ingestr.
 
-## Source & Destination Tables
+## Source & destination tables
 The source and destination tables are the tables from the source and destination databases, respectively. The source table is the table from where you want to ingest the data from, and the destination table is the table where you want to store the data.
 
 ingestr uses the `--source-table` and `--dest-table` flags to specify the source and destination tables, respectively. The `--dest-table` is optional, if you don't specify it, ingestr will use the same table name as the source table.
 
 
-## Incremental Loading
+## Incremental loading
 ingestr supports incremental loading, which means you can choose to append, merge or delete+insert data into the destination table. Incremental loading allows you to ingest only the new rows from the source table into the destination table, which means that you don't have to ingest the entire table every time you run ingestr.
 
 Incremental loading requires various identifiers in the source table to understand what has changed when, so that the new rows can be ingested into the destination table. Read more in the [Incremental Loading](/getting-started/incremental-loading.md) section.

{ingestr-0.9.2 → ingestr-0.9.4}/docs/getting-started/incremental-loading.md

@@ -6,12 +6,12 @@ outline: deep
 ingestr supports incremental loading, which means you can choose to append, merge or delete+insert data into the destination table. Incremental loading allows you to ingest only the new rows from the source table into the destination table, which means that you don't have to ingest the entire table every time you run ingestr.
 
 Before you use incremental loading, you should understand 3 important keys:
-- `primary_key`: the column(s) that uniquely identify a row in the table, if you give a primary key for an ingestion the resulting rows will be deduplicated based on the primary key, a.k.a there will only be one row for each primary key in the destination.
-- `incremental_key`: the column that will be used to determine the new rows, if you give an incremental key for an ingestion the resulting rows will be filtered based on the incremental key, a.k.a only the new rows will be ingested.
-  - A good example of an incremental key is a timestamp column, where you only want to ingest the rows that are newer than the last ingestion, e.g. `created_at` or `updated_at`.
+- `primary_key`: the column or columns that uniquely identify a row in the table, if you give a primary key for an ingestion the resulting rows will be deduplicated based on the primary key, which means there will only be one row for each primary key in the destination.
+- `incremental_key`: the column that will be used to determine the new rows, if you give an incremental key for an ingestion the resulting rows will be filtered based on the incremental key, which means only the new rows will be ingested.
+  - A good example of an incremental key is a timestamp column, where you only want to ingest the rows that are newer than the last ingestion, for example `created_at` or `updated_at`.
 - `strategy`: the strategy to use for incremental loading, the available strategies are:
   - `replace`: replace the existing destination table with the source directly, this is the default strategy and the simplest one.
-    - This strategy is not recommended for large tables, as it will replace the entire table and can be slow.
+    - This strategy isn't recommended for large tables, as it will replace the entire table and can be slow.
   - `append`: simply append the new rows to the destination table.
   - `merge`: merge the new rows with the existing rows in the destination table, insert the new ones and update the existing ones with the new values.
   - `delete+insert`: delete the existing rows in the destination table that match the incremental key and then insert the new rows.
@@ -38,7 +38,7 @@ Here's how the replace strategy works:
 > This strategy will delete the entire destination table and replace it with the source table, use with caution.
 
 ## Append
-Append will simply append the new rows from the source table to the destination table. By default, it will append all the rows, in order to use it as an incremental strategy, you should provide an `incremental_key`.
+Append will simply append the new rows from the source table to the destination table. By default, it will append all the rows. You should provide an `incremental_key` to use it as an incremental strategy.
 
 The following example below will append the new rows from the `my_schema.some_data` table in Postgres to the `my_schema.some_data` table in BigQuery, only where there's a new table.
 ```bash
@@ -89,11 +89,11 @@ When you run the command again, it will only ingest the new rows into the destin
 The behavior is the same if there were new rows in the source table, they would be appended to the destination table if they have `updated_at` that is **later than the latest record** in the destination table.
 
 > [!TIP]
-> The `append` strategy allows you to keep a version history of your data, as it will keep appending the new rows to the destination table. You can use it to build [SCD Type 2](https://en.wikipedia.org/wiki/Slowly_changing_dimension#Type_2:_add_new_row) tables, for example.
+> The `append` strategy allows you to keep a version history of your data, as it will keep appending the new rows to the destination table. You can use it to build [Slowly Changing Dimensions (SCD) Type 2](https://en.wikipedia.org/wiki/Slowly_changing_dimension#Type_2:_add_new_row) tables, for example.
 
 
 ## Merge
-Merge will merge the new rows with the existing rows in the destination table, insert the new ones and update the existing ones with the new values. By default, it will merge all the rows, in order to use it as an incremental strategy, you should provide an `incremental_key` as well as a `primary_key` to find the right rows to update.
+Merge will merge the new rows with the existing rows in the destination table, insert the new ones and update the existing ones with the new values. By default, it will merge all the rows. If you'd like to use it as an incremental strategy, you should provide an `incremental_key` as well as a `primary_key` to find the right rows to update.
 
 The following example below will merge the new rows from the `my_schema.some_data` table in Postgres to the `my_schema.some_data` table in BigQuery, only where there's a new table.
 ```bash
@@ -155,7 +155,7 @@ The behavior is the same if there were new rows in the source table, they would
 > For the cases where there's a primary key match, the `merge` strategy will **update** the existing rows in the destination table with the new values from the source table. Use with caution, as it can lead to data loss if not used properly, as well as data processing charges if your data warehouse charges for updates.
 
 ## Delete+Insert
-Delete+Insert will delete the existing rows in the destination table that match the `incremental_key` and then insert the new rows from the source table. By default, it will delete and insert all the rows, in order to use it as an incremental strategy, you should provide an `incremental_key`.
+Delete+Insert will delete the existing rows in the destination table that match the `incremental_key` and then insert the new rows from the source table. By default, it will delete and insert all the rows. If you'd like to use it as an incremental strategy, you should provide an `incremental_key`.
 
 The following example below will delete the existing rows in the `my_schema.some_data` table in BigQuery that match the `updated_at` and then insert the new rows from the `my_schema.some_data` table in Postgres.
 ```bash
@@ -213,7 +213,7 @@ When you run the command again, it will delete the existing rows in the destinat
 The behavior is the same if there were new rows in the source table, they would be deleted and inserted into the destination table if they have `updated_at` that is **later than the latest record** in the destination table.
 
 > [!TIP]
-> The `delete+insert` strategy is useful when you want to keep the destination table clean, as it will delete the existing rows in the destination table that match the `incremental_key` and then insert the new rows from the source table. `delete+insert` strategy also allows you to do backfills on the data, e.g. going back to a past date and ingesting the data again.
+> The `delete+insert` strategy is useful when you want to keep the destination table clean, as it will delete the existing rows in the destination table that match the `incremental_key` and then insert the new rows from the source table. `delete+insert` strategy also allows you to backfill the data, e.g. going back to a past date and ingesting the data again.
 
 
 ## Conclusion
@@ -222,7 +222,7 @@ Incremental loading is a powerful feature that allows you to ingest only the new
 - If you can and your data is not huge, use the `replace` strategy, as it's the simplest strategy and it will replace the entire destination table with the source table, which will always give you a clean exact replica of the source table.
 - If you want to keep a version history of your data, use the `append` strategy, as it will keep appending the new rows to the destination table, which will give you a version history of your data.
 - If you want to keep the latest version of your data in the destination table and your table has a natural primary key, such as a user ID, use the `merge` strategy, as it will update the existing rows in the destination table with the new values from the source table.
-- If you want to keep the destination table clean and you want to do backfills on the data, use the `delete+insert` strategy, as it will delete the existing rows in the destination table that match the `incremental_key` and then insert the new rows from the source table.
+- If you want to keep the destination table clean and you want to backfill the data, use the `delete+insert` strategy, as it will delete the existing rows in the destination table that match the `incremental_key` and then insert the new rows from the source table.
 
 > [!TIP]
 > Even though the document tries to explain, there's no better learning than trying it yourself. You can use the [Quickstart](/getting-started/quickstart.md) to try the incremental loading strategies yourself.

{ingestr-0.9.2 → ingestr-0.9.4}/docs/getting-started/quickstart.md

@@ -3,9 +3,9 @@ outline: deep
 ---
 
 # Quickstart
-ingestr is a command-line application that allows you to ingest data from any source into any destination using simple command-line flags, no code necessary.
+ingestr is a command-line app that allows you to ingest data from any source into any destination using simple command-line flags, no code necessary.
 
-- ✨ copy data from your Postges / Mongo / BigQuery or any other source into any destination
+- ✨ copy data from your Postgres / Mongo / BigQuery or any other source into any destination
 - ➕ incremental loading: `append`, `merge` or `delete+insert`
 - 🐍 single-command installation
 
@@ -29,11 +29,11 @@ ingestr ingest \
 
 That's it.
 
-This command will:
-- get the table `public.some_data` from the Postgres instance.
-- upload this data to your BigQuery warehouse under the schema `ingestr` and table `some_data`.
+This command:
+- gets the table `public.some_data` from the Postgres instance.
+- uploads this data to your BigQuery warehouse under the schema `ingestr` and table `some_data`.
 
 
-## Supported Sources & Destinations
+## Supported sources & destinations
 
-See the Supported Sources & Destinations page for a list of all supported sources and destinations. More to come soon!
+See the Supported Sources & Destinations page for a list of all supported sources and destinations.

{ingestr-0.9.2 → ingestr-0.9.4}/docs/getting-started/telemetry.md

@@ -8,11 +8,11 @@ ingestr uses a very basic form of **anonymous telemetry** to be able to keep tra
 - It sends the following information:
   - ingestr version
   - machine ID
-  - OS info: OS, architecture, Python version
+  - OS information: OS, architecture, Python version
   - command executed
   - success/failure
 
-The information collected here is used to understand the usage of ingestr and to improve the product. We use [Rudderstack](https://www.rudderstack.com/) to collect the events and we do not store any PII. 
+The information collected here is used to understand the usage of ingestr and to improve the product. We use [Rudderstack](https://www.rudderstack.com/) to collect the events and we don't store any PII. 
 
 The specific events that are sent are:
 - command triggered
@@ -22,5 +22,5 @@ The questions we answer by these simple events are:
 - How many unique users are using ingestr?
 - How many times is ingestr being used?
 
-## Disabling Telemetry
-If you'd like to disable telemetry, simply set the `INGESTR_DISABLE_TELEMETRY` environment variable to `true`.
+## Disabling telemetry
+If you'd like to turn off the telemetry, simply set the `INGESTR_DISABLE_TELEMETRY` environment variable to `true`.

ingestr-0.9.4/docs/supported-sources/adjust.md

@@ -0,0 +1,84 @@
+# Adjust
+
+[Adjust](https://www.adjust.com/) is a mobile marketing analytics platform that provides solutions for measuring and optimizing campaigns, as well as protecting user data.
+
+ingestr supports Adjust as a source.
+
+## URI format
+
+The URI format for Adjust is as follows:
+
+```plaintext
+adjust://?api_key=<api-key-here>
+```
+Parameters:
+- `api_key`: Required. The API key for the Adjust account.
+- `lookback_days`: Optional. The number of days to go back than the given start date for data. Defaults to 30 days.
+
+An API token is required to retrieve reports from the Adjust reporting API. please follow the guide to [obtain an API key](https://dev.adjust.com/en/api/rs-api/authentication/).
+
+Once you complete the guide, you should have an API key. Let's say your API key is `nr_123`, here's a sample command that will copy the data from Adjust into a DuckDB database:
+
+```sh
+ingestr ingest --source-uri 'adjust://?api_key=nr_123' --source-table 'campaigns' --dest-uri duckdb:///adjust.duckdb --dest-table 'adjust.output'
+```
+
+The result of this command will be a table in the `adjust.duckdb` database.
+
+### Lookback days
+
+Adjust data may change going back, which means you'll need to change your start date to get the latest data. The `lookback_days` parameter allows you to specify how many days to go back when calculating the start date, and takes care of automatically updating the start date and getting the past data as well. It defaults to 30 days.
+
+## Tables
+Adjust source allows ingesting data from various sources:
+
+- `campaigns`: Retrieves data for a campaign, showing the app's revenue and network costs over multiple days.
+- `creatives`: Retrieves data for a creative assets, detailing the app's revenue and network costs across multiple days.
+- `custom`: Retrieves custom data based on the dimensions and metrics specified.
+
+### Custom reports: `custom:<dimensions>:<metrics>[:<filters>]`
+
+The custom table allows you to retrieve data based on specific dimensions and metrics, and apply filters to the data.
+
+The format for the custom table is: 
+```plaintext
+custom:<dimensions>:<metrics>[:<filters>]
+```
+
+Parameters:
+- `dimensions`: A comma-separated list of [dimensions](https://dev.adjust.com/en/api/rs-api/reports#dimensions) to retrieve.
+- `metrics`: A comma-separated list of [metrics](https://dev.adjust.com/en/api/rs-api/reports#metrics) to retrieve.
+- `filters`: A comma-separated list of [filters](https://dev.adjust.com/en/api/rs-api/reports#filters) to apply to the data.
+  - Parsing the `filters` key is smart enough to handle filters that contain commas inside them.
+
+> [!WARNING]
+> Custom tables require a time-based dimension for efficient operation, such as `hour`, `day`, `week`, `month`, or `year`.
+
+## Examples
+
+Copy campaigns data from Adjust into a DuckDB database:
+```sh
+ingestr ingest \
+    --source-uri 'adjust://?api_key=nr_123' \
+    --source-table 'campaigns' \
+    --dest-uri duckdb:///adjust.duckdb \
+    --dest-table 'adjust.output'
+```
+
+Copy creatives data from Adjust into a DuckDB database:
+```sh
+ingestr ingest \
+    --source-uri 'adjust://?api_key=nr_123' \
+    --source-table 'creatives' \
+    --dest-uri duckdb:///adjust.duckdb \
+    --dest-table 'adjust.output'
+```
+
+Copy custom data from Adjust into a DuckDB database:
+```sh
+ingestr ingest \
+    --source-uri "adjust://?api_key=nr_123&lookback_days=2" \
+    --source-table "custom:hour,app,store_id,channel,os_name,country_code,campaign_network,campaign_id_network,adgroup_network, adgroup_id_network,creative_network,creative_id_network:impressions,clicks,cost,network_cost,installs,ad_revenue,all_revenue" \
+    --dest-uri duckdb:///adjust.db \
+    --dest-table "mat.example"
+```

{ingestr-0.9.2 → ingestr-0.9.4}/docs/supported-sources/airtable.md

@@ -4,7 +4,7 @@
 
 ingestr supports Airtable as a source.
 
-## URI Format
+## URI format
 
 The URI format for Airtable is as follows:
 
@@ -23,7 +23,7 @@ The URI is used to connect to the Airtable API for extracting data. More details
 
 Airtable requires a few steps to set up an integration, please follow the guide dltHub [has built here](https://dlthub.com/docs/dlt-ecosystem/verified-sources/airtable#setup-guide).
 
-Once you complete the guide, you should have an Access Token and Base Id. Let's say your Access Token is `patr123.abc` and Base Id is `appXYZ`, here's a sample command that will copy the data from Airtable into a duckdb database:
+Once you complete the guide, you should have an Access Token and Base Id. Let's say your Access Token is `patr123.abc` and Base Id is `appXYZ`, here's a sample command that will copy the data from Airtable into a DuckDB database:
 
 ```sh
 ingestr ingest --source-uri 'airtable://?base_id=appXYc&access_token=patr123.abc' --source-table 'employee' --dest-uri 'duckdb:///airtable.duckdb' --dest-table 'des.employee'
@@ -31,7 +31,7 @@ ingestr ingest --source-uri 'airtable://?base_id=appXYc&access_token=patr123.abc
 
 The result of this command will be an `employee` table containing data from the `employee` source in the `Airtable.duckdb` database.
 
-The `source-table` can include multiple table names that share the `same base_id` (e.g.--source-table 'employee,users') but this will merge all the data from the specified tables into a single destination table.
+The `source-table` can include multiple table names that share the same `base_id`, e.g. `--source-table 'employee,users'`, but this will merge all the data from the specified tables into a single destination table.
 
 > [!CAUTION]
 > Airtable does not support incremental loading, which means every time you run the command, the entire table will be copied from Airtable to the destination. This can be slow for large tables.

ingestr-0.9.4/docs/supported-sources/appsflyer.md

@@ -0,0 +1,33 @@
+# AppsFlyer
+
+[AppsFlyer](https://www.appsflyer.com/) is a mobile marketing analytics and attribution platform that helps businesses track, measure, and optimize their app marketing efforts across various channels.
+
+ingestr supports AppsFlyer as a source.
+
+The URI format for AppsFlyer is as follows:
+
+```plaintext
+appsflyer://?api_key=<api-key>
+```
+
+An API token is required to retrieve reports from the AppsFlyer API. Please follow the guide to [obtain a API key](https://support.appsflyer.com/hc/en-us/articles/360004562377-Managing-AppsFlyer-tokens)
+
+Once you complete the guide, you should have an API key. Let's say your API key is `ey123`, here's a sample command that will copy the data from AppsFlyer into a DuckDB database:
+
+```bash
+ingestr ingest 
+    --source-uri 'appsflyer://?api_key=ey123' 
+    --source-table 'campaigns' 
+    --dest-uri duckdb:///appsflyer.duckdb 
+    --dest-table 'appsflyer.output'
+```
+
+The result of this command will be a table in the `appsflyer.duckdb` database.
+
+## Tables
+AppsFlyer source allows ingesting the following sources into separate tables:
+
+- `campaigns`: Retrieves data for campaigns, detailing the app's costs, loyal users, total installs, and revenue over multiple days.
+- `creatives`: Retrieves data for a creative asset, including revenue and cost.
+
+Use these as `--source-table` parameter in the `ingestr ingest` command.

{ingestr-0.9.2 → ingestr-0.9.4}/docs/supported-sources/bigquery.md

@@ -1,9 +1,9 @@
 # Google BigQuery
-BigQuery is a fully-managed, serverless data warehouse that enables scalable analysis over petabytes of data.
+BigQuery is a fully managed, serverless data warehouse that enables scalable analysis over petabytes of data.
 
 ingestr supports BigQuery as both a source and destination.
 
-## URI Format
+## URI format
 The URI format for BigQuery is as follows:
 
 ```plaintext
@@ -13,7 +13,7 @@ bigquery://<project-name>?credentials_path=/path/to/service/account.json&locatio
 URI parameters:
 - `project-name`: the name of the project in which the dataset resides
 - `credentials_path`: the path to the service account JSON file
-- `location`: the location of the dataset (optional)
+- `location`: optional, the location of the dataset
 
 The same URI structure can be used both for sources and destinations. You can read more about SQLAlchemy's BigQuery dialect [here](https://github.com/googleapis/python-bigquery-sqlalchemy?tab=readme-ov-file#connection-string-parameters).
 

{ingestr-0.9.2 → ingestr-0.9.4}/docs/supported-sources/chess.md

@@ -4,7 +4,7 @@
 
 ingestr supports Chess.com as a source, primarily to play around with the data of players, games, and more since it doesn't require any authentication.
 
-## URI Format
+## URI format
 
 The URI format for Chess is as follows:
 
@@ -26,12 +26,12 @@ ingestr ingest --source-uri 'chess://?players=max2,peter23' --source-table 'prof
 
 The result of this command will be a table in the `chess.duckdb` database.
 
-## Available Tables
+## Tables
 
 Chess source allows ingesting the following sources into separate tables:
 
-- `profiles`: Retrives player profiles based on a list of player usernames.
-- `games`: Retrives players' games for specified players.
-- `archives`: Retrives url to game archives for specified players.
+- `profiles`: Retrieves player profiles based on a list of player usernames.
+- `games`: Retrieves players' games for specified players.
+- `archives`: Retrieves the URLs to game archives for specified players.
 
 Use these as `--source-table` parameter in the `ingestr ingest` command.

{ingestr-0.9.2 → ingestr-0.9.4}/docs/supported-sources/csv.md

@@ -1,7 +1,7 @@
 # CSV
 ingestr supports CSV files as source and destination. This allows copying data from any database into a local CSV file, as well as uploading data from the local CSV files into database tables.
 
-## URI Format
+## URI format
 The URI format for CSV files is as follows:
 
 ```plaintext

{ingestr-0.9.2 → ingestr-0.9.4}/docs/supported-sources/databricks.md

@@ -3,7 +3,7 @@ Databricks is a platform for big data analytics and artificial intelligence.
 
 ingestr supports Databricks as both a source and destination.
 
-## URI Format
+## URI format
 The URI format for Databricks is as follows:
 
 ```plaintext

{ingestr-0.9.2 → ingestr-0.9.4}/docs/supported-sources/duckdb.md

@@ -3,7 +3,7 @@ DuckDB is an in-memory database designed to be fast and reliable.
 
 ingestr supports DuckDB as both a source and destination.
 
-## URI Format
+## URI format
 The URI format for DuckDB is as follows:
 
 ```plaintext

{ingestr-0.9.2 → ingestr-0.9.4}/docs/supported-sources/facebook-ads.md

@@ -4,7 +4,7 @@ Facebook Ads is the advertising platform that helps users to create targeted ads
 
 ingestr supports Facebook Ads as a source.
 
-## URI Format
+## URI format
 
 The URI format for Facebook Ads is as follows:
 
@@ -25,7 +25,7 @@ The URI is used to connect to Facebook Ads API for extracting data.
 
 Facebook Ads requires a few steps to set up an integration, please follow the guide dltHub [has built here](https://dlthub.com/docs/dlt-ecosystem/verified-sources/facebook_ads#setup-guide).
 
-Once you complete the guide, you should have an Access_Token and Account ID . Let's say your access_token is `abcdef` and account_id is `1234` , here's a sample command that will copy the data from Facebook Ads into a duckdb database:
+Once you complete the guide, you should have an access token and an Account ID. Let's say your `access_token` is `abcdef` and `account_id` is `1234`, here's a sample command that will copy the data from Facebook Ads into a DuckDB database:
 
 ```sh
 ingestr ingest \
@@ -37,7 +37,7 @@ ingestr ingest \
 
 The result of this command will be a table in the `facebook.duckdb` database.
 
-## Available Tables
+## Tables
 
 Facebook Ads source allows ingesting the following sources into separate tables:
 

{ingestr-0.9.2 → ingestr-0.9.4}/docs/supported-sources/gorgias.md

@@ -3,7 +3,7 @@
 
 ingestr supports Gorgias as a source.
 
-## URI Format
+## URI format
 The URI format for Gorgias is as follows:
 
 ```plaintext
@@ -26,7 +26,7 @@ ingestr ingest --source-table 'tickets' --source-uri $GORGIAS_URI --dest-uri $BI
 ingestr ingest --source-table 'customers' --source-uri $GORGIAS_URI --dest-uri duckdb:///gorgias.duckdb --interval-start 2024-01-01  --dest-table 'gorgias.customers'
 ```
 
-## Supported Entities
+## Supported entities
 The Gorgias source supports a growing list of entities, feel free to create an issue if you need more entities to be supported.
 
 ### Customers
@@ -39,12 +39,12 @@ Tickets are the main entity in Gorgias, representing customer inquiries. Each ti
 
 You can retrieve tickets by using `tickets` as the source table.
 
-### Ticket Messages
+### Ticket messages
 Ticket messages are the messages exchanged between the customer and the support agent in a ticket. Each message has a unique ID and contains information such as the sender, content, and timestamp.
 
 You can retrieve ticket messages by using `ticket_messages` as the source table.
 
-### Satisfaction Surveys
+### Satisfaction surveys
 Satisfaction surveys are sent to customers after a ticket is resolved to gather feedback on their experience. Each survey has a unique ID and contains information such as the rating and comments.
 
 You can retrieve satisfaction surveys by using `satisfaction_surveys` as the source table.