Skip to main content

MicroStrategy

Overview​

MicroStrategy is an enterprise business intelligence platform for building governed dossiers, dashboards, reports, cubes, metrics, and attributes over business data.

The DataHub integration for MicroStrategy ingests projects and folders as containers, dossiers/documents as dashboards, visualizations as charts, and embedded dashboard datasets/cubes as datasets with schema fields derived from MicroStrategy metrics, attributes, and attribute forms. It can also ingest MicroStrategy reports as chart entities with report-scoped source datasets when extract_reports is enabled. The connector records project source warehouse/source type summaries when datasource APIs are available.

Lineage is emitted from datasets to visualizations and report source datasets to reports through ChartInfo.inputs and ChartInfo.inputEdges when the connector can resolve bindings from definitions or runtime details. When metadata exposes metric and attribute references, the connector also emits chart InputFields for the fields used by each visualization or report. Direct dashboard dataset edges are disabled by default because large BI dashboards can reference many datasets and make lineage graphs noisy; set emit_dashboard_dataset_edges: true only when dashboard-level fallback lineage is preferred. Coarse table-level warehouse lineage from SQL-view APIs is also disabled by default; set extract_warehouse_lineage: true for dashboard dataset -> warehouse table edges or extract_report_sql_lineage: true for report source dataset -> warehouse table edges before field-level metric, attribute, or fact lineage is available.

Concept Mapping​

MicroStrategy ConceptDataHub ConceptNotes
ProjectContainer (Project subtype)Project-scoped APIs require X-MSTR-ProjectID.
FolderContainer (Folder subtype)Created when search results expose folder or location context.
Dossier / document / dashboardDashboard (Dossier subtype)Dashboard metadata is read from dossier/document definition APIs.
VisualizationChart (Visualization subtype)Chart lineage uses ChartInfo.inputs, inputEdges, and chart InputFields when dataset and field IDs can be mapped.
ReportChart (Report subtype)Optional via extract_reports; report lineage uses a report-scoped source dataset.
Dashboard dataset / cubeDataset (MicroStrategy Dataset subtype)Schema fields come from embedded availableObjects.
Report source datasetDataset (MicroStrategy Dataset subtype)Schema fields come from report definition availableObjects.
Source warehouse / datasourceCustom properties and optional upstream lineageSQL-view APIs provide opt-in coarse physical table lineage when available.
MetricSchema field with Measure tagMetric IDs are preserved in field jsonProps.
Attribute / formSchema field with Dimension tagDate/time forms also receive the Temporal tag.
OwnerCorpUser ownershipEmitted when owner fields are exposed and ingest_owner is enabled.
Metric / attribute glossaryField glossary terms from explicit config mapsThe connector does not create glossary terms automatically.

Module microstrategy​

Incubating

Important Capabilities​

CapabilityStatusNotes
Asset Containers✅Projects and folders emit as containers.
Column-level Lineage✅Modeling API field lineage from MicroStrategy metrics and attributes to source warehouse fields.
Dataset Usage✅Dashboard and report usage from the Platform Analytics cube when extract_usage_statistics is enabled.
Descriptions✅Enabled by default.
Detect Deleted Entities✅Enabled via stateful ingestion.
Extract Ownership✅Enabled by default via ingest_owner.
Extract Tags✅Metric, attribute, and temporal field tags.
Platform Instance✅Enabled by default.
Schema Metadata✅Enabled by default.
Table-Level Lineage✅Visualization and report inputs when resolvable.
Test Connection✅Enabled by default.

Overview​

MicroStrategy is an enterprise business intelligence platform for building governed dossiers, dashboards, reports, cubes, metrics, and attributes over business data.

This source ingests projects and folders as containers, dossiers/documents as dashboards, visualizations as charts, and embedded dashboard datasets/cubes as datasets with schema fields derived from MicroStrategy metrics, attributes, and attribute forms. It can also ingest MicroStrategy reports as chart entities with report-scoped source datasets when extract_reports is enabled, and it records project source warehouse summaries when datasource APIs are available.

Lineage is emitted from datasets to visualizations (and from report source datasets to reports) through ChartInfo.inputs and ChartInfo.inputEdges, with chart InputFields when metric and attribute references are exposed. Optional coarse table-level warehouse lineage from SQL-view APIs is disabled by default; enable extract_warehouse_lineage or extract_report_sql_lineage to emit dataset-to-warehouse-table edges.

