GLYDE Unity + Loxo

Overview

GLYDE Unity integrates with Loxo, the recruiting CRM and ATS, through a read-and-search-focused integration: candidate retrieval by GLYDE UUID or Loxo person id, pipeline (Deal) reads and creation, and Loxo's REST API exposed end-to-end through the GLYDE ATS proxy — 185 operations across people, jobs, deals, companies, job contacts, and list endpoints.

The integration spans the full GLYDE platform: Microsoft Teams, Copilot for Microsoft 365, Power Automate, the GLYDE Unity SDK, the Model Context Protocol (MCP) for AI agents, and the GLYDE Voice Agent. All operations are tenant-isolated using client_uuid and authenticated via a per-tenant Bearer API token with the agency slug automatically injected into every call.

Loxo data flows through GLYDE Unity's index-centric normalization pipeline, converting Loxo's snake_case fields to GLYDE's canonical snake_case index schema. Search results are cached in Redis and queued for background Azure AI Search indexing, so the GLYDE index (powering conversational and weighted search) keeps improving as recruiters use the platform.

Architecture & Data Flow

GLYDE Unity acts as an orchestration layer between consuming platforms (Teams, Copilot, Power Platform, SDK) and the Loxo REST API (https://app.loxo.co/api). Requests are authenticated, normalized, and routed through the integration adaptor's candidates and applications sub-adaptors; jobs, notes, and advanced operations are served through the index or the ATS proxy. The connector auto-injects the tenant agency_slug into every request, so callers never handle tenant routing themselves.

Teams / Copilot / Power Platform / SDK / MCP Client
                    |
                    v
    ┌─────────────────────────────────────┐
    │     GLYDE Unity REST API            │
    │   api.glydeunity.com/api/unity/*    │
    │                                     │
    │  ┌─ Auth Middleware ─────────────┐   │
    │  │  API Key / JWT / Trusted App │   │
    │  │  Role-based access control   │   │
    │  └──────────────────────────────┘   │
    │              |                       │
    │              v                       │
    │  ┌─ Loxo Integration Adaptor ─────┐ │
    │  │  Sub-Adaptors:                 │ │
    │  │   candidates (people:show)     │ │
    │  │   applications (deals)         │ │
    │  │   messages / search (base)     │ │
    │  │                                │ │
    │  │  Index-first lookups           │ │
    │  │  Template Method Pattern       │ │
    │  └────────────────────────────────┘ │
    │              |                       │
    │              v                       │
    │  ┌─ Loxo External Connector ──────┐ │
    │  │  loxo-connector.ts             │ │
    │  │  185 OpenAPI Operations        │ │
    │  │  LoxoConnectorAuthManager      │ │
    │  │  Bearer api_key + agency_slug  │ │
    │  │  auto-injection                │ │
    │  └────────────────────────────────┘ │
    └──────────────|──────────────────────┘
                   |
                   v
    ┌──────────────────────────────────────┐
    │          Loxo REST API               │
    │   https://app.loxo.co/api            │
    │   /{agency_slug}/...                 │
    │                                      │
    │  people | jobs | deals | companies   │
    │  job_contacts | lists (statuses,     │
    │  types) | documents                  │
    └──────────────────────────────────────┘

Authentication

Credential Fields

Session Management

Sessions are cached in Redis with the key pattern session:client:{clientUuid}:integration:loxo. The session carries the Bearer token and the agency slug. Because Loxo API keys are static, the session is simply rebuilt from Key Vault when the 24-hour validity window lapses or when a request is rejected as unauthenticated.

Token Refresh

No refresh flow exists or is needed — Loxo API keys are long-lived. GLYDE Unity deliberately does not support deployment-global Loxo credentials: every tenant must have its own api_key + tenant in Key Vault, and authentication fails with an explicit error listing the missing fields otherwise.

Capabilities

Platform Access

GLYDE Unity provides unified access to Loxo across multiple Microsoft 365 and developer platforms.

Entity Mappings

Loxo uses different entity names and field conventions. GLYDE Unity normalizes these through the index-centric data pipeline.

Candidate → Person

Job → Job

Application → Deal

Endpoint Reference

Events & Webhooks

Loxo event ingestion is not currently active. A default event subscription (loxo-core-events, matching Candidate.*, Job.*, Application.*) is registered in a disabled state, and no Loxo poller has been implemented — the subscription is deliberately disabled to avoid a misleading "active" configuration. A passthrough inbound normalizer exists for Loxo, so webhooks configured manually in the Loxo UI pointing at POST /api/unity/events/webhook/:clientUuid/loxo can be received, but there is no remote subscription management, polling fallback, or event replay. Until the poller ships, candidate/job data reaches the GLYDE index via search-time caching and background indexing rather than event-driven refresh.

Configuration Requirements

• Loxo API KeyREQUIRED

  Per-tenant API key generated in Loxo. Written straight to Azure Key Vault (secret {clientUuid}-loxo-credentials) at activation time. Global/deployment-wide credentials are deliberately not supported.

  api_key: "xxxxxxxxxxxxxxxxxxxxxxxx"

• Agency Slug (Tenant)REQUIRED

  The Loxo agency slug identifying the tenant. Required on every Loxo API call; GLYDE Unity auto-injects it into request params, but it must be present in the stored credentials.

  tenant: "hru-tech"

• Integration TypeREQUIRED

  The client's integration_type must be set to "loxo" for the adaptor router to select the Loxo integration.

  integration_type: "loxo"

• API Base URL (Optional)

  Override the Loxo API base URL (defaults to https://app.loxo.co/api). Configured via the LOXO_API_URL environment variable or a per-tenant service_url.

  LOXO_API_URL="https://app.loxo.co/api"

Known Limitations

• Read/Search-Focused Integration: candidate create/update are not implemented at the adaptor level (no Loxo outbound candidate mapping). Use the ATS proxy (people:create, people:update, people:update_by_email) when writes are required.
• Loxo Entity Vocabulary: the candidate entity is called Person, and the application entity is called Deal. The adaptor and LLM metadata map these synonyms automatically, but raw proxy calls use Loxo names.
• Cursor Pagination (scroll_id): Loxo list endpoints paginate with scroll_id + per_page (default 20), not offset/page. Application listing follows up to 10 scroll pages per request.
• agency_slug Required Everywhere: all Loxo operations are namespaced under the agency slug; GLYDE Unity injects it automatically, but credentials missing the tenant slug will fail.
• Application Update Not Supported: only Deal creation and reads are implemented. Stage changes happen in Loxo or via the ATS proxy.
• Find Application Filters: applications can be found by person_id + job_id only; filtering by externalRef or status is rejected by the adaptor.
• No Live Job Leg: the jobs sub-adaptor is the base implementation, so job get/find are index-only; live Loxo job operations go through the proxy (jobs:index, jobs:show, jobs:apply).
• No Notes/Activities Write-Back: the unified-activities sub-adaptor is not wired for Loxo; emails and SMS sent through GLYDE are not logged back into Loxo.
• Events Disabled: no poller, disabled default subscription, no remote subscription management, no replay (see the Events section).
• No Directory Live Leg: company/contact directory search is index-only for Loxo; rows enter the directory via POST /api/unity/directory/ingest imports.
• Loosely Typed Responses: many Loxo OpenAPI response schemas are empty ({}); the connector unwraps rows via configured row keys (results/people/data etc.) rather than schema validation.

Version History