> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dataharbor.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Enrolling Data Sources

> Connect your existing APIs to DataHarbor.

# Enrolling Data Sources

Enrollment connects your existing data source to DataHarbor. Once enrolled, you can create multiple [Virtual APIs](./virtual-apis) from a single source.

## Supported sources

| Source Type                           | Status      |
| ------------------------------------- | ----------- |
| REST APIs (JSON, CSV, YAML, Markdown) | Available   |
| GraphQL APIs (query-only)             | Available   |
| Azure Fabric                          | Coming Soon |
| Databricks                            | Coming Soon |
| Snowflake                             | Coming Soon |
| BigQuery                              | Coming Soon |

## Enrolling a REST API

Enrollment is done through the DataHarbor dashboard. You configure three things:

1. **Base URL** — the root URL of your upstream API
2. **Route Enforcement** — whether requests must stay within the enrolled template
3. **Request Path Template** — the path structure with parameter placeholders

### Base URL

The base URL is the root of your API, without any path segments:

```
https://api.yourcompany.com
```

DataHarbor uses this to connect to your upstream service and proxy requests through your Virtual APIs.

### Request path template

The path template describes the full route structure of your API using `{parameter}` placeholders for dynamic segments:

```
/customers/{customerId}/orders/{orderId}/items/{itemId}
```

DataHarbor uses this template to understand your API's resource hierarchy. Each static segment (like `customers`, `orders`, `items`) becomes a matchable object name in your [Virtual API Configuration](./virtual-apis#object-definitions-and-route-matching).

### Route enforcement

HTTP sources support two route enforcement modes:

| Mode         | Behavior                                                                                    |
| ------------ | ------------------------------------------------------------------------------------------- |
| `Strict`     | Requests must follow the enrolled route template. Requests outside that shape are rejected. |
| `Permissive` | DataHarbor sends any request path to the configured backend.                                |

Use `Strict` when you want the source definition to define the allowed route family. Use `Permissive` when you want DataHarbor to proxy arbitrary paths to the same backend.

See [Route Matching](../sources/route-matching) for how strict-mode admissibility works.

#### Required parameters

Prefix a parameter with `$` to mark it as required:

```
/organizations/{$orgId}/users/{userId}
```

Required parameters must always be provided with a specific value — they cannot be omitted or wildcarded. Use this for parameters like tenant IDs that are always needed to scope requests correctly.

#### How templates map to objects

Given this path template:

```
/properties/{propertyId}/inspections/{inspectionId}/issues/{issueId}
```

DataHarbor extracts three object names: `properties`, `inspections`, and `issues`. These are the names you reference in your Virtual API Configuration:

```yaml theme={null}
objects:
  properties:
    controls:
      - type: redact
        fields: [ownerFirstName]
  inspections:
    controls:
      - type: redact
        fields: [inspectorName]
  issues:
    controls:
      - type: redact
        fields: [title]
```

## Authentication

DataHarbor supports three authentication methods for connecting to your upstream API. Configure these in the dashboard when enrolling your source.

| Method      | Description                  |
| ----------- | ---------------------------- |
| **Public**  | No authentication required   |
| **API Key** | Key sent in a request header |
| **Basic**   | Username and password        |

When you provide upstream credentials during enrollment, DataHarbor stores that secret material in a **secure secret store** rather than embedding it in the Virtual API Configuration.

## Enrolling a GraphQL API

GraphQL enrollment follows the same dashboard flow, but instead of a path template you define:

1. **Endpoint URL** — the upstream GraphQL endpoint
2. **Named operations** — the `query` documents callers are allowed to run
3. **Authentication** — the source-level credentials DataHarbor uses upstream

Unlike REST sources, callers do not send arbitrary request paths or GraphQL documents. They invoke one of the operation IDs you enrolled on the source.

See [GraphQL Sources](../sources/graphql-sources) for the source-specific rules, operation constraints, variable handling, and filter-spec guidance.

## Schema discovery

When you enroll a source, DataHarbor:

1. Calls each endpoint to sample the response structure
2. Learns the schema shape over time
3. Detects net-new fields as they appear
4. Flags potentially sensitive fields for review

Schema discovery runs automatically as requests flow through your Virtual APIs — the more your API is used, the more complete the schema becomes.

## Next steps

<CardGroup cols={2}>
  <Card title="HTTP Sources" icon="globe" href="../sources/http-sources">
    See the current source connection model and auth expectations
  </Card>

  <Card title="Virtual APIs" icon="layer-group" href="./virtual-apis">
    Create Virtual APIs from your enrolled source
  </Card>

  <Card title="Schema Analytics" icon="chart-line" href="../protect/schema-analytics">
    Monitor schema changes over time
  </Card>
</CardGroup>