Prerequisites​

Create a MicroStrategy user with read access to the projects, dossiers, documents, and reports you want to ingest. For production metadata extraction, use username/password authentication with access to Library APIs and project-scoped metadata search. Guest authentication is useful for public demo exploration but does not expose all modeling APIs.

For optional upstream warehouse table lineage, the MicroStrategy principal needs access to create a dashboard/dossier instance and read the dataset SQL-view API. This lineage is coarse table-level lineage and is disabled by default until field-level metric, attribute, or fact lineage is available. Modeling privileges such as Architect/editor access can expose additional logical model details, but they are not required for SQL-view physical table lineage when the SQL-view APIs are available.

For optional report ingestion, the principal needs project-scoped report search and report definition access. For optional report SQL lineage, it also needs permission to create report instances and read the report SQL-view API.

Install the Plugin​

pip install 'acryl-datahub[microstrategy]'

Starter Recipe​

Check out the following recipe to get started with ingestion! See below for full configuration options.

For general pointers on writing and running a recipe, see our main recipe guide.

source:
  type: microstrategy
  config:
    base_url: "https://your-company.example.com/MicroStrategyLibrary"

    auth:
      type: password
      username: "${MSTR_USERNAME}"
      password: "${MSTR_PASSWORD}"

    platform_instance: production
    env: PROD

    # Optional regex filters. All projects, dashboards, and reports are
    # ingested by default; scope them like this when needed:
    # project_pattern:
    #   allow:
    #     - "^Finance$"
    # dashboard_pattern:
    #   allow:
    #     - "^Quarterly Business Review$"
    # report_pattern:
    #   deny:
    #     - "^Scratch.*"

    extract_dashboards: true
    extract_charts: true
    extract_reports: false
    extract_report_definitions: true
    extract_cubes: true
    extract_lineage: true
    extract_visualization_details: true
    extract_source_warehouses: true
    extract_dashboard_dependencies: true
    extract_metric_expressions: true
    extract_model_lineage: true

    # Optional coarse table-level lineage from MicroStrategy SQL-view APIs.
    # Keep disabled unless you want dataset -> warehouse table edges without
    # field-level metric / attribute / fact lineage.
    extract_warehouse_lineage: false
    extract_report_sql_lineage: false

    # Map each MicroStrategy datasource / connection name to the platform,
    # platform instance, env, and URN casing it was ingested under, so warehouse
    # lineage URNs match those tables. Keying by connection name lets several
    # connections to the same platform (e.g. prod vs dev Snowflake) resolve
    # independently. Matched against the connection name first, then the
    # datasource name. Datasources with no entry auto-detect their platform and
    # use this connector's env, no platform instance, and lowercase URNs.
    # datasource_platform_mapping:
    #   "Snowflake Prod":
    #     platform: snowflake
    #     platform_instance: my_snowflake_instance
    #     env: PROD
    #     convert_urns_to_lowercase: true

    # Disabled by default to keep DataHub lineage graphs focused on
    # dataset -> visualization edges.
    emit_dashboard_dataset_edges: false

    tag_measures_and_dimensions: true
    ingest_owner: true

    stateful_ingestion:
      enabled: true
      remove_stale_metadata: true

sink:
  type: datahub-rest
  config:
    server: "http://localhost:8080"

Config Details​

Note that a . is used to denote nested fields in the YAML recipe.

