Skip to main content
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).

​
Before you start

  1. Provision customer accounts with your partner master key.
  2. Implement the three 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 typeAuth
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 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 as Humanly and partners ship integrations.