Zephyr Cloud REST API

Zephyr Cloud is SmartBear’s test management solution for Jira Cloud. The v2 REST API provides access to test cases, test cycles, test executions, folders, environments, statuses, and priorities.

Overview
Setup Guide
Permissions
Troubleshooting

Connect Parable to Zephyr Cloud using a single API access token. Parable ingests test cases, test cycles, execution results, and step-level data across all Jira projects accessible to the token.

Test execution data

Test cycles, executions, and step-level results

Test definition data

Test cases and their step definitions

Data streams

This Provider Plugin defines 14 data streams.

Stream	Description	Sync
`testcases`	Extracts all test cases across all Jira projects accessible to the token.	full
`testcycles`	Extracts all test cycles across all Jira projects accessible to the token.	full
`testexecutions`	Extracts all test executions across all Jira projects.	full
`testcase_steps`	Extracts test step definitions for each test case in the `testcases` stream.	full
`testexecution_steps`	Extracts test step execution results for each test execution in the `testexecutions` stream.	full
`folders`	Extracts all folders used to organize test cases, test cycles, and test plans across all projects.	full
`projects`	Extracts all Jira projects that have Zephyr Cloud enabled.	full
`environments`	Extracts all test environments defined across all projects.	full
`testplans`	Extracts all test plans across all projects.	full
`statuses`	Extracts all test result and test case statuses defined across all projects.	full
`priorities`	Extracts all test case priority levels defined across all projects.	full
`testcase_versions`	Extracts version history snapshots for each test case in the `testcases` stream.	full
`testcase_links`	Extracts Jira issue links for each test case in the `testcases` stream.	full
`testcase_weblinks`	Extracts external web links for each test case in the `testcases` stream.	full

Zephyr Cloud

What You’ll Need

Credential	What it is
API Access Token	A token generated from your Jira Cloud profile under Zephyr API Access Tokens

A Jira Cloud account with Zephyr Cloud installed.
Your account must have permission to access test data in at least one Jira project.

Step 1: Open Zephyr API Access Tokens

Sign in to Jira Cloud.
Click your profile icon in the top-right corner.
Select Zephyr API Access Tokens from the dropdown menu.

Tip: You can also navigate directly to your Jira Cloud instance and look for “Zephyr API Access Tokens” in your profile menu.

Step 2: Create a new access token

Click Create access token.
Give the token a descriptive name (e.g. “Parable integration”).
Copy the generated token immediately.

Warning: Copy your API access token now! This is the only time it will be displayed. Store it in a secure password manager before closing this page.

Warning: The token is shown only once at creation time. If you navigate away without copying it, you must create a new token.

Step 3: Connect in Parable

In Parable, open Platform → Providers and choose the Provider to add.
Select Zephyr Cloud.
Paste your API Access Token.
Click Save & verify.

Environments

Developer identifier: environmentsEnvironments contain all test environments defined across all projects.

Enables: interpret test executions against their configured test environment.
Scope: Reads every record from GET /v2/environments on each sync. Results contain only Zephyr records returned for Jira projects accessible to the configured API token.

Description

Developer identifier: environments.descriptionDescription records description of the environment. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact description value attached to each environment record.
Interpretation: The provider supplies description at environment granularity in the format stated by its description; omitted or redacted content remains unknown.

Developer identifier: environments.idID is the unique internal identifier of the environment. It is the record key, so rows with the same value describe the same record.

Enables: identify each environment record across syncs.
Interpretation: The provider supplies id at one value per environment record, and it is the record key.

Name

Developer identifier: environments.nameName records display name of the environment (e.g., Production, Staging). It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact name value attached to each environment record.
Interpretation: The provider supplies name at environment granularity in the format stated by its description; omitted or redacted content remains unknown.

Project

Developer identifier: environments.projectProject records Jira project reference; Cloud v2 returns a nested {id, self} object. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by project on a environment record.
Interpretation: The provider supplies project as a URL or resource locator on each environment record. Availability still follows the provider’s permissions and retention.

Developer identifier: environments.project.idID reports the numeric project ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match environment records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: environments.project.selfSelf records self URL of the project resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a environment record.
Interpretation: The provider supplies self as a URL or resource locator on each environment record. Availability still follows the provider’s permissions and retention.

Folders

Developer identifier: foldersFolders contain all folders used to organize test cases, test cycles, and test plans across all projects.

Enables: reconstruct folders used to organize test cases, cycles, and plans.
Scope: Reads every record from GET /v2/folders on each sync. Results contain only Zephyr records returned for Jira projects accessible to the configured API token.

Folder Type

Developer identifier: folders.folderTypeFolder Type states type of objects in this folder: TEST_CASE, TEST_CYCLE, or TEST_PLAN. It preserves the provider’s current classification of this record.

Enables: separate folder records by the exact provider-reported folder type value when describing their recorded state.
Interpretation: The provider supplies folderType per folder record using its own state vocabulary; unknown and missing values must remain distinct.

Developer identifier: folders.idID is the unique internal identifier of the folder. It is the record key, so rows with the same value describe the same record.

Enables: identify each folder record across syncs.
Interpretation: The provider supplies id at one value per folder record, and it is the record key.

Name

Developer identifier: folders.nameName records display name of the folder. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact name value attached to each folder record.
Interpretation: The provider supplies name at folder granularity in the format stated by its description; omitted or redacted content remains unknown.

Parent ID

Developer identifier: folders.parentIdParent ID reports the numeric ID of the parent folder; null if root-level. It is needed to resolve references that repeat the same provider identifier.

Enables: match folder records to provider records that carry the same parent ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies parentId as a record-level identifier. Its values are not guaranteed to be unique.

Project

Developer identifier: folders.projectProject records Jira project reference ({id, self}). It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by project on a folder record.
Interpretation: The provider supplies project as a URL or resource locator on each folder record. Availability still follows the provider’s permissions and retention.

Developer identifier: folders.project.idID reports the numeric project ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match folder records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: folders.project.selfSelf records self URL of the project resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a folder record.
Interpretation: The provider supplies self as a URL or resource locator on each folder record. Availability still follows the provider’s permissions and retention.

Priorities

Developer identifier: prioritiesPriorities contain all test case priority levels defined across all projects.

Enables: interpret test-case priority identifiers using provider-defined labels.
Scope: Reads every record from GET /v2/priorities on each sync. Results contain only Zephyr records returned for Jira projects accessible to the configured API token.

Color

Developer identifier: priorities.colorColor records color code associated with the priority for UI display. It preserves the provider’s visual treatment for the represented object.