FieldDescription
base_url ✅
string
MicroStrategy Library base URL, for example https://your-company.example.com/MicroStrategyLibrary.
attribute_glossary_term_mapping
map(str,string)
emit_dashboard_dataset_edges
boolean
Emit DashboardInfo.datasetEdges as a fallback. Disabled by default because BI dashboards with many datasets make lineage views noisy.
Default: False
extract_charts
boolean
Whether to extract visualizations as DataHub charts.
Default: True
extract_cubes
boolean
Whether to extract embedded dashboard datasets as DataHub datasets.
Default: True
extract_dashboard_dependencies
boolean
Whether to call metadata search lineage APIs for direct dashboard components such as metrics, attributes, filters, and functions.
Default: True
extract_dashboards
boolean
Whether to extract dossiers/documents as DataHub dashboards.
Default: True
extract_independent_reports
boolean
Whether to extract reports not referenced by any ingested dashboard. By default only dashboard-linked reports are ingested (report_pattern still applies), so scoping dashboards also scopes reports. The linkage comes from extract_dashboard_dependencies; when dashboards or dependencies are not extracted, all matching reports are ingested.
Default: False
extract_lineage
boolean
Whether to emit dataset-to-chart lineage when resolved from definitions.
Default: True
extract_metric_expressions
boolean
Whether to fetch metric model definitions with expression tokens and attach expression metadata to metric schema fields when the MicroStrategy principal has access.
Default: True
extract_model_lineage
boolean
Whether to attempt modeling/table API access needed for logical table and source warehouse lineage. If privileges are missing, the connector reports the failure and continues.
Default: True
extract_report_definitions
boolean
Whether to fetch report definitions for source dataset, metric, and attribute details when extract_reports is enabled.
Default: True
extract_report_sql_lineage
boolean
Whether to execute report SQL-view APIs and emit coarse table-level lineage from report source datasets to source warehouse datasets. Disabled by default for the same reason as extract_warehouse_lineage. Field-level model lineage for report source datasets also requires this flag, because model lineage only attaches to datasets with known warehouse upstreams.
Default: False
extract_reports
boolean
Whether to extract MicroStrategy reports as DataHub charts. Disabled by default because reports can be numerous and are independent from dossier visualization extraction.
Default: False
extract_source_warehouses
boolean
Whether to call the MicroStrategy datasource management APIs to discover project source warehouse names, source types, database versions, DBMS names, and connection metadata.
Default: True
extract_usage_statistics
boolean
Whether to extract dashboard and report usage statistics (view counts, unique users, per-user counts) by querying the MicroStrategy Platform Analytics telemetry cube. Requires the Platform Analytics project to be enabled on the environment (standard on MicroStrategy Cloud) and readable by the ingestion principal. Disabled by default.
Default: False
extract_visualization_details
boolean
Whether to execute dashboards and fetch per-visualization runtime definitions to resolve dataset-to-visualization lineage when the static dashboard definition does not include dataset IDs.
Default: True
extract_warehouse_lineage
boolean
Whether to execute dashboard/dossier SQL-view APIs and emit upstream coarse table-level lineage from MicroStrategy datasets to source warehouse datasets parsed from SQL. Disabled by default because this is not field-level metric, attribute, or fact lineage. The connector discovers the warehouse platform from MicroStrategy datasource metadata and does not store raw SQL.
Default: False
include_hidden
boolean
Whether to include hidden MicroStrategy objects when APIs support it.
Default: False
ingest_owner
boolean
Whether to map API owner fields to DataHub ownership aspects.
Default: True
max_retries
integer
Maximum retry attempts for transient API failures.
Default: 3
metric_glossary_term_mapping
map(str,string)
page_size
integer
Number of objects requested per paginated metadata search call.
Default: 100
platform_analytics_project_name
string
Name of the MicroStrategy project that hosts Platform Analytics telemetry. Only change this if the environment renamed the standard project.
Default: Platform Analytics
platform_instance
One of string, null
The instance of the platform that all assets produced by this recipe belong to. This should be unique within the platform. See https://docs.datahub.com/docs/platform-instances/ for more details.
Default: None
tag_measures_and_dimensions
boolean
Tag metric fields as Measure, attribute fields as Dimension, and date/time attribute forms as Temporal.
Default: True
timeout_seconds
integer
HTTP request timeout in seconds.
Default: 30
usage_cube_name
string
Name of the Platform Analytics cube to query for usage. The default is the aggregate telemetry cube shipped with Platform Analytics; a custom cube works as long as it exposes Date, Project, Object, and User attributes and an executions metric.
Default: Platform Analytics (Agg)
usage_lookback_days
integer
How many days of usage history to request from the Platform Analytics cube. The shipped aggregate cube typically retains a 14-day rolling window, so larger values only help when the environment retains more history.
Default: 14
usage_query_timeout_seconds
integer
HTTP timeout in seconds for Platform Analytics cube query calls. Cube execution is server-side work and can be slower than metadata definition APIs.
Default: 180
verify_ssl
boolean
Whether to verify SSL certificates for MicroStrategy API calls.
Default: True
warehouse_lineage_sql_timeout_seconds
integer
HTTP timeout in seconds for SQL-view APIs. These calls can be slower than metadata definition APIs because MicroStrategy must create and resolve a dashboard instance.
Default: 180
env
string
The environment that all assets produced by this connector belong to
Default: PROD
auth
One of MicroStrategyGuestAuth, MicroStrategyPasswordAuth
Authentication mode. Use type: guest for public demo-style access or type: password with username/password for authenticated tenants.
auth.password ❓
string(password)
MicroStrategy password.
auth.username ❓
string
MicroStrategy username.
auth.type
string
Const value: guest
Default: guest
dashboard_pattern
AllowDenyPattern
A class to store allow deny regexes
dashboard_pattern.ignoreCase
One of boolean, null
Whether to ignore case sensitivity during pattern matching.
Default: True
datasource_platform_mapping
map(str,ConnectionPlatformConfig)
datasource_platform_mapping.key.platform
One of string, null
DataHub platform name (for example snowflake) to override the one auto-detected from the datasource's database type. Set this when the warehouse is custom or its database type is not recognized.
Default: None
datasource_platform_mapping.key.convert_urns_to_lowercase
boolean
Lowercase the upstream warehouse dataset and column URNs. Set to false when this warehouse was ingested with case preserved so lineage URNs match.
Default: True
datasource_platform_mapping.key.platform_instance
One of string, null
The platform instance the warehouse was ingested under.
Default: None
datasource_platform_mapping.key.env
One of string, null
The environment the warehouse was ingested under. Defaults to this connector's env when unset.
Default: None
folder_pattern
AllowDenyPattern
A class to store allow deny regexes
folder_pattern.ignoreCase
One of boolean, null
Whether to ignore case sensitivity during pattern matching.
Default: True
project_pattern
AllowDenyPattern
A class to store allow deny regexes
project_pattern.ignoreCase
One of boolean, null
Whether to ignore case sensitivity during pattern matching.
Default: True
report_pattern
AllowDenyPattern
A class to store allow deny regexes
report_pattern.ignoreCase
One of boolean, null
Whether to ignore case sensitivity during pattern matching.
Default: True
stateful_ingestion
One of StatefulStaleMetadataRemovalConfig, null
Stateful ingestion config with stale entity removal support.
Default: None
stateful_ingestion.enabled
boolean
Whether or not to enable stateful ingest. Default: True if a pipeline_name is set and either a datahub-rest sink or datahub_api is specified, otherwise False
Default: False
stateful_ingestion.fail_safe_threshold
number
Prevents large amount of soft deletes & the state from committing from accidental changes to the source configuration if the relative change percent in entities compared to the previous state is above the 'fail_safe_threshold'.
Default: 75.0
stateful_ingestion.remove_stale_metadata
boolean
Soft-deletes the entities present in the last successful run but missing in the current run with stateful_ingestion enabled.
Default: True

