Stitch Connect API Reference

• Definition: An API access token associated with a single Stitch client account. This token must be passed into the header of every request made to the API for the Stitch client account.

• Required for: All API requests, except for Create an account

• Obtained by: Refer to the Obtain an API access token section

• Expiration: None

• Definition: The unique ID for your partner application, obtained after an interest form is submitted to and approved by Stitch.

• Required for: Requests to the Create an account endpoint

• Obtained by: Submitting an interest form and being approved by Stitch as a partner

• Expiration: None

• Definition: The key associated with your partner application, obtained after an interest form is submitted to and approved by Stitch.

• Required for: Requests to the Create an account endpoint

• Obtained by: Submitting an interest form and being approved by Stitch as a partner

• Expiration: None

• Definition: A token passed to the Connect JavaScript client to create a session in the Stitch web application and log a user into a Stitch client account.

• Required for: Creating a temporary Stitch session using the Connect JavaScript client

• Obtained by: A successful request to the Create a session endpoint

• Expiration: One hour after generation

• Definition: A token used to create a temporary Stitch session for the user for whom the exchanged ephemeral token was created.

• Required for: Creating a temporary Stitch session using the Connect JavaScript client

• Obtained by: Exchanging a valid ephemeral token in a Connect JavaScript function

• Expiration: Upon session termination or after 12 hours, whichever is first

Jobs

• GET /v4/{stitch_client_id}/extractions/{job_name}
• GET /v4/{stitch_client_id}/extractions
• GET /v4/{stitch_client_id}/loads

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The API URL to which /endpoints are appended.

The secure OAuth 2.0 identifier for the 3PL Central application/client.

The secure OAuth 2.0 secret key for the 3PL Central application/client authentication.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (60).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The ID for the 3PL Central customer organization.

The ID for the 3PL Central warehouse facility.

Defines how often, in minutes, Stitch should attempt to replicate data from 3PL Central. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from 3PL Central. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

A 3PL Central warehouse-specific 3PL key.

The ID for the 3PL Central user.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (60).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

An ISO 8601-compliant date to indicate the date that Stitch should stop replicating data from your AdRoll account. This can be useful if you want to replicate campaign data from a specific timerange.

Defines how often, in minutes, Stitch should attempt to replicate data from AdRoll. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from AdRoll. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

An access token generated by a NextRoll OAuth handshake.

The secret key of the AdRoll account to use when extracting data.

The grant to refresh your NextRoll access token when it has expired.

If true, an auto-incrementing Primary Key will not be required for tables using Full Table Replication. Auto-incrementing Primary Keys are used during full table replication to allow the replication of a table to span multiple replication jobs.

Unless set, this property will default to true.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (30).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The name of the logical database to connect to.

This is an internal field and is for Stitch use only.

Defines how often, in minutes, Stitch should attempt to replicate data from Amazon Aurora. Accepted values are:

• 1

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The IP address or hostname of the database server.

The password for the user connecting to the database server. Note: This property will never be returned by the API, but it can be submitted when creating or modifying a connection.

The port of the database server. The default is 3306.

Defines the unique ID of the server that Stitch will connect to, if using Log-based (binlog) Replication.

Server IDs must be unique, as MySQL doesn’t allow replication to simultaneously occur across multiple connections using the same server ID. For more info about this setting in Stitch, refer to the MySQL documentation.

If true, an SSH tunnel will be used to connect to the database.

The IP address or hostname of the SSH server. This property is only required if ssh: true.

The port of the SSH server. This property is only required if ssh: true.

The username of the SSH user. This property is only required if ssh: true.

If true, SSL will be used to connect to the database.

If true, Log-based Incremental Replication will be used as the default Replication Method for tables set to replicate. This choice can be overriden on individual tables at any time.

The username of the database user.

The user’s Amazon Web Services (AWS) Account ID. Refer to the Amazon DynamoDB documentation for more info.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (60).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The external ID associated with the Amazon Web Services (AWS) Identity Access Management (IAM) role used by Stitch. In AWS, external IDs are used to increase role security when granting access to accounts that you don’t own or have administrative access to. Stitch will provide this ID when accessing Amazon DynamoDB.

