# Sailthru Export Integration From The Command Line

Output result data from TD to Sailthru via CLI (TD Toolbelt).

# Prerequisites

- [TD Toolbelt](http://docs.treasuredata.com/display/PD/Installing+TD+Toolbelt) is installed.
- Basic knowledge and a Sailthru account.


## Using the Command-Line to Create Your Connection

You can use the CLI to configure your connection.


```bash
td query --database your_database --result configuration query
```

The following table identifies the configuration keys with descriptions.

| **Config Key** | **Type** | **Required** | **Description** |
|  --- | --- | --- | --- |
| `type` | string | yes | sailthru |
| `target` | string | Yes | Either “list” or “user”. |
| `api_key` | string | Yes | Sailthru provided API Key. Unlike result exporting with an established Authentication (using Console’s Query Results Export or Workflow), you have to explicitly specify your API Key in the CLI’s parameters. |
| `api_secret` | string | Yes | Sailthru provided API Secret. Similar to API Key, you also have to specify your API Secret. |
| `list_name` | string | Yes (for `target`: “list”) | Your destination list name.  A new list is created if it doesn’t exist or an existing list updates. You can [checklist names](https://my.sailthru.com/lists) on Sailthru. |
| `list_type` | string | No | Select either Primary or Secondary.  **Primary** lists are your main lists of subscribers that you send to on a regular and periodic basis. If you wish to track the growth of a list, it must be marked as primary.  **Secondary** lists are lists for which you do not need growth reporting. Their growth is not tracked, so they will not show up in the Primary List reports.  If an option is selected, it updates the existing list to this type. If neither is selected, list type remains as it was previously. See Sailthru for the [difference between primary and secondary lists](https://getstarted.sailthru.com/audience/managing-lists/primary-and-secondary-lists/). |
| `list_public_name` | string | No | The name that will be presented to your subscribers (i.e. on an opt-out page). |
| `user_key` | string | Yes (for `target`: `user`) | Select the corresponding type of your `id` column – email, SMS, sid, extid. |
| `user_ignore_error` | boolean | No | If checked, export jobs still proceed even if a user cannot be created/updated. If left unchecked, jobs terminate if an error record occurs. |
| `user_keys_columns` | string | No | Additional columns (comma separated) that are used to update the user’s keys. The column name has to match the key type exactly. |
| `user_keys_conflict_resolution` | string | No | “error” terminates the job if a conflict occurs (i.e. the changed keys match with another that already exists in the Sailthru database).  “merge” attempts to resolve the conflicted users with users that have the current `id`. |
| `user_vars_column` | string | No | Columns that are used as additional user’s variables. |
| `user_list` | string | No | Update the Lists that the user belongs to. The value has to conform to the syntax of: `"List Name": 0 |
| `user_optout_templates` | string | No | Similar to `user_list` config, but this is to add/remove users from the opt-out templates. |
| `bulk_user_key` | string | Yes (for `target`: `bulk_user`) | Select the corresponding type of your `id` column --email, SMS, sid, extid. |
| `bulk_user_keys_columns` | string | No | Similar to `user_keys_columns`, but for `target: bulk_user` |
| `bulk_user_vars_column` | string | No | Similar to `user_vars_columns`, but for `target: bulk_user` |
| `bulk_user_lists` | string | No | Similar to `user_lists`, but for `target: bulk_user` |
| `bulk_user_ignore_error` | string | No | Similar to `user_ignore_error`, but for `target: bulk_user` |


## **Example**: Outputting Emails to a List


```bash
td query --database my_db \
--result '{
           "type": "sailthru",
           "api_key": "xxx"
           "api_secret": "yyy"
           "target": "list",
           "list_name": "My List"
         }' \
'SELECT email from your_table'
```

## **Example**: Outputting Users


```bash
td query --database my_db \
--result '{
    "type": "sailthru",
    "api_key": "xxx",
    "api_secret": "yyy",
    "target": "user",
    "user_key": "email",
    "user_keys_columns": "sms, extid",
    "user_vars_columns": "name, address",
    "user_lists": "\"My List\": 1, \"Other List\": 0",
    "user_key_conflict_resolution": "merge",
    "user_optout_templates": "\"My Template\": 1",
    "user_ignore_error": true
  }' \
'SELECT email as id, sms, extid, name, address from your_table'
```

## **Example**: Bulk Outputting Users


```bash
td query --database my_db \
--result '{
    "type": "sailthru",
    "api_key": "xxx",
    "api_secret": "yyy",
    "target": "user",
    "bulk_user_key": "email",
    "bulk_user_keys_columns": "sms, extid",
    "bulk_user_vars_columns": "name, address",
    "bulk_user_lists": "\"My List\": 1, \"Other List\": 0",
    "bulk_user_ignore_error": true
  }' \
'SELECT email as id, sms, extid, name, address from your_table'
```

## Scheduling Execution

Learn more:

- [Scheduling Data Connector Job Execution from the CLI](/int/scheduling-a-data-connector-job-execution-from-the-cli)