GLYDE Unity + erecruit

Overview

GLYDE Unity provides a unified integration with erecruit's WebApi (API v2, erecruit 3.1+), exposing candidate records, internally posted positions, candidate applications, and the full application→submission→placement pipeline through a single ATS-agnostic API layer.

The integration spans the full GLYDE ecosystem: Microsoft Teams, Copilot for Microsoft 365, Power Automate, the GLYDE Unity SDK, and the Model Context Protocol (MCP) for AI agent consumption. All operations are tenant-isolated using client_uuid and authenticated via OAuth2 client-credentials tokens with fully automatic token management.

erecruit data flows through GLYDE Unity's index-centric normalization pipeline, ensuring consistent data representation across all consumers regardless of erecruit's native conventions — PascalCase payloads, integer entity IDs, and the merged Match pipeline record that collapses application, submission, and placement into one expanding type.

Product Demos

Short walkthroughs of the GLYDE experience across the surfaces this integration powers.

Architecture & Data Flow

GLYDE Unity acts as an orchestration layer between consuming platforms (Teams, Copilot, Power Platform, SDK) and the erecruit WebApi REST API. Requests are authenticated, normalized, and routed through the integration adaptor which handles entity-specific business logic, data mapping, and error classification. The erecruit WebApi exposes no API for registering webhooks, so change events are received through a webhook created manually in the erecruit ATS UI pointing at GLYDE (see Events & Webhooks below); until that is set up, index freshness is maintained through scheduled and on-demand cache refresh rather than inbound events.

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   │   │
    │  └──────────────────────────────┘   │
    │                                     │
    │  ┌─ Workflow Route Handler ──────┐  │
    │  │  Validation + Orchestration   │  │
    │  └──────────────────────────────┘   │
    │              |                       │
    │              v                       │
    │  ┌─ erecruit Integration Adaptor┐  │
    │  │  candidates.ts / applications│  │
    │  │  Template Method Pattern     │  │
    │  │  Index-centric data mapping  │  │
    │  └──────────────────────────────┘   │
    │              |                       │
    │              v                       │
    │  ┌─ erecruit External Connector ─┐ │
    │  │  erecruit-connector.ts        │  │
    │  │  ConnectorAuthManager (Bearer)│  │
    │  │  OpenAPI-driven operations    │  │
    │  │  ICanonicalEntityOperations   │  │
    │  └──────────────────────────────┘   │
    │      (inbound events via manual    │
    │       ATS-UI webhook + scheduled   │
    │       cache refresh)               │
    └──────────────|──────────────────────┘
                   |
                   v
    ┌──────────────────────────────────────┐
    │       erecruit WebApi REST API       │
    │  https://.erecruitcloud.com  │
    │                                      │
    │   Candidate | Position |             │
    │   CandidateApplication | Match |     │
    │   Company | Contact | Attachment     │
    └──────────────────────────────────────┘

Authentication

Credential Fields

Session Management

Sessions are cached in Redis with the key pattern session:client:{client_uuid}:integration:erecruit. The session stores the bearer access token, expiration timestamp, resolved base URL, and optional entity id. There is no global fallback credential — every tenant must have credentials provisioned in Azure Key Vault / IntegrationData (getDefaultAuthConfig throws).

Token Refresh

Access tokens expire every 10 minutes per the Bullhorn KB; the token response's expires_in is honored (600s default when omitted). Sessions rotate automatically: the 5-minute validity buffer re-mints the token well before expiry, and a 401 from the ATS triggers clearRedisSessionOnly() and a single retry with a freshly minted token.

Capabilities

Platform Access

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

Entity Mappings

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

Candidate → Candidate

Job → Position (PostedPositionResponse)

Application → CandidateApplication

Placement / Submission → Match

Endpoint Reference

Events & Webhooks