Enables: reproduce or compare the provider-supplied color for the represented design or board object.
Interpretation: The provider supplies color in its own color, opacity, stroke, emoji, or style vocabulary for the represented object.

Default

Developer identifier: priorities.defaultDefault indicates whether this is the default priority. It preserves the provider-reported yes-or-no condition for this record.

Enables: select priority records for which the provider reports default as true or false.
Interpretation: The provider supplies default as a boolean per priority record; false and missing are distinct when the field is optional.

Description

Developer identifier: priorities.descriptionDescription records description of the priority level. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact description value attached to each priority record.
Interpretation: The provider supplies description at priority granularity in the format stated by its description; omitted or redacted content remains unknown.

Developer identifier: priorities.idID is the unique internal identifier of the priority. It is the record key, so rows with the same value describe the same record.

Enables: identify each priority record across syncs.
Interpretation: The provider supplies id at one value per priority record, and it is the record key.

Name

Developer identifier: priorities.nameName records display name of the priority (e.g., High, Medium, Low). It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact name value attached to each priority record.
Interpretation: The provider supplies name at priority granularity in the format stated by its description; omitted or redacted content remains unknown.

Project

Developer identifier: priorities.projectProject records Jira project reference; Cloud v2 returns a nested {id, self} object. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by project on a priority record.
Interpretation: The provider supplies project as a URL or resource locator on each priority record. Availability still follows the provider’s permissions and retention.

Developer identifier: priorities.project.idID reports the numeric project ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match priority records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: priorities.project.selfSelf records self URL of the project resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a priority record.
Interpretation: The provider supplies self as a URL or resource locator on each priority record. Availability still follows the provider’s permissions and retention.

Projects

Developer identifier: projectsProjects contain all Jira projects that have Zephyr Cloud enabled.

Enables: enumerate Jira projects for which Zephyr Cloud returns a project record.
Scope: Reads every record from GET /v2/projects on each sync. Results contain only Zephyr records returned for Jira projects accessible to the configured API token.

Description

Developer identifier: projects.descriptionDescription records description of the project. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact description value attached to each project record.
Interpretation: The provider supplies description at project granularity in the format stated by its description; omitted or redacted content remains unknown.

Enabled

Developer identifier: projects.enabledEnabled indicates whether Zephyr Cloud is enabled for this project. It preserves the provider-reported yes-or-no condition for this record.

Enables: select project records for which the provider reports enabled as true or false.
Interpretation: The provider supplies enabled as a boolean per project record; false and missing are distinct when the field is optional.

Developer identifier: projects.idID is the unique internal identifier of the project. It is the record key, so rows with the same value describe the same record.

Enables: identify each project record across syncs.
Interpretation: The provider supplies id at one value per project record, and it is the record key.

Jira Project ID

Developer identifier: projects.jiraProjectIdJira Project ID reports the numeric Jira project ID, the matching key to Jira project data. It is needed to resolve references that repeat the same provider identifier.

Enables: match project records to provider records that carry the same jira project ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies jiraProjectId as a record-level identifier. Its values are not guaranteed to be unique.

Key

Developer identifier: projects.keyKey identifies Jira project key (e.g., PROJ). It is needed to resolve references that repeat the same provider identifier.

Enables: match project records to provider records that carry the same key, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies key as a record-level identifier. Its values are not guaranteed to be unique.

Name

Developer identifier: projects.nameName records name of the project. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact name value attached to each project record.
Interpretation: The provider supplies name at project granularity in the format stated by its description; omitted or redacted content remains unknown.

Statuses

Developer identifier: statusesStatuses contain all test result and test case statuses defined across all projects.

Enables: interpret test case and execution status identifiers using provider-defined labels.
Scope: Reads every record from GET /v2/statuses on each sync. Results contain only Zephyr records returned for Jira projects accessible to the configured API token.

Color

Developer identifier: statuses.colorColor records color code associated with the status for UI display. It preserves the provider’s visual treatment for the represented object.

Enables: reproduce or compare the provider-supplied color for the represented design or board object.
Interpretation: The provider supplies color in its own color, opacity, stroke, emoji, or style vocabulary for the represented object.

Default

Developer identifier: statuses.defaultDefault indicates whether this is the default status for its type. It preserves the provider-reported yes-or-no condition for this record.

Enables: select status records for which the provider reports default as true or false.
Interpretation: The provider supplies default as a boolean per status record; false and missing are distinct when the field is optional.

Description

Developer identifier: statuses.descriptionDescription records description of the status. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact description value attached to each status record.
Interpretation: The provider supplies description at status granularity in the format stated by its description; omitted or redacted content remains unknown.

Developer identifier: statuses.idID is the unique internal identifier of the status. It is the record key, so rows with the same value describe the same record.

Enables: identify each status record across syncs.
Interpretation: The provider supplies id at one value per status record, and it is the record key.

Name

Developer identifier: statuses.nameName records display name of the status (e.g., Pass, Fail, Draft). It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact name value attached to each status record.
Interpretation: The provider supplies name at status granularity in the format stated by its description; omitted or redacted content remains unknown.

Project

Developer identifier: statuses.projectProject records Jira project reference; Cloud v2 returns a nested {id, self} object. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by project on a status record.
Interpretation: The provider supplies project as a URL or resource locator on each status record. Availability still follows the provider’s permissions and retention.

Developer identifier: statuses.project.idID reports the numeric project ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match status records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: statuses.project.selfSelf records self URL of the project resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a status record.
Interpretation: The provider supplies self as a URL or resource locator on each status record. Availability still follows the provider’s permissions and retention.

Type

Developer identifier: statuses.typeType states type of object this status applies to: TEST_CASE, TEST_CYCLE, or TEST_EXECUTION. It preserves the provider’s current classification of this record.

Enables: separate status records by the exact provider-reported type value when describing their recorded state.
Interpretation: The provider supplies type per status record using its own state vocabulary; unknown and missing values must remain distinct.

Testcase Links

Developer identifier: testcase_linksTestcase Links contain Jira issue links associated with each test case. Parable reads them for each test case in the Testcases stream.

Enables: associate test cases with the Jira issue links returned by Zephyr.
Scope: Reads every record from GET /v2/testcases/{testCaseKey}/links on each sync. Results contain only Zephyr records returned for Jira projects accessible to the configured API token.

Developer identifier: testcase_links.idID is the unique internal identifier of the link. It is the record key, so rows with the same value describe the same record.

Enables: identify each test case link record across syncs.
Interpretation: The provider supplies id at one value per test case link record, and it is the record key.

Issue ID

Developer identifier: testcase_links.issueIdIssue ID identifies Jira issue ID linked to this test case. It is needed to resolve references that repeat the same provider identifier.