Capabilities​

Lineage Behavior​

By default, the connector emits lineage from MicroStrategy datasets to visualizations by setting ChartInfo.inputs and ChartInfo.inputEdges. When visualization metadata exposes metric and attribute references, it also emits chart InputFields pointing at the MicroStrategy dataset fields used by each visualization. It does not emit direct dataset-to-dashboard edges because those edges can make DataHub lineage views noisy for large BI dashboards.

Set emit_dashboard_dataset_edges: true if you want every dashboard dataset to appear directly upstream of the dashboard as fallback lineage.

The definition APIs do not expose a visualization's dataset binding directly, so the connector resolves it in tiers. First it reads the modeling document API: derived metrics and attributes are scoped to a single dataset, so a visualization grid referencing them identifies its source dataset with certainty. When no dataset-scoped objects are referenced (or modeling access is unavailable), the connector falls back to inferring the binding from shared object references and name tokens. If that inference cannot exclude any dataset (for example, dashboards built from one cube per time period where all cubes share one object catalog), the visualization is treated as unresolved and gets no dataset inputs rather than an all-to-all fan-out; use emit_dashboard_dataset_edges: true to keep such dashboards connected to their datasets.

When extract_visualization_details: true, the connector creates a dashboard instance and calls the v2 visualization definition endpoint to resolve dataset-to-visualization lineage when the static dashboard definition does not include dataset IDs. Use dashboard_pattern to scope live validation runs, for example:

dashboard_pattern:
  allow:
    - "^Quarterly Business Review$"

Reports​

Set extract_reports: true to ingest MicroStrategy reports as DataHub chart entities with the Report subtype. Report extraction is disabled by default because report libraries can be much larger than curated dossiers. Use report_pattern to scope report extraction.