This value can be anything, but it must be the same as the external ID provided in the AWS console when creating the Stitch IAM role. Refer to the Amazon DynamoDB documentation for more info.

Defines how often, in minutes, Stitch should attempt to replicate data from Amazon DynamoDB. Accepted values are:

• 1

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The name of the region your Amazon DynamoDB instance resides in.

The name of the AWS IAM role Stitch should assume when extracting data from Amazon DynamoDB. This role will have the permissions in the IAM policy associated with the role.

Refer to the Amazon DynamoDB documentation for more info about the IAM policy, role, and how to create them in AWS.

The date from which Stitch should begin replicating data from Amazon DynamoDB. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

This is a Stitch internal field.

The name of the logical database to connect to.

If using SSH encryption, the host of the SSH server. Required only if encryption_type is ssh.

If using SSH encryption, the port of the SSH server. Required only if encryption_type is ssh.

Indicates that SSH encryption should be used to connect to the destination. Valid values are:

• none - No encryption will be used.
• ssh - SSH encryption will be used to connect to the destination. The SSH connection details should be submitted using the encryption_host, encryption_port, and encryption_username.

If using SSH encryption, the name of the SSH user. Required only if encryption_type is ssh.

The IP address or hostname of the database server.

The password for the user connecting to the database server. Note: This property will never be returned by the API, but it can be submitted when creating or modifying a connection.

The port of the database server. The default is 5439.

The username of the database user.

The user’s Amazon Web Services (AWS) Account ID. Refer to the Amazon S3 CSV documentation for more info.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The name of the bucket Stitch should replicate data from. This value should not contain any URLs, https, or S3 parts.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (60).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The external ID associated with the Amazon Web Services (AWS) Identity Access Management (IAM) role used by Stitch. In AWS, external IDs are used to increase role security when granting access to accounts that you don’t own or have administrative access to. Stitch will provide this ID when accessing Amazon S3 CSV.

This value can be anything, but it must be the same as the external ID provided in the AWS console when creating the Stitch IAM role. Refer to the Amazon S3 CSV documentation for more info.

Defines how often, in minutes, Stitch should attempt to replicate data from Amazon S3 CSV. Accepted values are:

• 1

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The name of the AWS IAM role Stitch should assume when extracting data from Amazon S3. This role will have the permissions in the IAM policy associated with the role.

Refer to our Amazon S3 CSV documentation for more info about the IAM policy, role, and how to create them in AWS.

The date from which Stitch should begin replicating data from Amazon S3 CSV. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

A series of properties defining the CSV files to be tracked as tables. For every table configuration, this property will contain a JSON object with the following properties. Note: Every property should be an escaped string.

Refer to the Amazon S3 CSV documentation for requirements for CSV files.

• search_pattern - The search criteria Stitch should use when selecting CSV files for extraction. This can be the name of a single file or a regular expression. For example: customers.csv or *\.csv
• search_prefix - The directory path Stitch should limit the file search to. For example: exports/data
• table_name - The name of the table as it should appear in the destination. For example: customers

• key_properties - A comma-separated list of header fields in the CSV files Stitch can use to uniquely identify records. For example: _id,date

  Note: If undefined, data will be loaded to the table in an append-only fashion. Refer to the Amazon S3 CSV documentation for more info.

• date_overrides - A comma-separated list of header fields in the CSV that should be typed as datetime fields in the destination. For example: updated_at,created_at

  Note: If columns aren’t specified and values can’t be parsed as dates, Stitch will load data for the columns as nullable strings. Refer to the Amazon S3 CSV documentation for more info.

• delimiter - The field separator delimiter used in the CSV files. Accepted values are:

  • , - Comma
  • | - Pipe
  • \t - Tab

Defines the delimiter used if output_file_format is csv. Accepted values are:

• , (comma)
• | (pipe)
• \t (tab)

If true, Stitch will place all elements of key-value pairs in quotes when output_file_format is csv.

For example: Numerical fields will appear as "123" instead of 123.

Defines the type of file Stitch will write to the bucket. Possible values are:

• csv, which will use CSV (.csv) files
• jsonl, which will use JSON (.jsonl) files