Enables: match testcase link records to provider records that carry the same issue ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies issueId as a record-level identifier. Its values are not guaranteed to be unique.

Test Case Key

Developer identifier: testcase_links.testCaseKeyTest Case Key identifies the key of the parent record in testcases, and Parable copies it from that record. Zephyr Cloud does not return this value with the record. It is needed to resolve references that repeat the same provider identifier.

Enables: match testcase link records to provider records that carry the same test case key, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies testCaseKey as a record-level identifier. Its values are not guaranteed to be unique.

Type

Developer identifier: testcase_links.typeType states link type: COVERAGE, BLOCKS, or RELATED. It preserves the provider’s current classification of this record.

Enables: separate testcase link records by the exact provider-reported type value when describing their recorded state.
Interpretation: The provider supplies type per test case link record using its own state vocabulary; unknown and missing values must remain distinct.

Testcase Steps

Developer identifier: testcase_stepsTestcase Steps contain test step definitions for each test case. Parable reads them for each test case in the Testcases stream.

Enables: inspect ordered test-step definitions for each parent test case.
Scope: Reads every record from GET /v2/testcases/{testCaseKey}/teststeps on each sync. Results contain only Zephyr records returned for Jira projects accessible to the configured API token.

Developer identifier: testcase_steps.idID identifies the step. Parable builds it from the parent testCaseKey and the position of the step, because Zephyr Cloud returns no step ID that is unique across test cases. It is the record key, so rows with the same value describe the same record.

Enables: identify each test case step record across syncs.
Interpretation: Parable generates id at one value per test case step record, and it is the record key.

Index

Developer identifier: testcase_steps.indexIndex reports zero-based ordinal position of this step within its test case. It preserves the stated measure at this record’s granularity.

Enables: order or classify testcase step records using the provider-defined index value.
Interpretation: The provider supplies index at test case step granularity as a provider-defined ordinal or planning value rather than elapsed time or money; zero and missing are not interchangeable.

Inline

Developer identifier: testcase_steps.inlineInline records inline step definition; Cloud v2 nests step content under this envelope. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact inline value attached to each test case step record.
Interpretation: The provider supplies inline at test case step granularity in the format stated by its description; omitted or redacted content remains unknown.

Custom Fields

Developer identifier: testcase_steps.inline.customFieldsCustom Fields records custom field values as a key-value map. It holds configured attributes whose keys and shapes can vary.

Enables: interpret custom fields according to the provider and Workspace configuration that produced each testcase step record.
Interpretation: Keys and value shapes within customFields can vary with provider and customer configuration. Check the keys in your Workspace’s data rather than assume a fixed set.

Description

Developer identifier: testcase_steps.inline.descriptionDescription records step description / action to perform. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact description value attached to each test case step record.
Interpretation: The provider supplies description at test case step granularity in the format stated by its description; omitted or redacted content remains unknown.

Expected Result

Developer identifier: testcase_steps.inline.expectedResultExpected Result records expected result for this step. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact expected result value attached to each test case step record.
Interpretation: The provider supplies expectedResult at test case step granularity in the format stated by its description; omitted or redacted content remains unknown.

Test Data

Developer identifier: testcase_steps.inline.testDataTest Data records test data associated with this step. It keeps this specific test data attribute attached to the test case step record.

Enables: compare the provider-defined test data values across testcase step records using the meaning stated in the field description.
Interpretation: The provider supplies testData once per test case step record as string. Missing and explicit values remain distinct when the field is optional.

Test Case Key

Developer identifier: testcase_steps.testCaseKeyTest Case Key identifies the key of the parent record in testcases, and Parable copies it from that record. Zephyr Cloud does not return this value with the record. It is needed to resolve references that repeat the same provider identifier.

Enables: match testcase step records to provider records that carry the same test case key, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies testCaseKey as a record-level identifier. Its values are not guaranteed to be unique.

Testcase Versions

Developer identifier: testcase_versionsTestcase Versions contain version history snapshots for each test case. Parable reads them for each test case in the Testcases stream.

Enables: compare the provider-returned version snapshots of each test case.
Scope: Reads every record from GET /v2/testcases/{testCaseKey}/versions on each sync. Results contain only Zephyr records returned for Jira projects accessible to the configured API token.

Created On

Developer identifier: testcase_versions.createdOnCreated On records ISO 8601 timestamp when this version was created. It anchors the named event or boundary on the record’s timeline.

Enables: place testcase version records on a timeline by created on and select the records within an explicit reporting window.
Interpretation: The provider supplies createdOn per test case version record as a timestamp at the precision returned by the provider; missing values mean the event or boundary was not reported.

Developer identifier: testcase_versions.idID is the unique internal identifier of the test case version. It is the record key, so rows with the same value describe the same record.

Enables: identify each test case version record across syncs.
Interpretation: The provider supplies id at one value per test case version record, and it is the record key.

Self

Developer identifier: testcase_versions.selfSelf records self URL of the version resource. The versions endpoint returns links that hold only an ID, not the full test case version. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test case version record.
Interpretation: The provider supplies self as a URL or resource locator on each test case version record. Availability still follows the provider’s permissions and retention.

Test Case Key

Developer identifier: testcase_versions.testCaseKeyTest Case Key identifies the key of the parent record in testcases, and Parable copies it from that record. Zephyr Cloud does not return this value with the record. It is needed to resolve references that repeat the same provider identifier.

Enables: match testcase version records to provider records that carry the same test case key, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies testCaseKey as a record-level identifier. Its values are not guaranteed to be unique.

Testcase Weblinks

Developer identifier: testcase_weblinksTestcase Weblinks contain external web links associated with each test case. Parable reads them for each test case in the Testcases stream.

Enables: retain the external web links attached to each test case.
Scope: Reads every record from GET /v2/testcases/{testCaseKey}/links on each sync. Results contain only Zephyr records returned for Jira projects accessible to the configured API token.

Description

Developer identifier: testcase_weblinks.descriptionDescription records display description of the web link. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact description value attached to each test case web link record.
Interpretation: The provider supplies description at test case web link granularity in the format stated by its description; omitted or redacted content remains unknown.

Developer identifier: testcase_weblinks.idID is the unique internal identifier of the web link. It is the record key, so rows with the same value describe the same record.

Enables: identify each test case web link record across syncs.
Interpretation: The provider supplies id at one value per test case web link record, and it is the record key.

Test Case Key

Developer identifier: testcase_weblinks.testCaseKeyTest Case Key identifies the key of the parent record in testcases, and Parable copies it from that record. Zephyr Cloud does not return this value with the record. It is needed to resolve references that repeat the same provider identifier.

