GLYDE Unity + TrackerRMS

Overview

GLYDE Unity integrates with TrackerRMS, the recruiting and staffing CRM/ATS, through its Evo REST API: candidate (Resource) retrieval by GLYDE UUID or Tracker id, live candidate/job search against Tracker's paged search operations, application (OpportunityResource) reads and creation, API-managed webhooks for Resource, Opportunity, and Application changes, and 141 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 OAuth2 with a JWT token exchange — GLYDE's Tracker app credentials are deployment-global, and each tenant authorizes once through a refresh token that GLYDE exchanges for a ~7-day Tracker JWT.

TrackerRMS data flows through GLYDE Unity's index-centric normalization pipeline, converting Tracker's PascalCase fields (GivenName, FamilyName, PostCode) to GLYDE's canonical snake_case format with ISO dates. Search results are cached in Redis and queued for background Azure AI Search indexing; inbound webhooks keep the cache fresh (event-assisted caching, 4-hour TTL hint).

Architecture & Data Flow

GLYDE Unity acts as an orchestration layer between consuming platforms (Teams, Copilot, Power Platform, SDK) and the TrackerRMS Evo REST API (https://evousapi.tracker-rms.com). Requests are authenticated, normalized, and routed through the integration adaptor's candidates, applications, and search sub-adaptors; jobs are index-only and advanced operations run through the ATS proxy. The adaptor's live search legs classify free text into Tracker's strict find semantics (name vs email vs phone) before calling SearchResources / OpportunityPagedSearch.

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                       │
    │  ┌─ TrackerRMS Integration Adaptor ┐ │
    │  │  Sub-Adaptors:                  │ │
    │  │   candidates (GetResource)      │ │
    │  │   applications (Opportunity-    │ │
    │  │     Resource search/create)     │ │
    │  │   search (custom find legs)     │ │
    │  │   messages / jobs (base)        │ │
    │  └────────────────────────────────┘ │
    │              |                       │
    │              v                       │
    │  ┌─ TrackerRMS External Connector ┐ │
    │  │  tracker-rms-connector.ts      │ │
    │  │  141 OpenAPI Operations        │ │
    │  │  TrackerRmsConnectorAuth-      │ │
    │  │    Manager: OAuth2 + Exchange  │ │
    │  │    Token → JWT (~7 days)       │ │
    │  └────────────────────────────────┘ │
    └──────────────|──────────────────────┘
                   |
                   v
    ┌──────────────────────────────────────┐
    │      TrackerRMS Evo REST API         │
    │  https://evousapi.tracker-rms.com    │
    │  /api/v1/...                         │
    │                                      │
    │  Resource | Opportunity |            │
    │  OpportunityResource | Project |     │
    │  Client | Contact | Webhook          │
    └──────────────────────────────────────┘

Authentication

Credential Fields

Session Management

Sessions are cached in Redis with the key pattern session:client:{clientUuid}:integration:tracker. The session carries the Tracker JWT and the x-api-key context. Tracker omits expires_in on the exchange response, so the session expiry is derived from the JWT exp claim (~7 days) and the JWT itself is re-validated before each use.

Token Refresh

When the JWT is expired or invalid, the manager re-runs the refresh-token flow (Tier 1) or the OAuth access-token exchange (Tier 2) automatically. Two implementation quirks are handled for you: the scope parameter must NOT be sent to /oAuth2/Token (Tracker rejects it with invalid_grant), and a tenant secret mis-seeded with the REST API key is detected and discarded in favor of the deployment-global secret.

Capabilities

Platform Access

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

Entity Mappings

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

Candidate → Resource

Job → Opportunity

Application → OpportunityResource (assignment: Project)

Endpoint Reference

Events & Webhooks

TrackerRMS supports API-managed inbound webhooks. GLYDE Unity provisions webhook registrations remotely through Tracker's own webhook API (AddHook, Update, GetHooksList, DeleteHook), pointing them at the Unity inbound receiver (POST /api/unity/events/webhook/:clientUuid/tracker). Registration is idempotent — existing hooks are detected and reused. Events are normalized to the canonical EventObject format via the passthrough normalizer and drive event-assisted cache refresh (4-hour TTL hint).

Subscription Model

The default outbound subscription (tracker-app-notifications) delivers rollup event types candidate.*, job.*, and application.* to platform trigger subscriptions. There is no polling fallback and no event replay — if a webhook delivery is missed, refresh the entity via a direct read.

Configuration Requirements

• Tenant OAuth Grant (Refresh Token)REQUIRED

  Each tenant completes the Tracker OAuth consent flow once (GLYDE Buddy callback) or supplies a refresh token / OAuth access token. Stored per tenant in Key Vault; exchanged for a Tracker JWT automatically.

  refresh_token: "xxxxxxxx"

• GLYDE Tracker App Credentials (Deployment-Global)REQUIRED

  The GLYDE-side Evo API client id and client secret, stored as Azure Key Vault secrets (TrackerClientId / TrackerClientSecret) and wired via TRACKER_CLIENT_ID / TRACKER_CLIENT_SECRET. Shared across tenants; a tenant secret mis-seeded with the REST API key is detected and discarded.

  TRACKER_CLIENT_ID="EvoApi_1.0", TRACKER_CLIENT_SECRET="********"

• Tracker REST API Key (Optional)

  Optional per-tenant x-api-key for the Tracker REST surface; preserved in session context and sent alongside the JWT.

  api_key: "xxxxxxxx"

• Integration TypeREQUIRED

  The client's integration_type must be "tracker" (or "trackerrms", which normalizes to "tracker") for the adaptor router to select the TrackerRMS integration.

  integration_type: "tracker"

• Environment Configuration

  Deployment-level env vars: TRACKER_CLIENT_ID, TRACKER_CLIENT_SECRET, TRACKER_OAUTH_BASE_URL (regional: evoapius/evoapica/evoapi), TRACKER_REDIRECT_URI, and TRACKER_RMS_API_URL (defaults to https://evousapi.tracker-rms.com).

  TRACKER_OAUTH_BASE_URL="https://evoapius.tracker-rms.com"

• TrackerConfiguration (Deep Links)

  The tenant's TrackerConfiguration.TenantURL enables GLYDE deep links back into Tracker entity summaries (https://<sub>.tracker-rms.com/Tracker/Candidate|Job/Summary?id=...).

  TrackerConfiguration.TenantURL: "https://myco.tracker-rms.com"

Known Limitations

• 100-Row Hard Cap: every Tracker Search* operation accepts maxResults up to 100; above that Tracker returns HTTP 400 ("Maximum Results cannot exceed 100"). Paginate with pageNumber.
• Resource Search Is a Find, Not Full Text: searchTerm matches the candidate display name (displayAs) only; dedicated email and telephone fields exist. Skills/role/location intents must be served from the GLYDE index (weighted/AI search), not the Tracker leg.
• Invalid state Silently Returns Zero Rows: the Resource state filter takes pipeline stage values only (Applied, CVReview, CVSend, Shortlisted, Interview, Offer, Working, Rejected, Complete, Internal, ShortlistedByUser, ShortlistedByResource). Omit it by default — values like "open" or "active" return empty results without an error.
• Sort Column Restrictions: sortBy: lastupdateddatetime is the only confirmed valid sort (Tracker-wide audit column); other values (e.g. the OpenAPI sample "name") are invalid.
• No Candidate Create/Update: no Tracker outbound candidate mapping is implemented; candidate writes must go through the ATS proxy.
• No Application Update: only creation (AddOpportunityResource) and reads (SearchOpportunityResources) are supported.
• Composite Application Id: Tracker has no get-by-id for applications — lookups require the composite opportunityId:resourceId (or the opportunityResourceId when present).
• No Live Job Leg: job get/find are index-only; live Tracker job operations go through the proxy (SearchOpportunities, GetOpportunity).
• No Communication Write-Back: emails/SMS sent through GLYDE are never logged back into Tracker as notes/activities.
• No Directory Live Leg: company/contact directory search is index-only for Tracker; rows enter the directory via POST /api/unity/directory/ingest imports. Tracker's ClientPagedSearch/ContactPagedSearch remain reachable through the ATS proxy.
• No Polling Fallback or Replay: events are webhook-only; missed deliveries require a direct entity refresh.
• Empty Results Are a Success: empty Tracker search results return a success envelope with an explicit "do not retry alternative operations" message, to stop LLM escalation to other Tracker ops.

Version History