Custom Integrations
Custom integrations let you connect to any REST API and pull data into Resplendent Data—even if there’s no pre-built integration for it. You define the request, tell us how to parse the response, and we handle the syncing.
When to use custom integrations
Section titled “When to use custom integrations”Use a custom integration when:
- The API you need isn’t in the built-in integration gallery
- You have an internal API that exposes business data
- You want to pull data from a SaaS tool we don’t support yet
Accessing custom integrations
Section titled “Accessing custom integrations”- Click Custom Integrations in the sidebar
- You’ll see a table of all existing custom integrations with their names and descriptions
- Click Add to create a new one, or click the Edit button on an existing integration to modify it
Creating a custom integration
Section titled “Creating a custom integration”The integration editor is organized into four tabs: General, Request Config, Endpoints, and Sync Options. A live preview panel on the right side shows contextual information and lets you test your configuration as you build it.
General tab
Section titled “General tab”This tab covers the basics and authentication.
Integration information
Section titled “Integration information”| Field | Description |
|---|---|
| Name | A unique name to identify this integration |
| Description | A short summary of what data source this integration connects to |
User inputs
Section titled “User inputs”User inputs are the values that someone will fill in when they connect this integration (e.g., API keys, account IDs, subdomain names). Each input has:
| Property | Description |
|---|---|
| Name | Label shown to the user when connecting |
| Type | text, number, or boolean |
| Default Value | Optional pre-filled value |
| Placeholder | Optional hint text shown in the input field |
These input values can be referenced later in URL, header, body, and parameter configurations using the Connection Value part type.
Authentication
Section titled “Authentication”Choose how the integration authenticates with the target API:
| Auth Type | How it works |
|---|---|
| None | No authentication is added to requests |
| Basic | Sends a Base64-encoded username:password in the Authorization header. Select which user inputs map to the username and password fields |
| Bearer | Sends a token in the Authorization: Bearer <token> header. Select which user input provides the token |
| API Key | Sends a custom header with the API key value. Select which user input provides the key |
Request Config tab
Section titled “Request Config tab”This tab defines the base data request—the default HTTP request used when fetching data from each endpoint.
Building the request
Section titled “Building the request”| Setting | Description |
|---|---|
| HTTP Method | GET or POST |
| URL | Built from parts—combine static text with connection values (user inputs) |
| Headers | Key-value pairs added to every request |
| Body | Request body (typically for POST requests), built from key-value parts |
| URL Params | Query string parameters appended to the URL |
Each part of the URL, headers, body, and URL params can be either a static value (hardcoded text) or a connection value (references a user input defined on the General tab).
Base data response parsing
Section titled “Base data response parsing”This section defines how the response from data requests is parsed. Since the base data request fetches actual data rows, the output type is always tabular.
| Setting | Description |
|---|---|
| Response Type | JSON or CSV |
| Path to Tabular Data | For JSON responses, the dot-separated path to the array of records (e.g., data.results) |
| Flatten Values | If enabled, nested JSON objects within each row are flattened into top-level columns |
| Flatten Depth | How many levels deep to flatten (1–10) |
Endpoints tab
Section titled “Endpoints tab”Endpoints define which datasets (tables) are available from this integration. There are two approaches:
Request-based endpoints (dynamic)
Section titled “Request-based endpoints (dynamic)”The integration makes an API call to discover available endpoints at runtime. This is useful for APIs that expose a list of their own resources.
| Setting | Description |
|---|---|
| Use Base URL | Whether to prepend the base URL from the Request Config tab |
| Request configuration | HTTP method, URL, headers, body, and URL params for the discovery request |
| Response parsing (Label-ID List) | Parses the discovery response to extract a list of dataset names and IDs (see below) |
Label-ID list response parsing is used exclusively here—for parsing the response of the endpoint discovery request. It extracts a list of dataset identifiers from the API response:
| Setting | Description |
|---|---|
| Response Type | JSON or CSV |
| Path to Tabular Data | Dot-separated path to the array or object containing the endpoint list |
| Dataset Name/ID Path | Path to the field used as the endpoint identifier. Use $key if the identifier is the key in a key-value pair |
| Use Separate Label | Toggle on if the display name differs from the ID |
| Path to Dataset Label | Path to the human-readable name (only shown when “Use Separate Label” is enabled) |
Static endpoints (manual)
Section titled “Static endpoints (manual)”Manually define a fixed list of endpoints. Each static endpoint can optionally override the base request and response configuration:
| Setting | Description |
|---|---|
| Use default request config | When enabled, the endpoint inherits the base data request from the Request Config tab. When disabled, you can customize the HTTP method, URL, headers, body, and params for this specific endpoint |
| Dataset/Endpoint Name | The name for this dataset |
| Use base response config | When enabled, the endpoint uses the base response parsing. When disabled, you can customize response parsing per endpoint |
Test endpoint configuration
Section titled “Test endpoint configuration”Configure a test endpoint used to validate the integration connection. This lets users verify their credentials work before syncing. You can use the default request config or customize the test request separately.
Sync Options tab
Section titled “Sync Options tab”Configure how the integration handles large datasets and change detection.
Pagination
Section titled “Pagination”Enable pagination if the API returns data in pages.
| Setting | Description |
|---|---|
| Max Page Size | Maximum number of records per page |
| URL Parameters | Query params for pagination (e.g., page = page number) |
| Header Parameters | Pagination info sent via headers |
| Body Parameters | Pagination info sent in the request body |
Pagination parameters support dataset values in addition to static and connection values. The available dataset values for pagination are:
page_size— the configured max page sizepage_number— the current page number (auto-incremented)
Incremental updates
Section titled “Incremental updates”Enable incremental updates to only fetch records that have changed since the last sync, rather than pulling everything each time.
| Setting | Description |
|---|---|
| URL Parameters | Filter params for changed data (e.g., since = last sync timestamp) |
| Header Parameters | Change detection info sent via headers |
| Body Parameters | Change detection info sent in the request body |
Incremental update parameters support these dataset values:
last_update_value— the timestamp of the last successful syncsorting_column— the column used for ordering
Sorting
Section titled “Sorting”Enable sorting to ensure data is returned in a consistent order across paginated requests.
| Setting | Description |
|---|---|
| URL Parameters | Sort params (e.g., sort = column name) |
| Header Parameters | Sorting info sent via headers |
| Body Parameters | Sorting info sent in the request body |
Sorting parameters support these dataset values:
sorting_column— the column to sort byunique_key— the primary key column
Managing existing integrations
Section titled “Managing existing integrations”Editing an integration
Section titled “Editing an integration”From the Custom Integrations list, click the Edit button on any row to open it in the editor. The preview panel on the right shows a live summary of your configuration, including:
- General tab: Integration name, description, input count, and auth type
- Request Config tab: Full request preview with method, URL, headers, and a test case panel for validating response parsing
- Endpoints tab: Endpoint definition type and a list of configured endpoints (click a static endpoint to preview its response parser)
- Sync Options tab: Summary of enabled sync features (pagination, incremental updates, sorting)
Saving
Section titled “Saving”Click the Save Integration button in the top-right corner of the editor. The integration will be validated and saved.
How custom integrations appear
Section titled “How custom integrations appear”Once saved, your custom integration shows up as a connectable data source on the Data Settings → Integrations page alongside the built-in integrations. Users with the appropriate role can:
- Click Connect on the custom integration card
- Fill in the user inputs you defined (API keys, account IDs, etc.)
- Select which datasets/endpoints to sync
- Start syncing data into Resplendent Data
The synced data appears as regular datasets and can be used in widgets, modified datasets, and joined datasets just like any other data source.