Content Packs Structure

For better separation between Content artifacts from different use cases and Partners we use a directory structure called Content Packs. Each Content Pack behaves like a mini content repo. It contains all relevant content items within its directory.

For instance a pack for CortexXDR will look as can be seen in the Content Repository Packs/CortexXDR.

To generate a new pack make sure to use: demisto-sdk init --pack. Detailed command instructions are available here.

Note: The Content repo is going through a transition phase to move all content into packs. During this phase you will see some Content artifacts are still not maintained within Packs. All new Content should be maintained via Packs.


All the directories within the pack are the representation of all the possible entities possible in Content. And the pack will be located in the Content repo under Packs/<Pack Name>

- Integrations
- Scripts
- Playbooks
- Reports
- Dashboards
- IncidentTypes
- IncidentFields
- Layouts
- Classifiers
- IndicatorTypes
- IndicatorFields
- Connections
- TestPlaybooks

Pack files#

The pack directory contains numerous configuration files used for metadata and documentation.

Please note that all of the following files will be created using the demisto-sdk init --pack, and some of them will have to be filled by you. An explanation for each of them will be provided below.


This file contains all the relevant metadata about the pack.

The following fields are populated in the pack metadata:

Field NameField TypeField Description
nameStringThe pack name. Usually it's the name of the integration the pack contains (e.g. CortexXDR) or the use-case implemented in it.
descriptionStringA short overview of the pack.
supportStringShould be one of the following:
1. xsoar - Supported by Cortex XSOAR.
2. partner - Supported by a Cortex XSOAR partner.
3. developer - Supported by an independent developer/organization.
4. community - Not officialy supported, but available for the community to use.
For partner and developer, either email address or URL fields must be filled out.
currentVersionStringThe pack version, in the format of x.x.x. On the initial release this should be set to "1.0.0".
authorStringThe name of the organization (for partners) or developer (for individual contributions) which developed the integration.
urlStringThe URL to which users should refer to in case of support needed regarding the pack. Usually is the organization support URL or the developer GitHub repository.
emailStringThe email address to which users should reach out to in case of support needed regarding the pack.
categoriesListThe use-case categories which are implemented in the pack. Usually set by the integration, which included in the pack category. Should be one of the following:
1. Analytics & SIEM
2. Utilities
3. Messaging
4. Endpoint
5. Network Security
6. Vulnerability Management
7. Case Management
8. Forensics & Malware Analysis
9. IT Services
10. Data Enrichment & Threat Intelligence
11. Authentication
12. Database
13. Deception
14. Email Gateway
tagsListTags to be attached to the pack on Cortex XSOAR marketplace.
createdStringPack creation time in ISO 8601 format - YYYY-MM-DDTHH:mm:ssZ, e.g. 2020-01-25T10:00:00Z
useCasesListUse-cases implemented by the pack.
keywordsListList of strings by which the pack can be found in Cortex XSOAR marketplace.
eulaLinkString(Optional - Premium packs only) URL referencing the pack license agreement, will appear under the 'Disclaimer' section in the pack details. Non-premium packs are hosted in the content repo and will be subject to the the MIT Licelse
dependenciesDictionary(Optional) An object that describes the content packs that the pack is dependant on. Should be kept empty on pack creation, as it is calculated by Cortex XSOAR content infrastructure.
displayedImagesList(Optional) Images to be displayed in Cortex XSOAR marketplace. Should be kept empty on pack creation, as it is calculated by Cortex XSOAR content infrastructure.
githubUserList(Optional) List of Github usernames to receive notification in the PR in case pack files were modified.
certificationString(Optional) If the pack is certifed the value of this fields should be "certified"

Pack metadata contents for example:

"name": "Palo Alto Networks Cortex XDR - Investigation and Response",
"description": "Cortex XDR is the world's first detection and response app that natively integrates network, endpoint and cloud data to stop sophisticated attacks.",
"support": "xsoar",
"currentVersion": "1.0.0",
"author": "Cortex XSOAR",
"url": "",
"email": "",
"categories": [
"tags": [
"Recommended by Cortex XSOAR",
"created": "2020-03-11T13:16:53Z",
"useCases": [
"keywords": [
"adaptive cyber protection",
"dependencies": {
"Base": {
"mandatory": true,
"name": "Base"
"CortexXDR": {
"mandatory": false,
"name": "Palo Alto Networks - Cortex XDR"
"displayedImages": [

A supported partner pack metadata contents for example:

"name": "Product name",
"description": "Pack description",
"support": "partner",
"currentVersion": "1.1.0",
"author": "Partner name",
"url": "https://support.<partner>.com",
"email": "support@<partner>.com",
"categories": [
"tags": [],
"created": "2020-03-19T09:39:30Z",
"useCases": [],
"keywords": [],
"dependencies": {},
"githubUser": [
"<partner Github username>"

The file contains a general explanation for the pack and you are free to add any information relevant for the pack. For more details refer to the Pack Documentation page.


This file will be used while running the demisto-sdk secrets(explanation), we will determine the file and will use it as a white list of approved words for your PR.

Note: We use demisto-sdk secrets as part of our pre-commit hook to check that possible secrets in the PR aren't exposed to a public repository.


This file allows ignoring linter errors while lint checking and ignoring tests in the test collection.

To add ignored tests/linter errors in a file, first, add the file name to the .pack-ignore in this format


On the following line add ignore= flag, with one or more comma-separated values:

  1. auto-test - ignore test file in the build test collection.
  2. linter code e.g. IN126 - ignore linter error codes.

Example .pack-ignore#



You may choose to show the pack author image such that it will be displayed in the marketplace under the PUBLISHER section when viewing the pack details. The image should be saved in the pack root level (i.e. content/packs/MyPackName/Author_image.png), make sure to stick with this file name for the image to appear. The image size should be up to 4kb and in the dimensions of 120x50.

In case file does not exist, the pack author will be displayed in text.

Last updated on