Enables: match testcase weblink records to provider records that carry the same test case key, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies testCaseKey as a record-level identifier. Its values are not guaranteed to be unique.

Type

Developer identifier: testcase_weblinks.typeType states link type: COVERAGE, BLOCKS, or RELATED. It preserves the provider’s current classification of this record.

Enables: separate testcase weblink records by the exact provider-reported type value when describing their recorded state.
Interpretation: The provider supplies type per test case web link record using its own state vocabulary; unknown and missing values must remain distinct.

URL

Developer identifier: testcase_weblinks.urlURL records URL of the linked resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by URL on a test case web link record.
Interpretation: The provider supplies url as a URL or resource locator on each test case web link record. Availability still follows the provider’s permissions and retention.

Testcases

Developer identifier: testcasesTestcases contain all test cases across all Jira projects accessible to the token.

Enables: review test-case definitions across token-visible Jira projects.
Scope: Reads every record from GET /v2/testcases/nextgen on each sync. Results contain only Zephyr records returned for Jira projects accessible to the configured API token.

Component

Developer identifier: testcases.componentComponent records Jira component reference ({id, self}). It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by component on a test case record.
Interpretation: The provider supplies component as a URL or resource locator on each test case record. Availability still follows the provider’s permissions and retention.

Developer identifier: testcases.component.idID reports the numeric component ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match test case records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testcases.component.selfSelf records self URL of the component resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test case record.
Interpretation: The provider supplies self as a URL or resource locator on each test case record. Availability still follows the provider’s permissions and retention.

Created By ID

Developer identifier: testcases.createdByIdCreated By ID identifies atlassian account ID of the user who created the test case. It is needed to resolve references that repeat the same provider identifier.

Enables: match test case records to provider records that carry the same created by ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies createdById as a record-level identifier. Its values are not guaranteed to be unique.

Created On

Developer identifier: testcases.createdOnCreated On records ISO 8601 timestamp when the test case was created. It anchors the named event or boundary on the record’s timeline.

Enables: place test case records on a timeline by created on and select the records within an explicit reporting window.
Interpretation: The provider supplies createdOn per test case record as a timestamp at the precision returned by the provider; missing values mean the event or boundary was not reported.

Custom Fields

Developer identifier: testcases.customFieldsCustom Fields records custom field values as a key-value map. It holds configured attributes whose keys and shapes can vary.

Enables: interpret custom fields according to the provider and Workspace configuration that produced each test case record.
Interpretation: Keys and value shapes within customFields can vary with provider and customer configuration. Check the keys in your Workspace’s data rather than assume a fixed set.

Estimated Time

Developer identifier: testcases.estimatedTimeEstimated Time reports the planned test-case execution duration in milliseconds. It preserves the provider’s effort estimate in an explicit unit.

Enables: compare planned execution time across test cases and schedule testing capacity.
Interpretation: The provider supplies estimatedTime as an integer duration in milliseconds, not an ordinal or sequence; zero and missing are not interchangeable.

Folder

Developer identifier: testcases.folderFolder records containing folder reference ({id, self}). It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by folder on a test case record.
Interpretation: The provider supplies folder as a URL or resource locator on each test case record. Availability still follows the provider’s permissions and retention.

Developer identifier: testcases.folder.idID reports the numeric folder ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match test case records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testcases.folder.selfSelf records self URL of the folder resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test case record.
Interpretation: The provider supplies self as a URL or resource locator on each test case record. Availability still follows the provider’s permissions and retention.

Developer identifier: testcases.idID is the unique internal identifier of the test case. It is the record key, so rows with the same value describe the same record.

Enables: identify each test case record across syncs.
Interpretation: The provider supplies id at one value per test case record, and it is the record key.

Key

Developer identifier: testcases.keyKey identifies human-readable key (e.g. SA-T10). It is needed to resolve references that repeat the same provider identifier.

Enables: match test case records to provider records that carry the same key, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies key as a record-level identifier. Its values are not guaranteed to be unique.

Labels

Developer identifier: testcases.labelsLabels records labels applied to the test case. It preserves the containing or referenced object needed to reconstruct the provider relationship.

Enables: apply the provider-defined labels classifications to each test case record.
Interpretation: The provider returns labels as a list; an absent value does not prove that no related object exists outside the credential’s visibility.

Name

Developer identifier: testcases.nameName records name/title of the test case. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact name value attached to each test case record.
Interpretation: The provider supplies name at test case granularity in the format stated by its description; omitted or redacted content remains unknown.

Objective

Developer identifier: testcases.objectiveObjective records objective or purpose of the test case (may contain HTML). It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact objective value attached to each test case record.
Interpretation: The provider supplies objective at test case granularity in the format stated by its description; omitted or redacted content remains unknown.

Owner

Developer identifier: testcases.ownerOwner records test case owner reference; Cloud v2 returns {self, accountId}. It keeps the provider-reported person or account context attached to the record.

Enables: attribute the test case record to the provider-reported actor represented by owner.
Interpretation: The provider supplies owner as identity or attribution context on each test case record. Names and contact values can change and are not stable identifiers unless the provider documents them as such.

Account ID

Developer identifier: testcases.owner.accountIdAccount ID identifies atlassian account ID of the owner. It is needed to resolve references that repeat the same provider identifier.

Enables: match test case records to provider records that carry the same account ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies accountId as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testcases.owner.selfSelf records self URL of the owner resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test case record.
Interpretation: The provider supplies self as a URL or resource locator on each test case record. Availability still follows the provider’s permissions and retention.

Precondition

Developer identifier: testcases.preconditionPrecondition records preconditions required before executing this test case (may contain HTML). It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact precondition value attached to each test case record.
Interpretation: The provider supplies precondition at test case granularity in the format stated by its description; omitted or redacted content remains unknown.

Priority

Developer identifier: testcases.priorityPriority states test case priority reference ({id, self}). It preserves the provider’s current classification of this record.

Enables: separate test case records by the exact provider-reported priority value when describing their recorded state.
Interpretation: The provider supplies priority per test case record using its own state vocabulary; unknown and missing values must remain distinct.

Developer identifier: testcases.priority.idID reports the numeric priority ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match test case records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testcases.priority.selfSelf records self URL of the priority resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test case record.
Interpretation: The provider supplies self as a URL or resource locator on each test case record. Availability still follows the provider’s permissions and retention.

Project

Developer identifier: testcases.projectProject records Jira project reference; Cloud v2 returns a nested {id, self} object. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by project on a test case record.
Interpretation: The provider supplies project as a URL or resource locator on each test case record. Availability still follows the provider’s permissions and retention.

