To ensure we’re providing improvements and fixes without breaking your downstream processes, Stitch versions its integrations. This allows you to understand what’s coming and make any necessary changes before you decide to upgrade.

In this guide, we’ll cover:


Understand integration versioning in Stitch

In this section, we’ll cover:

Version numbers

If you’ve previously checked an integration’s version, you might’ve noticed that version numbers in Stitch and what we have in the docs look a little different.

In the docs, we only use the major version identifier when referring to an integration’s version. For example: You might see 1.0.8 in Stitch, but in the docs we’ll use 1 (or v1) to refer to the version. Check out the next section for an example.

Note: For some integrations, you’ll see a version that’s formatted like a date, such as v15-10-2015. These are legacy versions that pre-date the Singer framework and indicate that an integration isn’t backed by a Singer tap. Refer to the Legacy integration versions section for more info.

Version upgrades

Most of the time, you’ll only need to upgrade an integration’s version when we release a new major version. Minor versions and patches are typically applied automatically.

When a new major version is made generally available (or Released, as noted in the next section), a few things will happen:

  1. The preceeding version is removed from Stitch. New connections can only be created using the new version, but existing connections will continue to run.
  2. We’ll communicate a deprecation date for the preceeding version, at which point Stitch will no longer offer support for it.
  3. After a period of time, we’ll communicate a sunset date for the preceeding version. Integrations using the now-sunset version will stop running.

Upgrading to a new major version requires you to re-create the integration in your account and re-replicate historical data.

Note: If you delete the original integration and re-use its namespace (schema name), the re-replication will count towards your row usage. However, if you use a new namespace, the first seven days of replication will be subject to the free historical data load and not count towards your usage.

Version statuses

The following table describes each of the statuses an integration version can be in at a given time:

  • Name: The name of the status. Note: We use these status names mainly in the Stitch Docs - only versions in beta will have a beta flag in Stitch.
  • Status in API: The pipeline_state value the status corresponds to in the API. Contained in a details object, the pipeline_state attribute indicates the current version status of an integration.
  • Availability: Indicates the availability of the version in Stitch or the API:
    • Unavailable: The version isn’t available. New connections can’t be created.
    • Private: The version is available only to accounts who have been granted access.
    • Available: The version is generally available, depending on the plan type required for the integration. For example: If an integration is Advanced or Premium, only users of these plans will have access to it.
  • Description: A description of the status, including in-app and support availability
Name Status(es) in API Availability Description
Alpha alpha/beta Private
  • Available only to accounts that have been granted access

  • May be missing features, contain bugs, and/or change at any time

  • May also encompass ‘closed’ beta

Beta beta Available
  • Generally available in Stitch, but may not be ‘fully baked’

  • May be missing features, contain bugs, and/or change at any time

  • Support is available, but Enterprise SLAs don’t apply

Released released Available
  • Generally available in Stitch

  • Support is available depending on the integration’s Certified or Community support status

Released (Testing) released Available
  • Generally available in Stitch, but hasn’t been fully tested with a specific variant of the connection

    For example: Amazon PostgreSQL RDS databases can be connected using the PostgreSQL integration, but RDS connections may not have been specifically tested prior to releasing a new version for PostgreSQL.

Deprecated deprecated Unavailable
  • No longer available in Stitch

  • Existing connections will continue to function

  • Support is unavailable, even if the connection is Certified

Sunset deprecated Unavailable
  • No longer available in Stitch

  • Existing connections will no longer function

  • Support is unavailable, even if the connection is Certified


Identify an integration's version

To ensure you’re viewing the documentation for the correct version of your integration, you should first check its version in Stitch.

  1. Sign into your Stitch account.
  2. On the Stitch Dashboard page, click the integration you want to check.
  3. Click the Extraction Logs tab:
    • If you see No logs available for this integration yet., the version of the integration doesn’t support the Extraction Logs feature. Refer to the Legacy integration versions section below for more info.
    • If you see a list of Extraction Logs:

      Open the most recent set of logs and look at the first line:

      Integration version information highlighted in an integration's extraction logs

      The string following tap-<name> version is the version of the integration you’re using. In this example, that’s 1.0.8, which corresponds to v1.

      Note: Only major version identifiers are reflected in integration documentation, i.e. 1 versus 1.0.8.


Legacy integration versions

The integrations in the table below only have a single running version, which is listed in the table. When and if these integrations are converted to Singer taps, they will support Extraction Logs and you’ll be able to identify their version using the method above.

Integration Version Release date

Questions? Feedback?

Did this article help? If you have questions or feedback, feel free to submit a pull request with your suggestions, open an issue on GitHub, or reach out to us.