GLYDE Unity + AviontéBOLD

Overview

GLYDE Unity provides a comprehensive, bi-directional integration with AviontéBOLD, the staffing industry's enterprise applicant tracking and workforce management platform. This integration enables recruiters, hiring managers, and AI agents to access Avionté talent records, job postings, applications, and activities through a unified API layer.

The integration spans the full GLYDE ecosystem: Microsoft Teams, Copilot for Microsoft 365, Power Automate, the GLYDE Chrome Extension, 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 with automatic token management.

Avionté data flows through GLYDE Unity's index-centric normalization pipeline, ensuring consistent data representation across all consumers regardless of Avionté's native field naming conventions (e.g., "Talent" instead of "Candidate", "Assignment" instead of "Placement").

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 AviontéBOLD REST API. Requests are authenticated, normalized, and routed through the integration adaptor which handles entity-specific business logic, data mapping, and error classification.

Teams / Copilot / Power Platform / Chrome Ext / 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                       │
    │  ┌─ Avionté Integration Adaptor ─┐  │
    │  │  candidates.ts / jobs / etc.  │  │
    │  │  Template Method Pattern      │  │
    │  │  Data Mapping (Index-centric) │  │
    │  └──────────────────────────────┘   │
    │              |                       │
    │              v                       │
    │  ┌─ Avionté External Connector ──┐  │
    │  │  avionte-connector.ts         │  │
    │  │  ConnectorAuthManager (OAuth2)│  │
    │  │  OpenAPI-driven operations    │  │
    │  └──────────────────────────────┘   │
    │              ^                       │
    │              │ webhooks (inbound)    │
    │  ┌─ Event Normalizer ────────────┐  │
    │  │  AvionteEventNormalizer       │  │
    │  │  FrontOfficeTenantId →     │  │
    │  │  tenant resolution            │  │
    │  └──────────────────────────────┘   │
    └──────────────|──────────────────────┘
                   |
                   v
    ┌──────────────────────────────────────┐
    │      AviontéBOLD REST API            │
    │   {tenant}.avionte.com/api/v1/*      │
    │                                      │
    │   Talent | Job | Application |       │
    │   Company | Assignment | Activity    │
    └──────────────────────────────────────┘

Authentication

Credential Fields

Session Management

Sessions are cached in Redis with the key pattern session:client:{client_uuid}:integration:avionte (encrypted Unity session blob). The session includes the OAuth2 access token, expiration timestamp, tenant identifier, and resolved service URL. TTL follows the platform profile (default connector cache window). Sessions are re-validated on each request via ConnectorAuthManager.

Token Refresh

The AvionteConnectorAuthManager checks token expiration before each API call. If the token is expired or within the refresh threshold, a new token is obtained via the client credentials flow. The OAuth2 scope is avionte.aero.compasintegrationservice. JWT tokens are validated for expiration using the exp claim.

Capabilities

Platform Access

GLYDE Unity provides unified access to AviontéBOLD across multiple Microsoft 365 and developer platforms.

Entity Mappings

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

Candidate → Talent

Job → Job

Application → Application

Placement → Assignment

Endpoint Reference

Events & Webhooks

Avionté inbound webhook processing is live and connector-owned. Inbound webhooks are received at POST /api/unity/events/webhook/avionte, the tenant is resolved from FrontOfficeTenantId via ExternalMappings, and events are normalized to the canonical GLYDE format by AvionteEventNormalizer before entering the event queue. Outbound delivery to Power Automate, notifications, and other destinations is configured per tenant through the event configuration endpoints. Event-assisted cache refresh keeps the GLYDE search index current as Avionté records change.

Configuration Requirements

• OAuth2 Client CredentialsREQUIRED

  Avionté issues client_id and client_secret for API access. These must be stored in Azure Key Vault via the GLYDE Unity client configuration.

  client_id: "glyde-integration-client"

• Tenant IdentifierREQUIRED

  The Avionté tenant identifier is required for all API calls and is injected as the Tenant HTTP header. This is typically the company's Avionté instance identifier.

  tenant: "acme-staffing"

• Activity Type ConfigurationREQUIRED

  Client-specific activity type IDs for logging notes in Avionté. Configured in integration_data.AvionteConfiguration. Resolution order: general_activity_type, then Talent.general_activity_type (human_review uses Talent.human_review_activity_type).

  AvionteConfiguration.general_activity_type: 42

• Activity Author User IDREQUIRED

  Avionté user ID used as the author for GLYDE-created activities. Resolution order: new_submission_user, then glyde_user_id, then recruiter ExternalMappings (source=avionte, type=recruiter) for the requesting GLYDE user.

  AvionteConfiguration.new_submission_user: 1001

• Human Review Activity TypeREQUIRED

  Activity type ID for "Glyde Contact Requested" notes (human_review flag). Configured per-client in AvionteConfiguration.Talent.human_review_activity_type.

  AvionteConfiguration.Talent.human_review_activity_type: 15

• Webhook Subscription (Optional)

  To receive live Avionté events, register the GLYDE webhook URL ({unityBaseUrl}/api/unity/events/webhook/avionte) in the Avionté webhook configuration and ensure an ExternalMapping exists for the FrontOfficeTenantId. Default subscriptions can be provisioned via POST /api/unity/events/defaults/sync.

  Webhook URL: https://api.glydeunity.com/api/unity/events/webhook/avionte

• Chrome Extension ID (Optional)

  When using the GLYDE Chrome Extension for ATS cache sync, set UNITY_AVIONTE_EXTENSION_CHROME_ID so the extension origin is allowed to complete OTP registration and enqueue candidate IDs.

  UNITY_AVIONTE_EXTENSION_CHROME_ID: "abcdefghijklmnopqrstuvwxyz"

• Integration TypeREQUIRED

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

  integration_type: "avionte"

• API Base URL (Optional)

  Override the default AviontéBOLD API base URL if using a non-standard endpoint.

  service_url: "https://api.avionte.com"

Known Limitations

• No live search API for Talent or Jobs. Avionté exposes no search/filter endpoint — GLYDE serves candidate/job search from the Azure AI Search index and uses QueryMultipleTalents/QueryMultipleJobs batch reads for live pulls. The connector's canonical searchCandidates/searchJobs methods return NOT_IMPLEMENTED and atsProfile.searchCapabilities.supported is false.
• Candidate entity is called "Talent" in Avionté — all API operations use this naming convention.
• Placement entity is called "Assignment" in Avionté.
• Record updates use full PUT (not PATCH) — all fields must be provided on updates, not just changed fields.
• Application updates return NOT_IMPLEMENTED — Avionté does not support direct application modifications through the current API version.
• Live job get-by-id is not implemented — job reads resolve from the GLYDE search index; only create and update write through to Avionté.
• Job notes are not supported — unified activities write talent activities only (CreateTalentActivity). Activity retrieval from Avionté is not implemented.
• SMS messages are sent via Twilio but do not create an Avionté activity note (email does).
• Job create requires Avionte front_office__JobDto fields — map UI payload via JobDataMapper, inject branchId / ownerUserId server-side, and supply tenant Avionte ids from AvionteConfiguration (company_id, job_status_id, job_contact_id, job_order_type_id, front_office_id, worksite_address_id) on integration_data and/or unity_configuration.
• The Avionté OpenAPI spec uses camelCase field naming, which differs from GLYDE Unity's snake_case convention. Mapping is handled automatically.
• Entity metadata inspection may return 501 from the connector for some entity types — Buddy falls back to the atsProfile.entities catalog with a structured "unsupported" envelope.
• Pagination uses offset/limit pattern with a default limit of 25 records per page.
• The Tenant header is required for all API calls and is automatically injected by the connector.
• Avionté deep links require the tenant atsBaseUrl (myavionte.com subdomain) to be configured; otherwise links fall back to the GLYDE Screen /dl/ resolver.
• There is no dedicated Avionté recommended-fields provider for LLM tool calls — prompts rely on unityInspectATSOperation / unityInspectATSEntityFields output.

Version History