SimplifyVMS (platform)

SimplifyVMS (Simplify Workforce Inc., Jersey City) is a cloud-native VMS that runs contingent staffing, statement-of-work services procurement, direct sourcing, and credentialing and compliance in one platform, built for multi-country deployment. composerID treats it as a destination system of record: Intent Records are published onto its native requisition and SOW objects and the audit spine is kept, with tenant mapping validated in a customer sandbox because no public endpoint reference was found and the API is treated as customer-scoped.

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

Publish path

Via onboarding

endpoints and credentials provisioned by SimplifyVMS 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	Customer-provisioned credentials. The vendor describes a documented API for custom integrations and Simplify Bridge connectors for packaged ones; the auth flow (OAuth 2.0 vs API key) is confirmed per tenant at onboarding.
API style	Vendor-documented API for custom integrations plus Simplify Bridge, a no-code connector layer with data mapping, transformation, conditional logic and error handling, which the vendor says has integrated across 80+ back-office systems (Workday, Oracle, ADP, SAP, Ariba, Coupa among them). No public endpoint reference was found, so it is treated as customer-scoped until onboarding.
Base URL	Provisioned per customer tenant. No public base URL.
Objects	Requisition (job), Assignment (the vendor's work-order terminology is confirmed per tenant), Worker, Timesheet and expenses, Statement of Work (fixed fee, recurring, time and materials, unit-based or hybrid; milestones, deliverables, SLAs and acceptance criteria), Supplier (tiered), Invoice
Events / webhooks	Not publicly documented. Simplify Bridge advertises real-time synchronisation between connected systems, so event or webhook options are confirmed per tenant; composerID plans poll-based reconciliation until then.
Rate limits	Not publicly documented; set by the tenant integration agreement.

Developer access

The SimplifyVMS 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 SimplifyVMS

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
Requisition (Contingent) Create the job / worker request	role_title, location, start_date, end_date, cost_center, worker_type, rate_card	Requisition via customer API	Tenant required	Requisition and job-distribution flow; supplier tiering is tenant configuration
Statement of Work (Services) Create the SOW record	scope, sow_type, milestones[], deliverables[], budget, start_date, end_date, supplier	SOW module via customer API	Tenant required	sow_type maps to the module's fixed fee / recurring / T&M / unit / hybrid types; clause and template choice stays inside SimplifyVMS
Assignment / work order Assignment lifecycle read-back	worker_id, dates, rate, status	Customer API (read)	Read only	Back-sync into the intent timeline; poll-first until tenant events are confirmed. Vendor object name confirmed at onboarding
Intent ID correlation Carry the Intent ID	intent_id, intent_version	Custom field on the requisition / SOW	Required	Customer-scoped API: field key agreed with the joint customer at onboarding

Developer access

The field-level mapping is for registered developers

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

SimplifyVMS API documentation is customer-scoped; the public material describes the integration platform, not endpoints. composerID starts with the minimum viable mapping above and relies on tenant discovery (required fields, custom fields, SOW types, supplier tiers) to generate a working MappingProfile. Where a customer already runs Simplify Bridge, composerID publishes to the VMS directly and leaves Bridge to its existing HRIS/ERP feeds.

Developer access

Tenant-mapping notes are for registered developers

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