Inbound erecruit change events are supported through a webhook that is created manually in the erecruit ATS UI — the erecruit WebApi exposes no endpoint for registering subscriptions programmatically (remote_subscription_supported: false), so a one-time manual setup in the ATS administration UI is required. Events are processed through the GLYDE ATS event pipeline: they keep the candidate/job indexes current (gated by the tenant's event_system.processing.update_ats_cache setting) and are the primary way candidate records first flow into GLYDE, because the WebApi has no candidate-enumeration search (listing requires vendor/status/owner filters or an exact name).

Manual webhook setup:

1. In the erecruit ATS administration UI, create a webhook (event subscription) for Candidate, Position, and CandidateApplication change events.
2. Point it at the GLYDE event receiver for this tenant: POST https://api.glydeunity.com/api/unity/events/webhook/{client_uuid}/erecruit — the tenant's GLYDE client_uuid is embedded in the URL, so no tenant resolution is required in the payload. (An alternative form, POST /api/unity/events/webhook/erecruit, exists for senders that pass the clientUuid query parameter instead.)
3. Ask GLYDE support to enable the erecruit-core-events subscription on the tenant — it is born disabled on purpose (events arriving before the webhook exists are rejected with 404). After enabling, run POST /api/unity/activation/verify — the events phase should report healthy and go-live (initial index population) can proceed.

Configuration Requirements

• erecruit API Service Credentials (Client ID / Client Secret)REQUIRED

  Client ID + client secret for an application registered in the erecruit control panel, with the needed calls enabled under Manage API Permissions (per-call permissions). These must be stored in Azure Key Vault via the GLYDE Unity client configuration; there is no global fallback credential.

  client_id: "glu-integration-app"

• Tenant service_url (WebApi Base URL)REQUIRED

  Per-tenant erecruit WebApi base URL — must include the /webapi path (e.g. https://<agency>.erecruitcloud.com/webapi): data calls are made against this base, while the token endpoint is derived from the site origin ({origin}/t/token), so a URL missing /webapi still mints tokens but fails every data call. Resolution order: tenant service_url → ERECRUIT_API_URL env. The activation wizard’s verification pass (POST /api/unity/activation/verify) live-probes stored credentials with one cheap read call, so a malformed base URL is caught at setup time instead of at first use.

  service_url: "https://nelsonupgrade.erecruitcloud.com/webapi"

• EntityID (Tenant Identifier, optional)

  Legacy v1 context only — NOT required for v2 token auth. Stored as UnityCredentials.tenant when provided.

  tenant: "3"

• Integration TypeREQUIRED

  The client's integration_type must be set to "erecruit" in the GLYDE client configuration for the adaptor router to select the correct integration.

  integration_type: "erecruit"

Known Limitations

• Events require manual webhook setup. The erecruit WebApi has no subscription-registration endpoints, so the inbound webhook must be created manually in the erecruit ATS UI pointing at POST /api/unity/events/webhook/{client_uuid}/erecruit, and the erecruit-core-events subscription enabled by GLYDE support (it is born disabled). Until then, index freshness relies on TTL + scheduled cache refresh, and candidate records only enter GLYDE through searches and explicit reads.
• No candidate-enumeration search. Candidate_List requires at least one of VendorID/StatusIDs/OwnerID, and Candidate_ByName is an exact First+Last lookup — the WebApi has no "list all candidates" operation, which is why inbound events are the primary initial-population path for candidates.
• No server-side pagination on core lists. Candidate_List, Position_GetInternallyPosted, and the CandidateApplication list operations return the FULL list — filter client-side.
• No keyword search. Search is structured-filter only (VendorID, StatusIDs, OwnerID, name parts). searchCapabilities.supportsKeywordSearch is false; keyword-style discovery is served from the GLYDE Azure AI Search index.
• Field names are PascalCase (First, Last, ID, StatusID) — not camelCase or snake_case. All mapping lives in types/erecruit/mapping-profile.ts.
• Entity IDs are integers; Match/CandidateApplication cross-reference them via CandidateID / PositionID / MatchID.
• Match is the pipeline record: application → submission → placement as ONE expanding record (Status is the stage label). There is no separate GLYDE placement entity — Match is registered with canonicalEntity: "other".
• Auth uses API service credentials (client_id + client_secret for an application registered in the control panel, permissions via Manage API Permissions); POST {site-origin}/t/token returns the bearer access_token.
• Access tokens expire every 10 minutes — sessions rotate automatically off the response expires_in (600s default) and the 5-minute validity buffer.
• Status labels require expansion. Candidate/Position records carry integer StatusID refs; labels only appear in _expanded.Status.Name (requires the expand query parameter). Applications are the exception — they carry string Status labels directly.
• Statuses/types are NamedValue { ID, Name } lookups (Position_GetStatuses / Position_GetTypes / Candidate_GetRatings / AdSource_GetAdSources, etc.) consumed via fieldValueOperations for designer dropdowns.
• Candidate create/update are not implemented at the workflow layer (the adaptor inherits the base not-supported defaults). Candidate records flow in through list/get and the search-cache pipeline; use the ATS proxy for vendor-native writes.
• Job create/update are not implemented and live job get-by-id resolves from the GLYDE index; live single-position reads are available via Position_GetPosition through the ATS proxy.
• No ATS activity write-back for messages. Email/SMS delivery is GLYDE-native (Mailgun/Twilio); no erecruit activity note is created. Use the ATS proxy for vendor-native note operations.
• Addresses use PostalCode / AddressLine1 (not Zip / Address1).
• HireDate / ReHireDate on candidates are placement dates, NOT record timestamps — deliberately never mapped to created/updated. EducationLeveID is a vendor typo on CandidateResponse and is unmapped by design.
• Outbound create/update field mapping beyond CandidateApplication_Post is not yet implemented in the mapping profile — it defines the inbound field maps used by the ATS search-index pipeline.

Version History