Skip to main content

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

Enrollment connects your existing data source to DataHarbor. Once enrolled, you can create multiple Virtual APIs from a single source.

​
Supported sources

Source TypeStatus
REST APIs (JSON, CSV, YAML, Markdown)Available
GraphQL APIs (query-only)Available
Azure FabricComing Soon
DatabricksComing Soon
SnowflakeComing Soon
BigQueryComing 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.

​
Route enforcement

HTTP sources support two route enforcement modes:
ModeBehavior
StrictRequests must follow the enrolled route template. Requests outside that shape are rejected.
PermissiveDataHarbor 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 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: 
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.
MethodDescription
PublicNo authentication required
API KeyKey sent in a request header
BasicUsername 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 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

HTTP Sources

See the current source connection model and auth expectations

Virtual APIs

Create Virtual APIs from your enrolled source

Schema Analytics

Monitor schema changes over time