GLYDE Unity + JobDiva

Overview

GLYDE Unity provides a deep ATS integration with JobDiva, the enterprise staffing ATS, through its V2 API: full candidate CRUD (get, find, create, update, hotlists), job create/update, Submittal (application) create/update and reads, candidate notes/activities with email logging, smart live search with automatic query routing, and 330 operations exposed through the GLYDE ATS proxy.

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 per-tenant service credentials (clientid / username / password) exchanged for a 1-hour JobDiva API token managed automatically by the connector.

JobDiva data flows through GLYDE Unity's index-centric normalization pipeline, converting JobDiva's UPPER_CASE create fields and camelCase read fields to GLYDE's canonical snake_case format. Search results are cached in Redis and queued for background Azure AI Search indexing via BullMQ, 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 JobDiva V2 API (https://api.jobdiva.com). Requests are authenticated, normalized, and routed through the integration adaptor's 8 entity sub-adaptors (candidates, jobs, applications, activities/notes, activities-unified, messages, search). The ATS search workflow classifies each query — numeric id lookup, simple name/email find, or broad TalentSearch — before calling JobDiva, and every search feeds the GLYDE cache and index.

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                       │
    │  ┌─ JobDiva Integration Adaptor ──┐ │
    │  │  8 Entity Sub-Adaptors:        │ │
    │  │  candidates / jobs /           │ │
    │  │  applications / activities /   │ │
    │  │  activities-unified / messages │ │
    │  │  search                        │ │
    │  │                                │ │
    │  │  Query Routing (id vs find vs  │ │
    │  │  TalentSearch)                 │ │
    │  │  Template Method Pattern       │ │
    │  │  Index-centric Data Mapping    │ │
    │  └────────────────────────────────┘ │
    │              |                       │
    │              v                       │
    │  ┌─ JobDiva External Connector ───┐ │
    │  │  jobdiva-connector.ts          │ │
    │  │  330 OpenAPI Operations (V2)   │ │
    │  │  JobDivaConnectorAuthManager   │ │
    │  │  /apiv2/authenticate → 1h      │ │
    │  │  token, Redis-cached           │ │
    │  └────────────────────────────────┘ │
    └──────────────|──────────────────────┘
                   |
                   v
    ┌──────────────────────────────────────┐
    │         JobDiva V2 API               │
    │  https://api.jobdiva.com             │
    │  /apiv2/...                          │
    │                                      │
    │  Candidate | Job | Submittal |       │
    │  Company | Note | CandidateHotlist   │
    └──────────────────────────────────────┘

Authentication

Credential Fields

Session Management

Sessions are cached in Redis with the key pattern session:client:{clientUuid}:integration:jobdiva. The session carries the API token with a fixed 1-hour TTL. On expiry the connector re-authenticates transparently on the next request. There are no deployment-global JobDiva credentials — authentication fails with an explicit error if the tenant has no Key Vault or integration-data credentials.

Token Refresh

There is no refresh token: when the 1-hour token lapses, the manager simply re-runs /apiv2/authenticate with the stored service credentials. Auth failures on search routes surface as JOBDIVA_AUTH_FAILED (HTTP 401) with guidance to re-check the tenant's stored credentials.

Capabilities

Platform Access

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

Entity Mappings

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

Candidate → Candidate (UPPER_CASE on create, camelCase on update/read)

Job → Job

Application → Submittal

Activity (Note) → CandidateNote

Endpoint Reference

Events & Webhooks

JobDiva supports inbound webhooks with manual registration. JobDiva exposes no remote webhook-management API in the connector spec, so GLYDE Unity records the default subscription (jobdiva-core-events) with awaiting-remote-registration semantics: the customer must manually point a JobDiva webhook at the Unity inbound receiver (POST /api/unity/events/webhook/:sourceSystem). Once deliveries flow, events are normalized to the canonical EventObject format via the passthrough normalizer and drive event-assisted cache refresh (4-hour TTL hint). There is no polling fallback and no event replay — missed deliveries require a direct entity refresh.

Configuration Requirements

• JobDiva Service CredentialsREQUIRED

  Per-tenant API service account (clientid + username + password), stored in Azure Key Vault. There are no deployment-global JobDiva credentials; legacy integration_data credentials are honored and synced back to Key Vault after successful auth. Tenant credentials are NOT environment variables.

  clientid: "1460", username: "api_user", password: "********"

• Integration TypeREQUIRED

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

  integration_type: "jobdiva"

• GLYDE User ID (Notes)REQUIRED

  integration_data.JobDivaConfiguration.glyde_user_id is used as the recruiterid on candidate notes created by GLYDE (activities and email logging). Required for note writes.

  JobDivaConfiguration.glyde_user_id: 12345

• API Base URL (Optional)

  Override the JobDiva API base URL (defaults to https://api.jobdiva.com) via the JOBDIVA_API_URL environment variable or a per-tenant service_url.

  JOBDIVA_API_URL="https://api.jobdiva.com"

• Search Stack (Deployment-Level)

  The atsSearch cache/index pipeline requires AZURE_SEARCH_ENDPOINT, AZURE_SEARCH_API_KEY (or AZURE_SEARCH_KEY), and Redis (REDIS_HOST/PORT/PASSWORD) — shared infrastructure, not per-tenant.

  AZURE_SEARCH_ENDPOINT="https://.search.windows.net"

Known Limitations

• Job Notes Not Supported: creating or reading JobDiva job-order notes is not implemented (the connector lacks the createJobOrderNote / getJobOrderNotes endpoints); only candidate notes are supported.
• Application Entity Is Called "Submittal": Submittal create is an upsert (create and update share one operation) and returns a boolean, so the created application is read back by listing the candidate's applications and matching jobId.
• Application Lookup by Id Not Supported: there is no get-by-application-id; use list-by-candidate and match. Find filters support atsCandidateId only — externalRef / job-only / status filters are rejected.
• No Universal Query Language: JobDiva has no cross-entity query syntax; search is operation-specific parameters. Pagination also varies by operation (the canonical profile documents from/count with a default of 100).
• Mixed Field-Name Conventions: candidate create uses UPPER_CASE fields (FIRSTNAME, LASTNAME, EMAIL, CELLPHONE) while update and reads use camelCase — the mapper handles both, but raw proxy callers must match the operation's convention.
• atsSearch Forwards a Limited Filter Set: only email, firstName/lastName splits, and city/state/zipCode/country JSON filters reach JobDiva; Unity-side orderby/select are Azure-index concepts and are not forwarded.
• Background Indexing Caps: atsSearch queues up to 1000 candidate ids per search for background Azure AI Search indexing (BullMQ, 100ms inter-job delay, max 3 concurrent workers).
• Token TTL Fixed at 1 Hour: the /apiv2/authenticate token is re-obtained transparently; there is no refresh token. Auth failures surface as JOBDIVA_AUTH_FAILED (HTTP 401) on search routes.
• Dates May Be Date-Only or Full Datetime: JobDiva mixes ISO date-only and full ISO datetime values; the mapper normalizes both.
• Directory Is Index-Only: no live companies/contacts leg is wired (searchCompanyUsingPOST exists in the spec and the proxy tier-1 list, but is not surfaced as directory search). Rows enter the directory via POST /api/unity/directory/ingest imports or JobDiva webhooks.
• Events Require Manual Registration: no remote subscription management, no polling fallback, no replay — the customer registers the webhook in the JobDiva UI.
• Placements & Compliance Not Supported: the connector does not expose JobDiva placement or compliance operations.

Version History