# Integrations for Building your Catalog

> Manage HTTP, AWS, and other integrations that power catalog data sources and workflow source nodes.

*Published: 2026-04-09*


## Overview

**Integrations** are reusable connection definitions—credentials, base URLs, and provider-specific settings—that **data sources** use when fetching data. 

They are the same integration system used across Roadie’s catalog tooling, so you configure them once and reference them from multiple sources or workflows.

From the **Integrations** overview you can browse, search, and filter integrations; create new ones; and edit or remove existing definitions (subject to permissions).

![integration-list(./integration-list.webp)]

## How they fit the pipeline

1. Create an **integration** for the system you need to reach (for example, an HTTP API or AWS API) using the `+ New` button on the Integrations page. Integrations require Names, Slugs, Connections, and Authentication options.
2. Use that integration in a **[data source](/docs/catalog/building-your-catalog/data-sources/)** so scheduled syncs can write objects into the datastore.

For HTTP-style access patterns elsewhere in Roadie (proxies, authenticated requests from plugins), see also the general [HTTP integration](/docs/integrations/http/) documentation. Integrations used when Building your Catalog are configured in the dedicated **Integrations** UI for data sources and workflows.

![integration-new(./integration-new.webp)]

## Advanced options on an Integration

Additional settings can be attached to an Integration.

### Additional headers

These header names are available when you add extra headers on an integration (for example `Authorization`, API keys, tracing, or caching):

| Option             | Detail                                                                                                   |
| ------------------ | -------------------------------------------------------------------------------------------------------- |
| `authorization`    | Sends credentials such as Bearer tokens, Basic auth, or vendor-specific schemes.                         |
| `x-api-key`        | Sends an API key in a header, a pattern used by many HTTP gateways and SaaS APIs.                        |
| `x-auth-token`     | Sends an alternate token-style credential when the upstream expects this header instead of `Authorization`. |
| `content-type`     | Declares the MIME type of the request body (for example `application/json`).                             |
| `accept`           | Tells the server which response content types the client can handle.                                     |
| `x-request-id`     | Unique id for a single request, useful for log correlation on the receiving service.                       |
| `x-correlation-id` | Shared id across related calls in a workflow, for distributed tracing.                                   |
| `cache-control`    | Directives that influence caching between clients, proxies, and origin.                                  |
| `if-none-match`    | Conditional request using an entity tag, often for efficient polling with `304 Not Modified`.            |
| `x-forwarded-for`  | Conveys the original client IP when the request passes through proxies or load balancers.                |
| `x-custom-header`  | Arbitrary vendor-specific header name and value beyond the presets above.                               |

- Rate limits can be added to limit requests and set a burst capacity.
- A CA Certificate can be attached

## Permissions

Creating, updating, and deleting integrations is gated by integration permissions. Restrict these to administrators or platform engineers who are allowed to manage outbound credentials and endpoints.

## Further reading

- [Building your Catalog — overview](/docs/catalog/building-your-catalog/)
- [Data sources](/docs/catalog/building-your-catalog/data-sources/)
- [Workflows to create entities](/docs/catalog/building-your-catalog/workflows/)
- [HTTP integration](/docs/integrations/http/)