Developer identifier: testcases.project.idID reports the numeric project ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match test case records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testcases.project.selfSelf records self URL of the project resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test case record.
Interpretation: The provider supplies self as a URL or resource locator on each test case record. Availability still follows the provider’s permissions and retention.

Status

Developer identifier: testcases.statusStatus states test case status reference ({id, self}). It preserves the provider’s current classification of this record.

Enables: separate test case records by the exact provider-reported status value when describing their recorded state.
Interpretation: The provider supplies status per test case record using its own state vocabulary; unknown and missing values must remain distinct.

Developer identifier: testcases.status.idID reports the numeric status ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match test case records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testcases.status.selfSelf records self URL of the status resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test case record.
Interpretation: The provider supplies self as a URL or resource locator on each test case record. Availability still follows the provider’s permissions and retention.

Updated On

Developer identifier: testcases.updatedOnUpdated On records ISO 8601 timestamp when the test case was last updated. It anchors the named event or boundary on the record’s timeline.

Enables: place test case records on a timeline by updated on and select the records within an explicit reporting window.
Interpretation: The provider supplies updatedOn per test case record as a timestamp at the precision returned by the provider; missing values mean the event or boundary was not reported.

Testcycles

Developer identifier: testcyclesTestcycles contain all test cycles across all Jira projects accessible to the token.

Enables: organize test executions by their Zephyr test cycles.
Scope: Reads every record from GET /v2/testcycles on each sync. Results contain only Zephyr records returned for Jira projects accessible to the configured API token.

Created On

Developer identifier: testcycles.createdOnCreated On records ISO 8601 timestamp when the test cycle was created. It anchors the named event or boundary on the record’s timeline.

Enables: place testcycle records on a timeline by created on and select the records within an explicit reporting window.
Interpretation: The provider supplies createdOn per test cycle record as a timestamp at the precision returned by the provider; missing values mean the event or boundary was not reported.

Custom Fields

Developer identifier: testcycles.customFieldsCustom Fields records custom field values as a key-value map. It holds configured attributes whose keys and shapes can vary.

Enables: interpret custom fields according to the provider and Workspace configuration that produced each testcycle record.
Interpretation: Keys and value shapes within customFields can vary with provider and customer configuration. Check the keys in your Workspace’s data rather than assume a fixed set.

Description

Developer identifier: testcycles.descriptionDescription records description of the test cycle. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact description value attached to each test cycle record.
Interpretation: The provider supplies description at test cycle granularity in the format stated by its description; omitted or redacted content remains unknown.

Folder

Developer identifier: testcycles.folderFolder records containing folder reference ({id, self}). It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by folder on a test cycle record.
Interpretation: The provider supplies folder as a URL or resource locator on each test cycle record. Availability still follows the provider’s permissions and retention.

Developer identifier: testcycles.folder.idID reports the numeric folder ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match testcycle records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testcycles.folder.selfSelf records self URL of the folder resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test cycle record.
Interpretation: The provider supplies self as a URL or resource locator on each test cycle record. Availability still follows the provider’s permissions and retention.

Developer identifier: testcycles.idID is the unique internal identifier of the test cycle. It is the record key, so rows with the same value describe the same record.

Enables: identify each test cycle record across syncs.
Interpretation: The provider supplies id at one value per test cycle record, and it is the record key.

Jira Project Version

Developer identifier: testcycles.jiraProjectVersionJira Project Version records Jira fix-version reference ({id, self}). It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by jira project version on a test cycle record.
Interpretation: The provider supplies jiraProjectVersion as a URL or resource locator on each test cycle record. Availability still follows the provider’s permissions and retention.

Developer identifier: testcycles.jiraProjectVersion.idID reports the numeric Jira fix-version ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match testcycle records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testcycles.jiraProjectVersion.selfSelf records self URL of the Jira fix-version resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test cycle record.
Interpretation: The provider supplies self as a URL or resource locator on each test cycle record. Availability still follows the provider’s permissions and retention.

Key

Developer identifier: testcycles.keyKey identifies human-readable key (e.g. SA-R40). It is needed to resolve references that repeat the same provider identifier.

Enables: match testcycle records to provider records that carry the same key, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies key as a record-level identifier. Its values are not guaranteed to be unique.

Name

Developer identifier: testcycles.nameName records name of the test cycle. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact name value attached to each test cycle record.
Interpretation: The provider supplies name at test cycle granularity in the format stated by its description; omitted or redacted content remains unknown.

Owner

Developer identifier: testcycles.ownerOwner records test cycle owner reference ({self, accountId}). It keeps the provider-reported person or account context attached to the record.

Enables: attribute the test cycle record to the provider-reported actor represented by owner.
Interpretation: The provider supplies owner as identity or attribution context on each test cycle record. Names and contact values can change and are not stable identifiers unless the provider documents them as such.

Account ID

Developer identifier: testcycles.owner.accountIdAccount ID identifies atlassian account ID of the owner. It is needed to resolve references that repeat the same provider identifier.

Enables: match testcycle records to provider records that carry the same account ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies accountId as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testcycles.owner.selfSelf records self URL of the owner resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test cycle record.
Interpretation: The provider supplies self as a URL or resource locator on each test cycle record. Availability still follows the provider’s permissions and retention.

Planned End Date

Developer identifier: testcycles.plannedEndDatePlanned End Date records planned end date (ISO 8601). It anchors the named event or boundary on the record’s timeline.

Enables: place testcycle records on a timeline by planned end date and select the records within an explicit reporting window.
Interpretation: The provider supplies plannedEndDate per test cycle record as a timestamp at the precision returned by the provider; missing values mean the event or boundary was not reported.

Planned Start Date

Developer identifier: testcycles.plannedStartDatePlanned Start Date records planned start date (ISO 8601). It anchors the named event or boundary on the record’s timeline.

Enables: place testcycle records on a timeline by planned start date and select the records within an explicit reporting window.
Interpretation: The provider supplies plannedStartDate per test cycle record as a timestamp at the precision returned by the provider; missing values mean the event or boundary was not reported.

Project

Developer identifier: testcycles.projectProject records Jira project reference ({id, self}). It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by project on a test cycle record.
Interpretation: The provider supplies project as a URL or resource locator on each test cycle record. Availability still follows the provider’s permissions and retention.

Developer identifier: testcycles.project.idID reports the numeric project ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match testcycle records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testcycles.project.selfSelf records self URL of the project resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test cycle record.
Interpretation: The provider supplies self as a URL or resource locator on each test cycle record. Availability still follows the provider’s permissions and retention.

Status

Developer identifier: testcycles.statusStatus states test cycle status reference ({id, self}). It preserves the provider’s current classification of this record.

