Overview

This page walks you through the files that you need to populate in order to create an offering on the Integrations page or the Marketplace page.

Configuration file

When preparing a new integration, you must include an example configuration that contains the necessary options and reasonable defaults. The example configuration file—which in this case, is located at <CHECK_NAME>/datadog_checks/<CHECK_NAME>/data/conf.yaml.example—has two top-level elements: init_config and instances.

The configuration under init_config is applied to the integration globally, and is used in every instantiation of the integration, whereas anything within instances is specific to a given instantiation.

Configuration blocks in either section take the following form:

## @<COMMAND> [- <ARGS>]
## <DESCRIPTION LINE 1>
## <DESCRIPTION LINE 2>
#
<KEY>: <VALUE>

Configuration blocks follow a few guidelines:

• Descriptions must not be empty.
• Always follow this format: <THIS_IS_A_PLACEHOLDER> for placeholders. For more information, see the Documentation Site’s contributing guidelines.
• All required parameters are not commented by default.
• All optional parameters are commented by default.
• If a placeholder has a default value for an integration (like the status endpoint of an integration), it can be used instead of a generic placeholder.

@param specification

You can use the @param command to describe configuration blocks and provide documentation for your configuration.

@param is implemented using one of the following forms:

@param <name> - <type> - required
@param <name> - <type> - optional
@param <name> - <type> - optional - default: <defval>

Arguments:

• name: The name of the parameter, such as search_string (mandatory).
• type: The data type for the parameter value (mandatory). Possible values include the following: boolean, string, integer, double, float, dictionary, list*, and object*.
• defval: Default value for the parameter; can be empty (optional).

list and object variables span over multiple lines and have special rules.

• In a list, individual elements are not documented with the @param specification.
• In an object, you can choose to either document elements individually with the @param specification or have a common top-level description following the specification of the object itself.

Optional parameters

An optional parameter must be commented by default. Before every line the parameter spans on, add # with the same indentation as the @param specification.

Block comments

You can add a block comment anywhere in the configuration file with the following rules:

• Comments start with ##.
• Comments should be indented like any variable (the hyphen doesn’t count).

For more information about YAML syntax, see the Wikipedia article about YAML. You can also explore the Online YAML Parser.

Manifest file

Every offering on the Integrations page or the Marketplace page contains a manifest.json file that defines operating parameters, positioning within the greater Datadog integration ecosystem, and additional metadata.

You can find the complete list of mandatory and optional attributes for the manifest.json file below:

Classifier tags

You can set multiple categories and define submitted or queried data types for the integration using the classifier_tags parameter.

You can find the complete list of classifier tags for the manifest.json file below:

Service check file

The service_check.json file describes the service checks made by the integration.

You can find the complete list of mandatory attributes for the service_checks.json file below:

Metrics metadata file

The metadata.csv file describes all of the metrics that can be collected by the integration.

You can find the complete list of mandatory and optional attributes for the metadata.csv file below:

Further Reading

Additional helpful documentation, links, and articles:

Contributing Guidelines for the Documentation SiteSOURCE CODE Learn about creating an Agent or API-based integrationDOCUMENTATION Learn about using OAuth for integrationsDOCUMENTATION