The name of the integration, corresponding to the value of name in the integration’s doc. For example: Entering github would associate the table with the GitHub integration.

The applicable version of the integration that contains the table.

Example values:

• 1
• 2

The name of the table as it appears in the tap. This is, generally, how the table name will appear in the user’s destination.

Example values:

• companies
• deal_pipelines
• email_activities

If applicable, the URL of the provider’s API documentation that’s associated with the table.

If applicable, the URL of the table’s schema in its Singer repository.

A description of the table. The description should contain helpful info about what data the user can expect to find in the table.

If applicable, include additional notes about how the table replicates, or anything that might be helpful. For example: How to identify deleted records, if the table is Append-Only, etc.

The Replication Method Stitch uses to replicate data for the table.

Must be one of the following:

• Key-based Incremental
• Append-Only Incremental
• Full Table

Only used if a Replication Key is not a column in the table itself. The name of the parameter used as a Replication Key for Incremental Replication.

The majority of the time, Stitch will use a column in the table itself (ex: updated_at) to identify new/updated data for replication. On occasion, some APIs don’t expose suitable fields in the response, meaning Stitch can’t use a tangible field as a Replication Key.

In these situations, the integation may use a query parameter in the API request used to extract data for the table. If this is the case for the table, enter the name of the parameter used.

Example values:

• updated_since
• created_since

The name of the API method used to request and extract data for the table. The value of this parameter should match what’s in the provider’s API documentation, if documentation exists.

Example values:

• Get customers
• List companies
• GetAllDealStages

The URL of the provider’s API documentation for the API method used for the table, if available.

The name of the attribute as it appears in the tap. Note: Case must be retained. This means that if the attribute’s name contains upper- and lower-case characters in the tap, the value of this parameter should match.

Example values:

• id
• CustomerID
• customer_name

The attribute’s data type.

Note: If the data type is object or array, the attribute will have sub-attributes. See the array-attributes and object-attributes attributes below for more info.

Must be one of the following:

• string
• boolean
• date-time
• integer
• number
• object
• array

If true, the attribute is the table’s Primary Key or makes up part of a composite Primary Key for the table.

If true, the attribute is the table’s Replication Key or makes up part of a composite Replication Key.

A description of the attribute, which can be written in Markdown or HTML.

- name: "is_active"
  type: "boolean"
  description: "If `true`, the user is currently active."

When appropriate, include potential values in list format. For example:

- name: "user_type"
  type: "string"
  description: |
    The user's type. Possible values are:

    - `admin`
    - `agent`
    - `read-only`

If applicable, a link to documentation that’s relevant to the attribute.

Applicable only if the attribute is an array (type: array). This is a map (the start of a list) that contains the sub-attributes contained in the array.

Sub-attributes follow the same structure as a top-level attribute, meaning they each nave a name, type, description, etc. Each sub-attribute must be indented two spaces from the start of array-attributes:.

For example:

- name: "customer_ids"
  type: "array"
  description: ""
  array-attributes:
    - name: "id"
      type: "integer"
      description: ""

Applicable only if the attribute is an object (type: object). This is a map (the start of a list) that contains the sub-attributes contained in the object.

Sub-attributes follow the same structure as a top-level attribute, meaning they each nave a name, type, description, etc. Each sub-attribute must be indented two spaces from the start of array-attributes:.

For example:

- name: "street_address"
  type: "object"
  description: "The customer's street address."
  array-attributes:
    - name: "address1"
      type: "string"
      description: "The first line of the customer's street address."

    - name: "city"
      type: "string"
      description: "The city associated with the customer's address."

    - name: "state"
      type: "string"
      description: "The state associated with the customer's address."