When dashboards are also extracted, only reports referenced by an ingested dashboard are ingested by default, so scoping dashboards with dashboard_pattern scopes reports too. Linked reports are fetched directly by id rather than by enumerating the project's report library, so large report libraries do not slow down scoped runs. Set extract_independent_reports: true to also ingest reports not used by any dashboard (every report matching report_pattern); this enumerates the full report library. This scoping relies on extract_dashboard_dependencies for the dashboard-to-report linkage; without it, or without dashboard extraction, all matching reports are ingested.

When report definitions expose source and availableObjects metadata, the connector emits a report-scoped MicroStrategy source dataset containing the report metrics, attributes, and attribute forms. Report lineage uses ChartInfo.inputs, ChartInfo.inputEdges, and chart InputFields from that report source dataset to the report chart.

If extract_dashboard_dependencies: true and extract_reports: true, dashboards that expose report dependencies link to the matching report chart entities. Reports are a separate lineage path from dossier visualizations:

Dashboard/Dossier -> Visualization -> MicroStrategy Dataset
Dashboard/Dossier -> Report -> MicroStrategy Report Source Dataset

Set extract_report_sql_lineage: true only when you also want optional coarse report source dataset -> warehouse table lineage from the report SQL-view API. This setting is disabled by default and does not emit direct warehouse edges to reports or dashboards.

Source Warehouses​

When extract_source_warehouses: true, the connector calls MicroStrategy datasource management APIs for each project and records a source warehouse summary on the project container. The summary includes the datasource count, source database types, datasource types, and DBMS names exposed by MicroStrategy.

If a dashboard dataset payload includes a direct source warehouse reference, the connector also records datasource ID, datasource name, source type, database version, DBMS name, connection ID/name, and available database/schema context as dataset custom properties.

When extract_warehouse_lineage: true, the connector executes the dashboard/dossier SQL-view API and emits coarse upstream lineage from each MicroStrategy dataset to the physical warehouse datasets parsed from SQL. When field-level model lineage resolves for a dataset, its table-level upstreams are restricted to the tables evidenced by field lineage — tables the SQL only joins for filtering (dimension lookups, calendar subqueries) are not emitted as upstreams. Datasets without field-level lineage keep the full SQL-derived table set. It does not store raw SQL or connection strings. This setting is disabled by default because SQL-view lineage is table-level and does not prove field-level metric, attribute, or fact lineage. The connector uses dataset-level source warehouse metadata when MicroStrategy provides it. It only falls back to project-level datasource metadata when the project resolves to one unambiguous warehouse context, so multi-source projects do not get broad dataset-to-table edges from an arbitrary datasource. The resulting lineage shape is:

Dashboard/Dossier -> Visualization -> MicroStrategy Dataset -> Warehouse Dataset

The connector intentionally keeps direct DashboardInfo.datasetEdges disabled by default so dashboards do not draw edges directly to every dataset in DataHub lineage views.

Dependency and Model Lineage Enrichment​

When extract_dashboard_dependencies: true, the connector uses MicroStrategy metadata search lineage APIs to record direct dashboard component dependency summaries, including dependency counts by MicroStrategy object type.

When extract_metric_expressions: true, the connector fetches accessible metric model definitions and stores expression token summaries in metric field jsonProps.

When extract_model_lineage: true, the connector probes modeling table APIs needed for logical table and physical source warehouse lineage. Missing privileges are reported as warnings and counters; the connector continues with dashboard, dataset, metric, and source warehouse metadata.

Metric and Attribute Tags​

MicroStrategy metrics and attributes are emitted as schema fields on the dashboard dataset/cube. The connector attaches canonical DataHub tags to the fields:

  • urn:li:tag:Measure for metrics.
  • urn:li:tag:Dimension for attributes and attribute forms.
  • urn:li:tag:Temporal for date/time attribute forms.

These tags are written to source-managed SchemaMetadata field metadata, not editable schema metadata.

Usage Statistics​

Set extract_usage_statistics: true to emit daily view counts, unique-user counts, and per-user usage for ingested dashboards and reports. MicroStrategy has no per-object usage REST endpoint; the connector queries the Platform Analytics telemetry cube (the Platform Analytics (Agg) cube in the Platform Analytics project) through the standard cube instance APIs and joins the telemetry rows to ingested entities by object GUID.