Enables: separate testcycle records by the exact provider-reported status value when describing their recorded state.
Interpretation: The provider supplies status per test cycle record using its own state vocabulary; unknown and missing values must remain distinct.

Developer identifier: testcycles.status.idID reports the numeric status ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match testcycle records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testcycles.status.selfSelf records self URL of the status resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test cycle record.
Interpretation: The provider supplies self as a URL or resource locator on each test cycle record. Availability still follows the provider’s permissions and retention.

Updated On

Developer identifier: testcycles.updatedOnUpdated On records ISO 8601 timestamp when the test cycle was last updated. It anchors the named event or boundary on the record’s timeline.

Enables: place testcycle records on a timeline by updated on and select the records within an explicit reporting window.
Interpretation: The provider supplies updatedOn per test cycle record as a timestamp at the precision returned by the provider; missing values mean the event or boundary was not reported.

Testexecution Steps

Developer identifier: testexecution_stepsTestexecution Steps contain test step execution results for each test execution. Parable reads them for each test execution in the Testexecutions stream.

Enables: compare expected and actual step results for each parent test execution.
Scope: Reads every record from GET /v2/testexecutions/{testExecutionKey}/teststeps on each sync. Results contain only Zephyr records returned for Jira projects accessible to the configured API token.

Actual Result

Developer identifier: testexecution_steps.actualResultActual Result records actual result recorded by the tester. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact actual result value attached to each test execution step record.
Interpretation: The provider supplies actualResult at test execution step granularity in the format stated by its description; omitted or redacted content remains unknown.

Developer identifier: testexecution_steps.idID identifies the step. Parable builds it from the parent testExecutionKey and the position of the step, because Zephyr Cloud returns no step ID that is unique across test executions. It is the record key, so rows with the same value describe the same record.

Enables: identify each test execution step record across syncs.
Interpretation: Parable generates id at one value per test execution step record, and it is the record key.

Index

Developer identifier: testexecution_steps.indexIndex reports zero-based ordinal position of this step within its execution. It preserves the stated measure at this record’s granularity.

Enables: order or classify testexecution step records using the provider-defined index value.
Interpretation: The provider supplies index at test execution step granularity as a provider-defined ordinal or planning value rather than elapsed time or money; zero and missing are not interchangeable.

Inline

Developer identifier: testexecution_steps.inlineInline records inline step definition; Cloud v2 nests step content under this envelope. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact inline value attached to each test execution step record.
Interpretation: The provider supplies inline at test execution step granularity in the format stated by its description; omitted or redacted content remains unknown.

Description

Developer identifier: testexecution_steps.inline.descriptionDescription records step description / action. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact description value attached to each test execution step record.
Interpretation: The provider supplies description at test execution step granularity in the format stated by its description; omitted or redacted content remains unknown.

Expected Result

Developer identifier: testexecution_steps.inline.expectedResultExpected Result records expected result for this step. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact expected result value attached to each test execution step record.
Interpretation: The provider supplies expectedResult at test execution step granularity in the format stated by its description; omitted or redacted content remains unknown.

Test Data

Developer identifier: testexecution_steps.inline.testDataTest Data records test data for this step. It keeps this specific test data attribute attached to the test execution step record.

Enables: compare the provider-defined test data values across testexecution step records using the meaning stated in the field description.
Interpretation: The provider supplies testData once per test execution step record as string. Missing and explicit values remain distinct when the field is optional.

Status

Developer identifier: testexecution_steps.statusStatus states step result status reference ({id, self}). It preserves the provider’s current classification of this record.

Enables: separate testexecution step records by the exact provider-reported status value when describing their recorded state.
Interpretation: The provider supplies status per test execution step record using its own state vocabulary; unknown and missing values must remain distinct.

Developer identifier: testexecution_steps.status.idID reports the numeric status ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match testexecution step records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testexecution_steps.status.selfSelf records self URL of the status resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test execution step record.
Interpretation: The provider supplies self as a URL or resource locator on each test execution step record. Availability still follows the provider’s permissions and retention.

Test Execution Key

Developer identifier: testexecution_steps.testExecutionKeyTest Execution Key identifies the key of the parent record in testexecutions, and Parable copies it from that record. Zephyr Cloud does not return this value with the record. It is needed to resolve references that repeat the same provider identifier.

Enables: match testexecution step records to provider records that carry the same test execution key, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies testExecutionKey as a record-level identifier. Its values are not guaranteed to be unique.

Testexecutions

Developer identifier: testexecutionsTestexecutions contain all test executions across all Jira projects.

Enables: measure recorded test outcomes by case, cycle, environment, and execution time.
Scope: Reads every record from GET /v2/testexecutions/nextgen on each sync. Results contain only Zephyr records returned for Jira projects accessible to the configured API token.

Actual End Date

Developer identifier: testexecutions.actualEndDateActual End Date records ISO 8601 timestamp when the execution completed. It anchors the named event or boundary on the record’s timeline.

Enables: place testexecution records on a timeline by actual end date and select the records within an explicit reporting window.
Interpretation: The provider supplies actualEndDate per test execution record as a timestamp at the precision returned by the provider; missing values mean the event or boundary was not reported.

Assigned To

Developer identifier: testexecutions.assignedToAssigned To records user assigned to execute the test ({self, accountId}). It keeps the provider-reported person or account context attached to the record.

Enables: attribute the test execution record to the provider-reported person or account represented by assigned to.
Interpretation: The provider supplies assignedTo as identity or attribution context on each test execution record. Names and contact values can change and are not stable identifiers unless the provider documents them as such.

Account ID

Developer identifier: testexecutions.assignedTo.accountIdAccount ID identifies atlassian account ID of the assignee. It is needed to resolve references that repeat the same provider identifier.

Enables: match testexecution records to provider records that carry the same account ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies accountId as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testexecutions.assignedTo.selfSelf records self URL of the assignee resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test execution record.
Interpretation: The provider supplies self as a URL or resource locator on each test execution record. Availability still follows the provider’s permissions and retention.

Automated

Developer identifier: testexecutions.automatedAutomated indicates whether this execution was automated. It preserves the provider-reported yes-or-no condition for this record.

Enables: select testexecution records for which the provider reports automated as true or false.
Interpretation: The provider supplies automated as a boolean per test execution record; false and missing are distinct when the field is optional.

Comment

Developer identifier: testexecutions.commentComment records comment added to this execution. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact comment value attached to each test execution record.
Interpretation: The provider supplies comment at test execution granularity in the format stated by its description; omitted or redacted content remains unknown.

Created On

Developer identifier: testexecutions.createdOnCreated On records ISO 8601 timestamp when the execution record was created. It anchors the named event or boundary on the record’s timeline.

