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 composerID reads to track services and SOW sourcing intent end to end.

API at a glance Minimum viable mapping Custom fields & tenant mapping

Publish path

Direct API

composerID adapter → Globality API

Events back

Push events

native webhooks / events back

API access

Open docs

public developer portal

Contract tier

Tier A

full loop: publish + events back

Tenant configuration (mandatory fields, approval chains, picklists) is a separate gate from vendor capability: it is discovered at preflight before first publish and may need destination admin changes. How composerID connects →

Reference

API at a glance

The public API facts composerID'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.

Developer access

The Globality API details are for registered developers

Auth model, base URLs, event posture and rate limits, free with a developer account.

Get free access → Registered developers are recognised automatically.

Readiness

Docs confidence: Public

“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

composerID 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, composerID emits an enrichment_request back to the intake layer.

Mapping

Minimum viable mapping for Globality

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
Intent ID correlation Carry the Intent ID	intent_id, intent_version	Project external reference (link-only until write support confirmed)	Required	Read-centric API: composerID records the intent_id ↔ project linkage on its own side

Developer access

The field-level mapping is for registered developers

Object targets, canonical fields and the Intent ID carrier for Globality, free with a developer account.

Get free access → Registered developers are recognised automatically.

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, composerID supports reconciliation: it compares the platform record snapshot to the canonical intent and flags drift.

Tenant specifics

Custom fields & unique mapping

Real deployments rely on program-specific custom fields (for compliance, approvals, GL coding, rate rules or supplier constraints). composerID is designed to generate tenant‑specific mappings rather than forcing you to redesign your intake.

How scanning works

High-level flow

connect_destination() → read required fields + picklists (where permitted) → detect custom fields / extensions → build MappingProfile + validation rules → preflight intent against tenant requirements

What gets produced

Portable artefacts

MappingProfile (tenant-scoped) Capabilities matrix Required-field rules Picklist dictionaries Enrichment prompts Audit spine links (defence_file_ref)

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.

Developer access

Tenant-mapping notes are for registered developers

Where Globality deployments differ tenant to tenant, and what to check before first publish.

Get free access → Registered developers are recognised automatically.

Implement the adapter

Use this page alongside the API + Schemas docs to implement: destination connection, preflight validation, publish, webhook back-sync and reconciliation.

Back to Platforms How integrations work API reference