ENG-2491 - Add Connection Metadata for D&D

[RobertKeyser]

Ticket ENG-2491

Description Of Changes

This PR adds structured metadata to connection types that support data discovery and detection monitors, exposing this information through the connection types API endpoint. This allows API consumers and automated tooling to dynamically discover which connection types support which features without maintaining hardcoded lists

Rationale:

from the connection type API endpoint, I see the following for RDS Postgres, which supports Detection & Discovery as well as Access/Erasures.

    {
      "identifier": "rds_postgres",
      "type": "database",
      "human_readable": "RDS Postgres",
      "encoded_icon": null,
      "authorization_required": false,
      "user_guide": null,
      "supported_actions": [
        "access",
        "erasure"
      ],
      "category": null,
      "tags": null,
      "enabled_features": null
    }

Here's an example of a SaaS connection (pulls this data from the yaml)

    {
      "identifier": "braze",
      "type": "saas",
      "human_readable": "Braze",
      "encoded_icon": "...",
      "authorization_required": false,
      "user_guide": "https://docs.ethyca.com/user-guides/integrations/saas-integrations/braze",
      "supported_actions": [
        "access",
        "erasure"
      ],
      "category": "MARKETING",
      "tags": [
        "API",
        "DSR Automation"
      ],
      "enabled_features": [
        "DSR_AUTOMATION"
      ]
    },

It appears as though RDS Postgres doesn't support anything, but that's only because it isn't a SaaS type connection.

Code Changes

• Added ConnectionTypeMetadata dataclass in connectionconfig.py to represent connection type capabilities (category, tags, enabled features)
• Added connection_type_metadata property to ConnectionType enum that returns metadata for connection types supporting discovery/detection
• Created CONNECTION_TYPE_METADATA_MAPPING dictionary that maintains the authoritative list of connection types with discovery/detection support.
• Updated get_connection_types() utility to include discovery metadata fields (category, tags, enabled_features) in API responses
• Added Tests

Steps to Confirm

curl -X 'GET' \
  'http://localhost:8080/api/v1/connection_type?page=1&size=100' \
  -H 'accept: application/json' \
  -H 'Authorization: Bearer <ACCESS TOKEN>'

Pre-Merge Checklist

• Issue requirements met
• All CI pipelines succeeded
• CHANGELOG.md updated
  • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
  • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
  • Updates unreleased work already in Changelog, no new entry necessary
• UX feedback:
  • All UX related changes have been reviewed by a designer
  • No UX review needed
• Followup issues:
  • Followup issues created
  • No followup issues
• Database migrations:
  • Ensure that your downrev is up to date with the latest revision on main
  • Ensure that your downgrade() migration is correct and works
    • If a downgrade migration is not possible for this change, please call this out in the PR description!
  • No migrations
• Documentation:
  • Documentation complete, PR opened in fidesdocs
  • Documentation issue created in fidesdocs
  • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
  • No documentation updates required

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
fides-plus-nightly	Ignored	Preview	Feb 1, 2026 4:05pm
fides-privacy-center	Ignored		Feb 1, 2026 4:05pm

[greptile-apps]

Greptile Overview

Greptile Summary

This PR adds structured metadata to connection types that support data discovery and detection monitors, exposing category, tags, and enabled features through the connection types API endpoint.

What Changed:

• Created ConnectionTypeMetadata dataclass to encapsulate connection capabilities (category, tags, enabled features)
• Added connection_type_metadata property to the ConnectionType enum that returns metadata via lookup in CONNECTION_TYPE_METADATA_MAPPING
• Defined metadata for 14 connection types: 9 traditional databases (postgres, mysql, mssql, rds_postgres, rds_mysql, google_cloud_sql_postgres, google_cloud_sql_mysql, scylla, dynamodb), 2 data warehouses (snowflake, bigquery), 1 identity provider (okta), 1 website connector, and S3
• Updated get_connection_types() utility to include metadata fields in API responses via the _get_connection_type_metadata_fields() helper
• All tests updated to expect new schema fields and validate the 14 connection types with metadata

Key Insights:

• The mapping is documented to stay in sync with Fidesplus discovery monitors
• Frozen dataclass prevents accidental mutation of metadata
• Helper function performs single lookup to avoid repeated property access
• Connection types without discovery/detection support return None for metadata fields
• This is a breaking API schema change for the /api/v1/connection_type endpoint

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The implementation is clean, well-tested, and follows existing patterns. All 14 connection types are validated in tests, metadata is immutable (frozen dataclass), and the helper function optimizes lookup performance. No security concerns or logic errors found.
• No files require special attention

Important Files Changed

Filename	Overview
src/fides/api/models/connectionconfig.py	Added ConnectionTypeMetadata dataclass and mapping for 14 connection types that support data discovery/detection
src/fides/api/util/connection_type.py	Added helper function to extract metadata fields and integrate them into API responses for database connection types
tests/ops/models/test_connectionconfig.py	Added comprehensive test validating metadata property returns correct values for all 14 discovery-enabled connection types

[greptile-apps]

_{3 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

_{3 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[adamsachs]

this generally looks good and fills an important gap we've had!

i've got a few things to think about, i don't think these are blockers, but they're probably worth us digging into while we're here, because realistically it may be a while before anyone returns!

1. my main concern with a static map like this is that someone will forget to update it if/when they add a new connection type. can you think of a mechanism or a tweak so that we can ensure a metadata mapping is defined if/when someone adds a new ConnectionType? ideally this lives as far upstream as possible: via a static check is best (but that can be difficult here/and in python generally), next best would be somewhere in the app code that throws a runtime error on module initialization so that server startup would fail, and then last fallback would be a test that fails. i know you have some test coverage for this functionality, but i don't think it'd actually fail if a new connection type was added and no mapping was provided - right? (apologies if i've missed a safeguard you already have in place for this!)
2. generally it'd be nice for us to leverage this API response in the FE, so that we don't have multiple sources of truth across the codebase. that's probably a bigger LOE than we want to take on in this particular PR, but can we make a followup task for this and/or get some buy-in from the FE team on this being a sound approach?
3. as noted in the inline comments, seems like we may want some additional annotations for enabled_features? maybe i've misunderstood how that field is meant to work though

let me know if you've got questions!

[adamsachs]

nit/maybe doesn't belong here, since i know this is already represented as "Discovery" in the UI...but on the original definitions of 'detection' and 'discovery', i'd expect this to be classified only as 'detection'. 'discovery' was specifically to refer to data classification...

i'm fine keeping this as-is to be consistent with what the UI shows now, but more than anything, i think this should just prompt us to re-visit whether we really should be distinguishing between 'detection' and 'discovery' still, since i think that has always been confusing, and we've really eliminated the distinction in the action center now (there are no distinct 'detection' and 'discovery' phases for datastore monitors).

[adamsachs]

question: are the integration features meant to be mutually exclusive? if not, then i'd expect to also see DSR_AUTOMATION on many of these, right?

Suggested change

	enabled_features=[IntegrationFeature.DATA_DISCOVERY],
	enabled_features=[IntegrationFeature.DATA_DISCOVERY, IntegrationFeature.DSR_AUTOMATION],