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

# Build a vendor integration

> Partner guide for wrapping vendors Humanly does not yet support

<Note>
  This guide is for **partners** building on Connect. Internal Humanly engineers adding first-party vendor namespaces should follow the internal engineer playbook (MS9 / PLAT-44).
</Note>

## Before you start

1. [Provision customer accounts](/connect/account-provisioning) with your partner master key.
2. Implement the three [standardized vendor endpoints](/connect/standardized-vendor-endpoints) for your vendor namespace.
3. Add vendor-specific read/write routes following MS7 conventions when available.

## Namespace

Your routes live under:

```
/connect/{your-vendor}/...
```

Use a lowercase URL segment (e.g. `ukg`, `bamboohr`). It maps to an `IntegrationType` enum value on the Humanly side.

## Authentication

Auth depends on which Connect routes you implement:

| Route type                                                | Auth                                                                          |
| --------------------------------------------------------- | ----------------------------------------------------------------------------- |
| **Meta routes** (integrations, health, config validation) | Customer **`x-api-key`** with **`integrations`** scope only                   |
| **Data routes** (orders, catalog, results, …)             | Customer **`x-api-key`** **or** legacy integration **`Authorization: Basic`** |
| **Platform health** (`GET /connect/health`)               | No auth                                                                       |

## Dual auth on data routes (legacy parity)

Data routes that mirror legacy ATS integrations accept either:

* **Partner path:** `x-api-key` with a Connect **customer** key (`integrations` scope) — for partners who [provision customers](/connect/account-provisioning) through Connect
* **Direct path:** `Authorization: Basic` with the customer's **integration credentials** — for customers still on the legacy direct-integration auth model Humanly used before Connect (per-vendor routes on the integration host, historically under `/qsi/{vendor}/*`)

If both headers are sent and the `x-api-key` is **valid for the route scope** (customer key with `integrations` scope on data routes), it takes precedence over Basic auth. A wrong-scope key (for example a partner master `accounts` key on vendor routes) returns **403** — Connect does not fall back to Basic auth.

## Vendor pages

Per-vendor reference docs will live under [Vendors](/connect/vendors/index) as Humanly and partners ship integrations.

## Related

* [Connect overview](/connect/overview)
* [Platform permission scopes](/platform/permission-scopes)