Integration development guidelines

This page provides development guidelines for implementing GitLab integrations, which are part of our main Rails project.

Also see our direction page for an overview of our strategy around integrations.

This guide is a work in progress. You’re welcome to ping @gitlab-org/manage/import-and-integrate if you need clarification or spot any outdated information.

Add a new integration

Define the integration

  1. Add a new model in app/models/integrations extending from Integration.
    • For example, Integrations::FooBar in app/models/integrations/foo_bar.rb.
    • For certain types of integrations, you can also build on these base classes:
      • Integrations::BaseChatNotification
      • Integrations::BaseCi
      • Integrations::BaseIssueTracker
      • Integrations::BaseMonitoring
      • Integrations::BaseSlashCommands
      • Integrations::BaseThirdPartyWiki
    • For integrations that primarily trigger HTTP calls to external services, you can also use the Integrations::HasWebHook concern. This reuses the webhook functionality in GitLab through an associated ServiceHook model, and automatically records request logs which can be viewed in the integration settings.
  2. Add the integration’s underscored name ('foo_bar') to Integration::INTEGRATION_NAMES.
  3. Add the integration as an association on Project:

    has_one :foo_bar_integration, class_name: 'Integrations::FooBar'

Define fields

Integrations can define arbitrary fields to store their configuration with the class method Integration.field. The values are stored as an encrypted JSON hash in the integrations.encrypted_properties column.

For example:

module Integrations
  class FooBar < Integration
    field :url
    field :tags

Integration.field installs accessor methods on the class. Here we would have #url, #url=, and #url_changed? to manage the url field. These accessors should access the fields stored in Integration#properties directly on the model, just like other ActiveRecord attributes.

You should always access the fields through their getters and not interact with the properties hash directly. You must not write to the properties hash, you must use the generated setter method instead. Direct writes to this hash are not persisted.

You should also define validations for all your properties. To see how these fields are exposed in the frontend form for the integration, see Customize the frontend form.

Other approaches include using Integration.prop_accessor or Integration.data_field, which you might see in earlier versions of integrations. You should not use these approaches for new integrations.

Define trigger events

Integrations are triggered by calling their #execute method in response to events in GitLab, which gets passed a payload hash with details about the event.

The supported events have some overlap with webhook events, and receive the same payload. You can specify the events you’re interested in by overriding the class method Integration.supported_events in your model.

The following events are supported for integrations:

Event typeDefaultValueTrigger
Alert event alertA a new, unique alert is recorded.
Commit eventcommitA commit is created or updated.
Deployment event deploymentA deployment starts or finishes.
Issue eventissueAn issue is created, updated, or closed.
Confidential issue eventconfidential_issueA confidential issue is created, updated, or closed.
Job event job 
Merge request eventmerge_requestA merge request is created, updated, or merged.
Comment event commentA new comment is added.
Confidential comment event confidential_noteA new comment on a confidential issue is added.
Pipeline event pipelineA pipeline status changes.
Push eventpushA push is made to the repository.
Tag push eventtag_pushNew tags are pushed to the repository.
Vulnerability event  vulnerabilityA new, unique vulnerability is recorded.
Wiki page eventwiki_pageA wiki page is created or updated.

Event examples

This example defines an integration that responds to commit and merge_request events:

module Integrations
  class FooBar < Integration
    def self.supported_events
      %w[commit merge_request]

An integration can also not respond to events, and implement custom functionality some other way:

module Integrations
  class FooBar < Integration
    def self.supported_events

Security enhancement features

Masking channel values

Integrations that inherit from Integrations::BaseChatNotification can hide the values of their channel input fields. Integrations should hide these values whenever the fields contain sensitive information such as auth tokens.

By default, #mask_configurable_channels? returns false. To mask the channel values, override the #mask_configurable_channels? method in the integration to return true:

override :mask_configurable_channels?
def mask_configurable_channels?

Define configuration test

Optionally, you can define a configuration test of an integration’s settings. The test is executed from the integration form’s Test button, and results are returned to the user.

A good configuration test:

  • Does not change data on the service. For example, it should not trigger a CI build. Sending a message is okay.
  • Is meaningful and as thorough as possible.

If it’s not possible to follow the above guidelines, consider not adding a configuration test.

To add a configuration test, define a #test method for the integration model.

The method receives data, which is a test push event payload. It should return a hash, containing the keys:

  • success (required): a boolean to indicate if the configuration test has passed.
  • result (optional): a message returned to the user if the configuration test has failed.

For example:

module Integrations
  class FooBar < Integration
    def test(data)
      success = test_api_key(data)

      { success: success, result: 'API key is invalid' }

Customize the frontend form

The frontend form is generated dynamically based on metadata defined in the model.

By default, the integration form provides:

  • A checkbox to enable or disable the integration.
  • Checkboxes for each of the trigger events returned from Integration#configurable_events.

