Support custom kind (API endpoint) in out of the box integrations
exploring
M
Maya Margalit
Today, out of the box Ocean integrations come with a fixed set of predefined kinds.
When users want to ingest data from API endpoints that are not covered by those kinds, they either need to wait for Port to add a new kind or create a separate custom Ocean integration, including authentication and connection setup, even though they already have an existing integration configured.
This creates unnecessary friction and duplication. We should allow users to define custom kinds directly within out of the box Ocean integrations, reusing the existing authentication and connection that Port already manages, so they can fetch additional data from supported APIs without creating a new integration or waiting for Port to add more kinds
M
Maya Margalit
Merged in a post:
Custom Kinds for integrations
M
Matan Heled
When working with Kinds in the integration, you are chained to the set of kinds provided by the specific integration.
Occasionally, integrations have events which require specific filters constantly to work with, which sometimes also complicates the mapping, making it less clear what the purpose is.
For example, Jira.
Jira issues, bugs, epics etc are all categorised under the same kind,
issue
. It would be nice to be able to create a custom Kind called
bugs
, which is the issue
kind, pre-filtered with .type == 'bug'
.This functionality will be extra helpful for the webhook ingestion, since there are no "types" when ingesting data through a webhook endpoint. Allowing custom kinds will enable a similar experience when working with webhook and other integrations.
R
Richard Rein Jr
We are in the same boat for GitHub Copilot metrics - using the built-in GitHub Copilot integration for most of our usage data, and then a second custom integration hosted by Port to load billing/seat information from the GitHub Copilot user management endpoints. It would be nice to have this all bundled together and managed in one integration.
N
Niels Van Zwieten
We're currently using a separate Custom integration for this. For example, we'd like to ingest GitLab Users, but the gitlab-v2 integration doesn't support that out of the box. So we deploy and maintain a second Custom integration just for the /api/v4/users endpoint, duplicating authentication setup and adding operational overhead.
M
Maya Margalit
marked this post as
exploring