For examples of what data will look like in each format, refer to our Amazon S3 documentation.

The name of the Amazon S3 bucket Stitch will write to.

Defines the naming convention Stitch should use when creating Object Keys. Object Keys are used to name tables when Stitch writes to the bucket.

The required elements for an Object Key are:

• [integration_name]
• [table_name]
• [table_version]
• [timestamp_loaded]

For more info on construcing an S3 Object Key, refer to our Amazon S3 documentation.

The sentinel key is the name the challenge file in the bucket must have. The challenge file is a blank file that Stitch uses to test the permissions for the bucket. Note: The API treats this property as a credential, which means it won’t be returned in responses.

This file:

• Must have a name that begins with stitch-challenge-file-. For example: stitch-challenge-file-af295ad1-7a4b-4881-89dc-c9be27de13a5
• Must remain in the bucket even after the inital setup is complete

Refer to our Amazon S3 documentation for additional details.

The account ID for the Amplitude Snowflake warehouse.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (30).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Amplitude. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from Amplitude. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

The username of the database user.

The name of the Amplitude Snowflake warehouse.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The API token for the AppsFlyer account Stitch should replicate data from. Refer to the AppsFlyer documentation for instructions on retrieving this info.

The app ID for the AppsFlyer account Stitch should replicate data from. Refer to the AppsFlyer documentation for instructions on retrieving this info.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (30).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from AppsFlyer. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from AppsFlyer. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (60).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Asana. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from Asana. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

The Asana token to use in future requests to the Asana API, created after a successful OAuth handshake.

Your Asana OAuth application client ID.

Your Asana OAuth application client secret.

Your Asana OAuth application redirect URL. This is provided to Asana when you register your OAuth application.

If exchanging a code with Asana, a long-lived token that can be used to retrieve new access_tokens when old ones expire.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

An API key for the Autopilot account that Stitch should replicate data from.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (3600).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Autopilot. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from Autopilot. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

The user’s BigCommerce API access token. Refer to the BigCommerce documentation for instructions on retrieving this credential.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The user’s BigCommerce API client ID. Refer to the BigCommerce documentation for instructions on retrieving this credential.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (60).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from BigCommerce. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from BigCommerce. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

The user’s BigCommerce store hash. Refer to the BigCommerce documentation for instructions on retrieving this credential.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (30).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Braintree. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The Braintree account’s merchant ID. Note: Stitch’s Braintree integration replicates data from the default merchant account under this merchant ID. Refer to the Braintree documentation for instructions on retrieving this info.

The Braintree account’s private key. Refer to the Braintree documentation for instructions on retrieving this info.

The Braintree account’s public key. Refer to the Braintree documentation for instructions on retrieving this info.

The date from which Stitch should begin replicating data from Braintree. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (60).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Bronto. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from Bronto. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

The API token for the Bronto account Stitch should replicate data from.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Note: Advanced Scheduling using Cron is not yet supported for this source. A value may be submitted for this property if the account is on an Enterprise plan, but Stitch will not use the expression submitted.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (30).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Campaign Manager. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The ID of the Campaign Manager profile you want to replicate data from. Refer to the Campaign Manager documentation for instructions on retrieving this info.

Your Campaign Manager OAuth application’s client ID. Refer to Google’s documentation for more info.

Your Campaign Manager OAuth application’s client secret. Refer to Google’s documentation for more info.

A long-lived token, used to generate new access tokens when needed. Refer to Google’s documentation for more info.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The user’s Campaign Monitor API client ID. This can be found in the Campaign Monitor app in Account Settings > API keys.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (30).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Campaign Monitor. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from Campaign Monitor. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

An Campaign Monitor OAuth token.

A long-lived Campaign Monitor token which can be used to obtain a new Campaign Monitor access_token.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The user’s Chargebee API key. Refer to the Chargebee documentation for info on generating this credential.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (60).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Chargebee. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The name of the user’s Chargebee site. This can be found in the Chargebee site URL. For example: If the URL was https://stitch.chargebee.com, only stitch would be entered into this field.

The date from which Stitch should begin replicating data from Chargebee. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

