A DataHub credential, reduced to the single HTTP header it contributes to a request, or anonymous access without an authentication header. Construct one via the static factory methods rather than directly. See the .

A branch in a DataHub repository, together with the commit it points at. See the .

A single commit in a DataHub repository. See the .

Top-level facade for DataHub resource APIs — the single public entry point on every target. new DataHubClient(baseUrl, auth) reads identically in .NET, JavaScript/TypeScript, and Python: the constructor defaults the DataHubClient.Http transport to the one built for the host runtime — DotNetHttpClient on .NET, FetchHttpClient on JavaScript/TypeScript, HttpxHttpClient on Python. Assign Http to substitute a transport for retries, proxies, or tests.

Version information for the DataHubClient library, shared by the .NET, JavaScript/TypeScript, and Python packages.

Base error for every failed DataHub operation. Wraps the raw HTTP status and body so callers get a consistent, cross-language error shape instead of a target-specific HTTP exception.

.NET implementation of IHttpClient backed by HttpClient. Follows up to twenty redirects and removes authentication headers when the destination changes origin. HTTPS-to-HTTP redirects are rejected.

Client for GitLab repository file operations. See the .

A transport-agnostic HTTP request. Resource APIs assemble these and hand them to an IHttpClient implementation, keeping DataHubClient free of any concrete HTTP library.

A transport-agnostic HTTP response returned by an IHttpClient implementation. Resource APIs inspect the status code and decode the body into model classes.

The HTTP transport abstraction for DataHubClient. Each distribution target supplies its own implementation — System.Net.Http on .NET, fetch on JavaScript/TypeScript, httpx on Python — so that DataHubClient never depends on a concrete HTTP library. Callers may also inject a custom implementation for retries, proxies, or tests.

An issue on a DataHub project. Iid is the per-project number shown in the UI; Id is globally unique across the instance. See the .

Client for GitLab issue operations. See the .

A merge request on a DataHub project. Iid is the per-project number shown in the UI; Id is globally unique across the instance. See the .

Client for GitLab merge request operations. See the .

A comment on an issue or merge request. System notes are generated by GitLab itself (e.g. "changed the status to closed"). See the .

404 — the requested project, branch, issue, … does not exist.

An entry in a project's generic Package Registry. See the .

Client for GitLab Package Registry operations, focused on generic packages. See the .

A DataHub project — the GitLab repository hosting a single ARC. See the .

Client for the GitLab Projects API used by DataHubs. See the .

429 — the DataHub rejected the request for exceeding its rate limit.

A single file in a DataHub repository, as returned by the . Content is encoded according to Encoding (typically base64).

Client for repository branch and commit operations. See the .

5xx — the DataHub failed to process an otherwise valid request.

401/403 — missing, invalid, or insufficiently scoped credentials.

A DataHub user, as returned embedded in issues, merge requests, notes, and commits. See the .

Client for the GitLab Users API used by DataHubs. See the .

Client for ARC validation (CQC) results. Every ARC on a DataHub has a cqc branch holding the output of validation package runs, one folder per validated ARC branch, containing one <name>@<version> folder per package with badge.svg, validation_report.xml, and validation_summary.json. See the . All methods default ref to the cqc branch head; pass a commit SHA from ListHistoryAsync to read results from any point in the branch history.

A reference to one validation package's result folder on an ARC's cqc branch, named <name>@<version> on disk. Instances are usually discovered via ValidationApi.ListPackagesAsync; use ValidationPackageRef.Create when the coordinates are already known. See the .

The validation package a summary was produced by, as embedded in validation_summary.json.

Aggregated pass/fail counts for one severity class of validation cases, as written by arc-validate into validation_summary.json.

The contents of a validation_summary.json produced by an ARC validation package run, mirroring arc-validate's ValidationSummary. See the .