GLYDE Unity + erecruit

Overview

GLYDE Unity provides a unified integration with erecruit's WebApi (Nelson Staffing tenant), 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 bearer-token login 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. Because the erecruit spec exposes no webhook or event endpoints, 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   │  │
    │  └──────────────────────────────┘   │
    │      (no inbound webhooks —         │
    │       TTL + scheduled cache refresh)│
    └──────────────|──────────────────────┘
                   |
                   v
    ┌──────────────────────────────────────┐
    │       erecruit WebApi REST API       │
    │  erecruit.nelsonstaffing.com/WebApi  │
    │                                      │
    │   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 token, expiration timestamp, resolved base URL, and entity id. There is no global fallback credential — every tenant must have credentials provisioned in Azure Key Vault / IntegrationData (getDefaultAuthConfig throws).

Token Refresh

The erecruit bearer token has no known expiry; sessions are revalidated on a 24-hour TTL cycle. When the session expires, ConnectorAuthManager.getAutoAuth() transparently re-runs the User_ValidateCredentials login before the next API call. 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

The erecruit WebApi specification exposes no event or webhook endpoints. Event capability is registered as disabled (supportLevel: "none") with a polling-fallback note (supportsPollingFallback: true). Index freshness is maintained through the TTL-based cache strategy (14,400s hint) and scheduled / on-demand refresh via the ATS search-cache pipeline. This will be revisited if erecruit exposes events out-of-band.

Configuration Requirements

• erecruit Credentials (UserName / Password)REQUIRED

  A dedicated erecruit WebApi user name and password for API access. These must be stored in Azure Key Vault via the GLYDE Unity client configuration; there is no global fallback credential.

  username: "glyde-integration@nelsonstaffing.com"

• EntityID (Tenant Identifier)REQUIRED

  The erecruit EntityID for the tenant. Stored as UnityCredentials.tenant and sent as EntityID in the User/ValidateCredentials login request. Authentication throws before any API call when it is missing.

  tenant: "nelsonstaffing"

• 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"

• API Base URL (Optional)

  Per-tenant service_url override for the erecruit WebApi. Resolution order: tenant service_url → ERECRUIT_API_URL env → https://erecruit.nelsonstaffing.com/WebApi.

  service_url: "https://erecruit.nelsonstaffing.com/WebApi"

Known Limitations

• No webhooks or events. The erecruit WebApi spec has no event/webhook endpoints — event capability is registered disabled with a polling-fallback note; index freshness relies on TTL + scheduled cache refresh.
• 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".
• EntityID (tenant) is mandatory for auth and stored as UnityCredentials.tenant; User_ValidateCredentials returns the bearer token in UserId and IsValid must be true.
• The bearer token has no known expiry — sessions revalidate on a 24-hour TTL cycle rather than a vendor-provided expiration.
• 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