A Chargify API key. Refer to the Chargify documentation for instructions on creating this credential.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (60).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Chargify. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from Chargify. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

Your Chargify subdomain. For example: If the full URL of your Chargify site were https://stitch.my-chargify-site.com, this value would be stitch.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Your API key. API keys can be generated in by navigating to Settings > Your API Keys.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (30).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Close.io. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from Close.io. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (30).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Club Speed. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Your Club Speed private API key. You will need to contact Club Speed support to obtain this credential.

The date from which Stitch should begin replicating data from Club Speed. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

Your Club Speed subdomain.

For example: If the full URL is stitchdata.clubspeedtiming.com, only stitchdata should be entered.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Your Codat API key. Refer to the Codat documentation for instructions on retrieving this credential.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (60).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Codat. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from Codat. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

Indicates whether the instance being connected is a UAT (sandbox) instance or not.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

A GitHub access token which allows access to any project the user wants to replicate data from. Note: This access token must have the repo scope at a minimum. Refer to the COVID-19 Public Data documentation for more info.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (60).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from COVID-19 Public Data. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from COVID-19 Public Data. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (60).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Darksky. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The language that summary attributes in the forecast table should be returned in. For example: If set to en, summary data will be returned in English.

Refer to Darksky’s documentation for a list of accepted values.

The longitude and latitude of the locations to be returned. The locations must be semi-colon delineated.

For example: <latitude>,<longitude> is an accepted value for a single location, and <latitude>,<longitude>;<latitude>,<longitude>; ... etc is accepted for multiple locations.

Your Darksky secret API key. Refer to the Darksky documentation for instructions on obtaining this credential.

The date from which Stitch should begin replicating data from Darksky. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

The requested unit of measurement for weather conditions to be returned.

For example: us for Imperial Units, and si for International System of Units.

A Databricks REST API access token. Refer to the Databricks Delta Lake documentation for instructions on generating this credential.

The JDBC URL used to connect to your Databricks cluster. Refer to the Databricks Delta Lake documentation for instructions on retrieving this info.

An object containing properties for configuring SSH encryption for the destination.

Contains the following properties:

Connection information for the Amazon S3 bucket Stitch will stage data to before loading into Databricks Delta Lake.

Contains the following properties:

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (60).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Deputy. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from Deputy. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

Your Deputy OAuth application’s client ID.

Your Deputy OAuth application’s client secret.

The Deputy subdomain of the user authorizing the connection.

A URL where Deputy will forward the user with access credentials for your application.

A long-lived token, used to generate new Deputy access tokens when old ones expire.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (60).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from eBay. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

This is your App ID in your eBay seller account.

This is your Cert ID in your eBay seller account.

A long-lived token, used to generate new eBay access tokens when old ones expire.

This allows Stitch to have certain access privileges to your eBay sales data.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The number of records each page in a bulk export should contain. Note: This setting only affects streams that use the Eloqua Bulk API. Refer to the Eloqua documentation for info about how each stream is replicated.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (60).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Eloqua. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from Eloqua. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

Your Eloqua OAuth application’s client ID, obtained when you register your app with Eloqua.

Your Eloqua OAuth application’s client secret, obtained when you register your app with Eloqua.

Your Eloqua OAuth application’s registered redirection endpoint. This should be the same URL entered as the Callback Url when you registered your app.

A long-lived token, used to generate new Eloqua access tokens when old ones expire.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines the number, in days, Stitch should use as an attribution window. An attribution window is the period of time for attributing results to ads and the lookback period after those actions occur during which ad results are counted.

Accepted values, in days:

• 1
• 7
• 28

To ensure your Facebook Ads and Stitch settings align, we recommend using the same attribution window in Stitch that you use in Facebook Ads. For example: If the attribution window is 28 days in Facebook, this value should be 28.

If your click and view windows differ, you should select the greater of the two. For example: If clicks have a window of 7 days and views have a window of 1 day, you should enter 7 for this setting.

Note: Advanced Scheduling using Cron is not yet supported for this source. A value may be submitted for this property if the account is on an Enterprise plan, but Stitch will not use the expression submitted.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (30).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Facebook Ads. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

