Omnea (platform)

Omnea (London, founded 2022) is a procurement intake and orchestration platform, positioned by the vendor as the agentic operating system for procurement and supplier management: requests arrive in natural language via Slack, Teams or web, a no-code Workflow Builder routes them through approvals, supplier onboarding, risk checks and sourcing, and approved requests become purchase orders in the ERP through two-way integrations. composerID hands canonical intent to Omnea's intake and lets the orchestrated flow carry it to PO: Omnea is a complementary orchestration partner, not a destination-of-record.

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

Publish path

Via onboarding

endpoints and credentials provisioned by Omnea at onboarding; no public endpoint reference

Events back

Poll-first

scheduled reconciliation

API access

No portal evident

posture drawn from the vendor's integration material; confirmed at onboarding

Contract tier

Tier B

publish + poll reconciliation

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	Credentials provisioned per customer. The vendor describes integrations as out-of-the-box or via API; no public self-service developer portal was found, so the auth model (OAuth 2.0 vs API key) is confirmed at onboarding.
API style	Pre-built bidirectional connectors across ERP, CLM, HRIS, ticketing, eSign and TPRM data providers (NetSuite and PandaDoc named in customer material), plus API integrations for what the connectors do not cover. Omnea also ships an MCP server that exposes suppliers, purchase orders, spend and renewals to AI assistants. Endpoint-level reference is customer-scoped until onboarding.
Base URL	Per-customer tenant, provisioned at onboarding. No public base URL.
Objects	Intake request, Approval, Supplier (onboarding questionnaire, risk profile), Sourcing event, Contract and renewal, Purchase Order (created in the ERP)
Events / webhooks	The vendor states supplier records updated in the ERP are reflected in workflows immediately rather than synchronised overnight, so event-driven sync exists in the connector layer; outbound webhook specifications are not published and are confirmed per tenant.
Rate limits	Not publicly documented; defined per customer integration.

Developer access

The Omnea 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: Customer

No developer portal evident. We could not find a public self-service developer portal or endpoint reference for this platform; the API posture above is drawn from the vendor's own integration material and is confirmed at onboarding.

“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 Omnea

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
Intake request Create the request Omnea orchestrates	request_type, description, requester, cost_center, budget, supplier (if known), start_date	Intake request (Workflow Builder routing)	Tenant required	Natural-language intake fields are tenant-configured; composerID supplies the structured record so Omnea skips re-asking
Supplier Supplier the request is for	supplier_name, legal_entity, country, existing_supplier_id	Supplier object (onboarding + risk)	Tenant required	Triggers Omnea's onboarding questionnaire and TPRM checks when the supplier is new
Intent ID correlation Carry the Intent ID	intent_id, intent_version	Custom field on the intake request	Required	Field key agreed with the joint customer; read back onto the PO the ERP integration creates
Purchase Order Result of the orchestrated flow	po_number, supplier, amount, gl_code, dates	PO created in the ERP via Omnea's two-way integration (read)	Read only	composerID records the PO reference on the intent timeline; the ERP, not Omnea, is the system of record

Developer access

The field-level mapping is for registered developers

Object targets, canonical fields and the Intent ID carrier for Omnea, 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

Omnea is an orchestration layer over the customer's ERP, CLM, eSign and risk tooling, and its intake forms, approval chains and Workflow Builder logic are tenant-defined. Integration credentials, base URLs and any webhook specifications are provisioned by Omnea during onboarding; the public material describes the integration surface, not endpoints. Note the domain is omnea.co.

Developer access

Tenant-mapping notes are for registered developers

Where Omnea 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