Enables: place testexecution records on a timeline by created on and select the records within an explicit reporting window.
Interpretation: The provider supplies createdOn per test execution record as a timestamp at the precision returned by the provider; missing values mean the event or boundary was not reported.

Custom Fields

Developer identifier: testexecutions.customFieldsCustom Fields records custom field values as a key-value map. It holds configured attributes whose keys and shapes can vary.

Enables: interpret custom fields according to the provider and Workspace configuration that produced each testexecution record.
Interpretation: Keys and value shapes within customFields can vary with provider and customer configuration. Check the keys in your Workspace’s data rather than assume a fixed set.

Environment

Developer identifier: testexecutions.environmentEnvironment states execution environment reference ({id, self}). It preserves the provider’s current classification of this record.

Enables: separate testexecution records by the exact provider-reported environment value when describing their recorded state.
Interpretation: The provider supplies environment per test execution record using its own state vocabulary; unknown and missing values must remain distinct.

Developer identifier: testexecutions.environment.idID reports the numeric environment ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match testexecution records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testexecutions.environment.selfSelf records self URL of the environment resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test execution record.
Interpretation: The provider supplies self as a URL or resource locator on each test execution record. Availability still follows the provider’s permissions and retention.

Estimated Time

Developer identifier: testexecutions.estimatedTimeEstimated Time reports the planned test-execution duration in milliseconds. It preserves the expected effort attached to the execution.

Enables: compare planned duration with actual execution time and identify executions that exceed their estimate.
Interpretation: The provider supplies estimatedTime as an integer duration in milliseconds, not an ordinal or sequence; zero and missing are not interchangeable.

Executed By

Developer identifier: testexecutions.executedByExecuted By records user who executed the test ({self, accountId}). It keeps the provider-reported person or account context attached to the record.

Enables: attribute the test execution record to the provider-reported person or account represented by executed by.
Interpretation: The provider supplies executedBy as identity or attribution context on each test execution record. Names and contact values can change and are not stable identifiers unless the provider documents them as such.

Account ID

Developer identifier: testexecutions.executedBy.accountIdAccount ID identifies atlassian account ID of the executor. It is needed to resolve references that repeat the same provider identifier.

Enables: match testexecution records to provider records that carry the same account ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies accountId as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testexecutions.executedBy.selfSelf records self URL of the executor resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test execution record.
Interpretation: The provider supplies self as a URL or resource locator on each test execution record. Availability still follows the provider’s permissions and retention.

Execution Time

Developer identifier: testexecutions.executionTimeExecution Time reports the actual test-execution duration in milliseconds. It preserves elapsed execution time in an explicit unit.

Enables: compare actual duration with the estimate and identify unusually slow test executions.
Interpretation: The provider supplies executionTime as an integer duration in milliseconds; zero and missing are not interchangeable.

Developer identifier: testexecutions.idID is the unique internal identifier of the test execution. It is the record key, so rows with the same value describe the same record.

Enables: identify each test execution record across syncs.
Interpretation: The provider supplies id at one value per test execution record, and it is the record key.

Jira Project Version

Developer identifier: testexecutions.jiraProjectVersionJira Project Version records Jira fix-version reference ({id, self}). It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by jira project version on a test execution record.
Interpretation: The provider supplies jiraProjectVersion as a URL or resource locator on each test execution record. Availability still follows the provider’s permissions and retention.

Developer identifier: testexecutions.jiraProjectVersion.idID reports the numeric Jira fix-version ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match testexecution records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testexecutions.jiraProjectVersion.selfSelf records self URL of the Jira fix-version resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test execution record.
Interpretation: The provider supplies self as a URL or resource locator on each test execution record. Availability still follows the provider’s permissions and retention.

Key

Developer identifier: testexecutions.keyKey identifies human-readable key (e.g. SA-E10). It is needed to resolve references that repeat the same provider identifier.

Enables: match testexecution records to provider records that carry the same key, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies key as a record-level identifier. Its values are not guaranteed to be unique.

Project

Developer identifier: testexecutions.projectProject records Jira project reference ({id, self}). It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by project on a test execution record.
Interpretation: The provider supplies project as a URL or resource locator on each test execution record. Availability still follows the provider’s permissions and retention.

Developer identifier: testexecutions.project.idID reports the numeric project ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match testexecution records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testexecutions.project.selfSelf records self URL of the project resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test execution record.
Interpretation: The provider supplies self as a URL or resource locator on each test execution record. Availability still follows the provider’s permissions and retention.

Status

Developer identifier: testexecutions.statusStatus states execution status reference ({id, self}). It preserves the provider’s current classification of this record.

Enables: separate testexecution records by the exact provider-reported status value when describing their recorded state.
Interpretation: The provider supplies status per test execution record using its own state vocabulary; unknown and missing values must remain distinct.

Developer identifier: testexecutions.status.idID reports the numeric status ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match testexecution records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testexecutions.status.selfSelf records self URL of the status resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test execution record.
Interpretation: The provider supplies self as a URL or resource locator on each test execution record. Availability still follows the provider’s permissions and retention.

Test Case

Developer identifier: testexecutions.testCaseTest Case records executed test case reference ({id, self}). It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by test case on a test execution record.
Interpretation: The provider supplies testCase as a URL or resource locator on each test execution record. Availability still follows the provider’s permissions and retention.

Developer identifier: testexecutions.testCase.idID reports the numeric test case ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match testexecution records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testexecutions.testCase.selfSelf records self URL of the test case resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test execution record.
Interpretation: The provider supplies self as a URL or resource locator on each test execution record. Availability still follows the provider’s permissions and retention.

Test Cycle

Developer identifier: testexecutions.testCycleTest Cycle records parent test cycle reference ({id, self}). It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by test cycle on a test execution record.
Interpretation: The provider supplies testCycle as a URL or resource locator on each test execution record. Availability still follows the provider’s permissions and retention.

Developer identifier: testexecutions.testCycle.idID reports the numeric test cycle ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match testexecution records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testexecutions.testCycle.selfSelf records self URL of the test cycle resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test execution record.
Interpretation: The provider supplies self as a URL or resource locator on each test execution record. Availability still follows the provider’s permissions and retention.

Updated On

Developer identifier: testexecutions.updatedOnUpdated On records ISO 8601 timestamp when the execution record was last updated. It anchors the named event or boundary on the record’s timeline.

Enables: place testexecution records on a timeline by updated on and select the records within an explicit reporting window.
Interpretation: The provider supplies updatedOn per test execution record as a timestamp at the precision returned by the provider; missing values mean the event or boundary was not reported.