If true, Stitch will replicate data for deleted campaigns, ads, and adsets. Note: This data will not be included alongside insights data.

The date from which Stitch should begin replicating data from Facebook Ads. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

An access token generated by a Facebook OAuth handshake.

The ID of the Facebook Ads account to use when extracting data.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The API key for the Freshdesk account Stitch should replicate data from. Refer to the Freshdesk documentation for instructions on retrieving this credential.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (30).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The subdomain prefix of the Freshdesk account Stitch should replicate data from. For example: If the URL were stitch. }}.com, this value would be stitch.

Defines how often, in minutes, Stitch should attempt to replicate data from Freshdesk. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from Freshdesk. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (30).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Front. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how data will be aggregated. Accepted values are daily or hourly.

The date from which Stitch should begin replicating data from Front. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

The user’s Front API token. Refer to the Front setup guide for instructions on how to generate this token.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

A FullStory API key, used to authenticate to FullStory’s Data Export API.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (30).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from FullStory. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from FullStory. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

An access token which allows access to any project the user wants to replicate data from. Note: This access token must have the repo scope at a minimum. Refer to the GitHub documentation for more info.

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (60).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from GitHub. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The path or paths of the repository or repositories to be tracked. A repository path is relative to https://github.com. For example: The path for the Stitch Docs repository is stitchdata/docs

To track multiple repositories, this value should be a space delimited list of the repository paths. For example:

stitchdata/docs stitchdata/docs-about-docs

The date from which Stitch should begin replicating data from GitHub. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The URL for the GitLab API. This value must be https://gitlab.com/api/v3.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (30).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from GitLab. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Note: While providing this property is optional, either projects or groups must be provided. You may also provide both properties.

A space separated list of groups you want to track. How data is replicated using this property depends on the value of the groups property:

• If groups is provided but projects is not, all group projects will be replicated.
• If groups and projects are provided, the selected projects of the provided groups will be replicated.
• If projects is provided but groups is not, all selected projects will be replicated.

A GitLab Personal Access token. Refer to the GitLab documentation for instructions on generating this credential.

Note: While providing this property is optional, either projects or groups must be provided. You may also provide both properties.

A space-separated list of projects you want to track.

For example: In an organization named stitch, there are two projects to track: stitch-data and stitch-docs. To track them, this value would be: stitch/stitch-data stitch/stitch-docs

A space separated list of groups you want to track. How data is replicated using this property depends on the value of the groups property:

• If groups is provided but projects is not, all group projects will be replicated.
• If groups and projects are provided, the selected projects of the provided groups will be replicated.
• If projects is provided but groups is not, all selected projects will be replicated.

The date from which Stitch should begin replicating data from GitLab. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

Defines the time that frequency_in_minutes is “anchored” to, which Stitch will use to create the integration’s replication schedule. In Stitch, this is referred to as Anchor Scheduling.

This field must contain an ISO 8601-compliant date. Note: When Stitch stores this value, it will be in UTC. You should provide this value in UTC to ensure the desired anchor time is retained.

For example: You want to create a schedule that is anchored to 1:00PM EST and runs every 6 hours (360 minutes). To do this, you can set anchor_time to something like 2018-04-30T17:00:00Z and frequency_in_minutes to 360. This means jobs would run at 23:00:00, 05:00:00, 11:00:00, and so on.

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

A valid Quartz cron expression representing the replication schedule for the integration. Refer to the Advanced Scheduling documentation for more info.

Note: If neither a cron_expression or frequency_in_minutes property is provided, Stitch will use the source’s default frequency_in_minutes value (1440).

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

Defines how often, in minutes, Stitch should attempt to replicate data from Google Ads. Accepted values are:

• 30
• 60
• 360
• 720
• 1440

Refer to the Replication Scheduling for API sources guide for more info about replication scheduling using the API.

The date from which Stitch should begin replicating data from Google Ads. Data from this date forward will be replicated.

This field must contain an ISO 8601-compliant date, and the timestamp must be midnight. For example: 2018-01-01T00:00:00Z

A comma-separated list of Google Ads account IDs to replicate data from.