Globality (platform)
Globality is an AI-guided services-sourcing platform. Its public REST API exposes a fixed domain model — Project to Brief to Provider to Proposal to Award — that VMS Agent reads to track services and SOW sourcing intent end to end.
The public API facts VMS Agent's adapter relies on. Tenant-specific details (custom fields, picklists, approval chains) are confirmed during connection and folded into the MappingProfile.
| Authentication | OAuth 2.0 client-credentials to a Bearer JWT via Auth0 (POST https://globality-prod.auth0.com/oauth/token, audience per environment). Token TTL 24h. Scopes read:project / write:project. |
|---|---|
| API style | REST (JSON), versioned /v2, OpenAPI / Swagger |
| Base URL | US https://apis.prod.globality.com | EU https://apis.eu.globality.com |
| Objects | Project, Brief, Provider (supplier), Proposal, Award, Files |
| Events / webhooks | Yes — push webhooks (registered in-app). Events: ProjectBriefCompleted/Updated, ProposalSubmitted/Approved, AwardCompleted, ProjectStatusChange. Thin payload to call back to /v2 for detail. Retries at 1/3/6/12/24h. |
| Rate limits | Not publicly documented; confirm per tenant. |
“Docs confidence” describes how deterministic our mapping templates can be before we connect to a tenant. Even with public docs, implementations vary — especially around custom fields, approval flows and object extensions.
Deterministic mapping
Common Workforce Model fields map to known API fields. Best for standard objects (requisitions, assignments, timesheets, POs).
Tenant discovery
VMS Agent can scan tenant configuration (custom fields, picklists, required fields) where the platform permits it, then generate a tenant‑specific MappingProfile.
Enrichment loop
If the target platform requires a field the Intent record doesn't yet have, VMS Agent emits an enrichment_request back to the intake layer.
An opinionated baseline. The platform adapter enforces additional requirements via preflight. “Tenant required” fields are discovered during connection and added to the MappingProfile.
| Object | Canonical fields | Platform target | Required status | Notes |
|---|---|---|---|---|
| Project (create) Container for sourcing intent |
service_category, sow.summary, budget, dates | POST /v2/projects | Required | Project is the sourcing-intent container |
| Brief (read) Scoped requirement |
requirement, budget, timeline, services | GET /v2/projects/{id} | Read | Auto-created from the intake form |
| Award (read) Outcome / receipt |
completion, dates, po_ref | webhook AwardCompleted then GET /v2 | Read | Feeds the publish receipt |
Idempotency & drift — publish + reconcileExpand
Publish operations are idempotent using a deterministic key {intent_id}-{intent_version}-{target_system}. Because humans can change records inside the platform, VMS Agent supports reconciliation: it compares the platform record snapshot to the canonical intent and flags drift.
Real deployments rely on program-specific custom fields (for compliance, approvals, GL coding, rate rules or supplier constraints). VMS Agent is designed to generate tenant‑specific mappings rather than forcing you to redesign your intake.
How scanning works
High-level flow
What gets produced
Portable artefacts
Important — where this platform is tenant-definedExpand
Public docs + OpenAPI, but credentials are customer-gated (an admin assigns the in-app Developer role). Region-specific base URLs and Auth0 audience per environment. The API is read-centric — Project create + status update only; there is no public endpoint to push your own supplier lists. Pre-built connectors exist for Ariba, Fieldglass and Coupa.
Use this page alongside the API + Schemas docs to implement: destination connection, preflight validation, publish, webhook back-sync and reconciliation.