Testplans

Developer identifier: testplansTestplans contain all test plans across all projects.

Enables: organize related test cycles under Zephyr test plans.
Scope: Reads every record from GET /v2/testplans on each sync. Results contain only Zephyr records returned for Jira projects accessible to the configured API token.

Created On

Developer identifier: testplans.createdOnCreated On records ISO 8601 timestamp when the test plan was created. It anchors the named event or boundary on the record’s timeline.

Enables: place testplan records on a timeline by created on and select the records within an explicit reporting window.
Interpretation: The provider supplies createdOn per test plan record as a timestamp at the precision returned by the provider; missing values mean the event or boundary was not reported.

Custom Fields

Developer identifier: testplans.customFieldsCustom Fields records project-defined custom fields on the test plan. It holds configured attributes whose keys and shapes can vary.

Enables: interpret custom fields according to the provider and Workspace configuration that produced each testplan record.
Interpretation: Keys and value shapes within customFields can vary with provider and customer configuration. Check the keys in your Workspace’s data rather than assume a fixed set.

Folder

Developer identifier: testplans.folderFolder records folder reference ({id, self}). It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by folder on a test plan record.
Interpretation: The provider supplies folder as a URL or resource locator on each test plan record. Availability still follows the provider’s permissions and retention.

Developer identifier: testplans.folder.idID reports the numeric folder ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match testplan records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testplans.folder.selfSelf records self URL of the folder resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test plan record.
Interpretation: The provider supplies self as a URL or resource locator on each test plan record. Availability still follows the provider’s permissions and retention.

Developer identifier: testplans.idID is the unique internal identifier of the test plan. It is the record key, so rows with the same value describe the same record.

Enables: identify each test plan record across syncs.
Interpretation: The provider supplies id at one value per test plan record, and it is the record key.

Key

Developer identifier: testplans.keyKey identifies human-readable key. It is needed to resolve references that repeat the same provider identifier.

Enables: match testplan records to provider records that carry the same key, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies key as a record-level identifier. Its values are not guaranteed to be unique.

Labels

Developer identifier: testplans.labelsLabels records labels attached to the test plan. It preserves the containing or referenced object needed to reconstruct the provider relationship.

Enables: apply the provider-defined labels classifications to each test plan record.
Interpretation: The provider returns labels as a list; an absent value does not prove that no related object exists outside the credential’s visibility.

Name

Developer identifier: testplans.nameName records name of the test plan. It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact name value attached to each test plan record.
Interpretation: The provider supplies name at test plan granularity in the format stated by its description; omitted or redacted content remains unknown.

Objective

Developer identifier: testplans.objectiveObjective records objective of the test plan (Cloud v2 field; not description). It keeps the exact text, label, or authored value needed to interpret the record.

Enables: inspect the exact objective value attached to each test plan record.
Interpretation: The provider supplies objective at test plan granularity in the format stated by its description; omitted or redacted content remains unknown.

Owner

Developer identifier: testplans.ownerOwner records owner reference ({accountId, self}). It keeps the provider-reported person or account context attached to the record.

Enables: attribute the test plan record to the provider-reported actor represented by owner.
Interpretation: The provider supplies owner as identity or attribution context on each test plan record. Names and contact values can change and are not stable identifiers unless the provider documents them as such.

Account ID

Developer identifier: testplans.owner.accountIdAccount ID identifies atlassian account ID of the owner. It is needed to resolve references that repeat the same provider identifier.

Enables: match testplan records to provider records that carry the same account ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies accountId as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testplans.owner.selfSelf records self URL of the user resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test plan record.
Interpretation: The provider supplies self as a URL or resource locator on each test plan record. Availability still follows the provider’s permissions and retention.

Project

Developer identifier: testplans.projectProject records Jira project reference; Cloud v2 returns a nested {id, self} object. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by project on a test plan record.
Interpretation: The provider supplies project as a URL or resource locator on each test plan record. Availability still follows the provider’s permissions and retention.

Developer identifier: testplans.project.idID reports the numeric project ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match testplan records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testplans.project.selfSelf records self URL of the project resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test plan record.
Interpretation: The provider supplies self as a URL or resource locator on each test plan record. Availability still follows the provider’s permissions and retention.

Status

Developer identifier: testplans.statusStatus states test plan status reference ({id, self}). It preserves the provider’s current classification of this record.

Enables: separate testplan records by the exact provider-reported status value when describing their recorded state.
Interpretation: The provider supplies status per test plan record using its own state vocabulary; unknown and missing values must remain distinct.

Developer identifier: testplans.status.idID reports the numeric status ID. It is needed to resolve references that repeat the same provider identifier.

Enables: match testplan records to provider records that carry the same ID, without assuming that this field alone makes every row unique.
Interpretation: The provider supplies id as a record-level identifier. Its values are not guaranteed to be unique.

Self

Developer identifier: testplans.status.selfSelf records self URL of the status resource. It retains the exact provider location for the referenced resource.

Enables: open or trace the exact provider resource referenced by self on a test plan record.
Interpretation: The provider supplies self as a URL or resource locator on each test plan record. Availability still follows the provider’s permissions and retention.

Updated On

Developer identifier: testplans.updatedOnUpdated On records ISO 8601 timestamp when the test plan was last updated. It anchors the named event or boundary on the record’s timeline.

Enables: place testplan records on a timeline by updated on and select the records within an explicit reporting window.
Interpretation: The provider supplies updatedOn per test plan record as a timestamp at the precision returned by the provider; missing values mean the event or boundary was not reported.

Validation fails immediately after entering the token

Confirm you copied the full token without leading or trailing whitespace.
The token may have been revoked. Return to the Zephyr API Access Tokens page and create a new one.
Ensure your Jira account has access to at least one project with Zephyr Cloud data.

Some projects show no data

Zephyr access is scoped to Jira project permissions. The account that generated the token must have at least Browse Projects permission in every project you want to ingest.

Rate limit errors during initial sync

Zephyr Cloud enforces rate limits per token. Parable automatically respects retry delays. A large initial sync across many projects may take longer than expected — no action required.

The testcases or testcycles stream has no records

Confirm that test cases and cycles exist in your Jira projects. If Zephyr Cloud has no test data, these streams have no records.

​Test execution data

​Test definition data

​Data streams

​Zephyr Cloud

​What You’ll Need

​Step 1: Open Zephyr API Access Tokens

​Step 2: Create a new access token

​Step 3: Connect in Parable

Test execution data

Test definition data

Data streams

Zephyr Cloud

What You’ll Need

Step 1: Open Zephyr API Access Tokens

Step 2: Create a new access token

Step 3: Connect in Parable