You can also add help text at the top of the form by either overriding Integration#help, or providing a template in app/views/shared/integrations/$INTEGRATION_NAME/_help.html.haml.

To add your custom properties to the form, you can define the metadata for them in Integration#fields.

This method should return an array of hashes for each field, where the keys can be:

type:symboltrue:textThe type of the form field. Can be :text, :textarea, :password, :checkbox, or :select.
name:stringtrue The property name for the form field.
required:booleanfalsefalseSpecify if the form field is required or optional.
title:stringfalseCapitalized value of name: The label for the form field.
placeholder:stringfalse A placeholder for the form field.
help:stringfalse A help text that displays below the form field.
api_only:booleanfalsefalseSpecify if the field should only be available through the API, and excluded from the frontend form.
if:boolean or lambdafalsetrueSpecify if the field should be available. The value can be a boolean or a lambda.

Additional keys for type: :checkbox

checkbox_label:stringfalseValue of title: A custom label that displays next to the checkbox.

Additional keys for type: :select

choices:arraytrue A nested array of [label, value] tuples.

Additional keys for type: :password

non_empty_password_title:stringfalseValue of title: An alternative label that displays when a value is already stored.
non_empty_password_help:stringfalseValue of help: An alternative help text that displays when a value is already stored.

Frontend form examples

This example defines a required url field, and optional username and password fields:

module Integrations
  class FooBar < Integration
    field :url,
      type: :text,
      title: s_('FooBarIntegration|Server URL'),
      placeholder: '',
      required: true

    field :username,
      type: :text,
      title: s_('FooBarIntegration|Username')

    field :password,
      type: 'password',
      title: s_('FoobarIntegration|Password'
      non_empty_password_title: s_('FooBarIntegration|Enter new password')

Expose the integration in the REST API

To expose the integration in the REST API:

  1. Add the integration’s class (::Integrations::FooBar) to API::Helpers::IntegrationsHelpers.integration_classes.
  2. Add all properties that should be exposed to API::Helpers::IntegrationsHelpers.integrations.
  3. Update the reference documentation in doc/api/, add a new section for your integration, and document all properties.

You can also refer to our REST API style guide.

Sensitive fields are not exposed over the API. Sensitive fields are those fields that contain any of the following in their name:

  • key
  • passphrase
  • password
  • secret
  • token
  • webhook

Availability of integrations

By default, integrations are available on the project, group, and instance level. Most integrations only act in a project context, but can be still configured from the group and instance levels.

For some integrations it can make sense to only make it available on the project level. To do that, the integration must be removed from Integration::INTEGRATION_NAMES and added to Integration::PROJECT_SPECIFIC_INTEGRATION_NAMES instead.

When developing a new integration, we also recommend you gate the availability behind a feature flag in Integration.available_integration_names.


You can provide help text in the integration form, including links to off-site documentation, as described above in Customize the frontend form. Refer to our usability guidelines for help text.

For more detailed documentation, provide a page in doc/user/project/integrations, and link it from the Integrations overview.

You can also refer to our general documentation guidelines.


Testing should not be confused with defining configuration tests.

It is often sufficient to add tests for the integration model in spec/models/integrations, and a factory with example settings in spec/factories/integrations.rb.

Each integration is also tested as part of generalized tests. For example, there are feature specs that verify that the settings form is rendering correctly for all integrations.

If your integration implements any custom behavior, especially in the frontend, this should be covered by additional tests.

You can also refer to our general testing guidelines.


All UI strings should be prepared for translation by following our internationalization guidelines.

The strings should use the integration name as namespace, for example, s_('FooBarIntegration|My string').

Deprecate and remove an integration

To remove an integration, you must first deprecate the integration. For more information, see the feature deprecation guidelines.

Deprecate an integration

You must announce any deprecation no later than the third milestone preceding intended removal. To deprecate an integration:

Remove an integration

To safely remove an integration, you must stage the removal across two milestones.

In the major milestone of intended removal (M.0), disable the integration and delete the records from the database:

In the next minor release (M.1):

  • Remove the integration’s model and any remaining code.
  • Close any issues, merge requests, and epics that have the integration’s label (~Integration::<name>).
  • Delete the integration’s label (~Integration::<name>) from gitlab-org.

Ongoing migrations and refactorings

Developers should be aware that the Integrations team is in the process of unifying the way integration properties are defined.

Integration examples

You can refer to these issues for examples of adding new integrations:

  • Datadog: Metrics collector, similar to the Prometheus integration.
  • EWM/RTC: External issue tracker.
  • Shimo: External wiki, similar to the Confluence and External Wiki integrations.
  • Webex Teams: Chat notifications.
  • ZenTao: External issue tracker with custom issue views, similar to the Jira integration.