Requirements and behavior:

  • Platform Analytics must be enabled on the environment (standard on MicroStrategy Cloud) and the ingestion principal needs read access to the Platform Analytics project. When the project or cube is missing, the connector records one warning and continues without usage.
  • The cube's attributes and metrics are resolved by name (Date, Project, Object, User, and Num Executions or Count Actions), so renamed or heavily customized telemetry cubes are skipped with a warning explaining what was missing. Use usage_cube_name to point at a custom cube that exposes the same objects.
  • usage_lookback_days bounds the request window (default 14 days — the shipped aggregate cube typically retains a 14-day rolling window). Usage freshness depends on the environment's Platform Analytics cube refresh schedule.
  • Usage rows for objects outside the ingested scope are counted in the usage_objects_unmatched report counter and skipped.

Limitations​

  • Warehouse lineage from the SQL-view APIs is coarse table-level lineage and is disabled by default (extract_warehouse_lineage and extract_report_sql_lineage). Field-level metric, attribute, or fact lineage to warehouse tables is not available yet.
  • Report extraction is disabled by default (extract_reports) because report libraries can be much larger than curated dossiers.
  • Direct dashboard-to-dataset edges are disabled by default; enable emit_dashboard_dataset_edges only if you want dashboard-level fallback lineage, which can make lineage views noisy for large dashboards.
  • Modeling APIs (logical tables, metric expressions) may return 403 when the principal lacks modeling privileges. The connector degrades gracefully — missing privileges are reported as warnings and counters, and ingestion continues with dashboard, dataset, metric, and source warehouse metadata.
  • Multi-source projects only receive dataset-to-warehouse edges when MicroStrategy exposes dataset-level source warehouse metadata; the connector does not guess a datasource when the project-level warehouse context is ambiguous.
  • Dataset upstreamLineage is replaced wholesale while any upstream tables remain, but a dataset whose warehouse lineage disappears entirely keeps the previous run's aspect (stale-entity removal deletes entities, not aspects). Remove leftovers with datahub delete --urn <urn> --aspect upstreamLineage or a rollback of the earlier run. Avoid pipeline-level incremental-lineage transformers with this source: their patch-add semantics prevent edge reductions from propagating.

Troubleshooting​

Missing dataset-to-visualization lineage​

If charts do not show upstream datasets, the static dashboard definition may not include dataset IDs. Set extract_visualization_details: true so the connector creates a dashboard instance and resolves bindings from the v2 visualization definition endpoint. This requires the principal to have instance-creation privileges; use dashboard_pattern to scope the run while validating.

403 errors on modeling or SQL-view APIs​

The connector does not fail ingestion on modeling API 403s — it records warnings and counters in the ingestion report and continues. Check the report counters to see which APIs were inaccessible, and grant the principal instance-creation and SQL-view access (for warehouse lineage) or modeling privileges (for extract_metric_expressions / extract_model_lineage) as needed.

Session invalidation mid-run​

MicroStrategy can invalidate the session token at any time (idle or absolute timeouts, concurrent-session limits, administrator action). The connector re-authenticates automatically and replays the failed request; the sessions_reauthenticated counter in the ingestion report shows when this happened. If re-login itself fails — or the server rejects a request immediately after a successful re-login — the run aborts with a single MicroStrategy Authentication Lost failure instead of failing every remaining project. Avoid signing in elsewhere with the ingestion service account while a run is in progress if your tenant enforces concurrent-session limits.

Empty or incomplete results​

If little or no metadata is ingested, verify that the principal has Library API access and project-scoped metadata search, and check that project_pattern (and dashboard_pattern / report_pattern, if set) are not filtering out the content you expect. Guest authentication works for public demo exploration but does not expose all modeling APIs.

Code Coordinates​

  • Class Name: datahub.ingestion.source.microstrategy.source.MicroStrategySource
  • Browse on GitHub
Questions?

If you've got any questions on configuring ingestion for MicroStrategy, feel free to ping us on our Slack.

💡 Contributing to this documentation

This page is auto-generated from the underlying source code. To make changes, please edit the relevant source files in the metadata-ingestion directory.

Tip: For quick typo fixes or documentation updates, you can click the ✏️ Edit icon directly in the GitHub UI to open a Pull Request. For larger changes and PR naming conventions, please refer to our Contributing Guide.