Beeline (platform)
Beeline is a vendor-neutral VMS commonly selected for best-of-breed contingent workforce programs, with a broad public API surface. composerID publishes portable intent into Beeline and supports tenant-specific custom fields and picklists through discovery + enrichment.
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 via Auth0. Tokens scoped per client onboarding. |
|---|---|
| API style | REST (JSON) — 300+ APIs across hiring, invoicing and compliance. Data is tiered: foundational (org hierarchy, geographies), supportive (worker, onboarding), transactional (timecards, invoicing, maverick-spend). |
| Base URL | Per-tenant Beeline environment (provisioned at onboarding). |
| Objects | Requisition, Worker, Assignment, Timecard, Expense, Invoice, Supplier, Organizational hierarchy |
| Events / webhooks | Event/webhook support where enabled per program; otherwise poll transactional resources. Client Onboarding API accepts batch payloads with automatic create-vs-update detection (no client-side state). |
| Rate limits | 1,000 calls per minute per endpoint. |
“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.
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 worker request |
role_title, location, start_date, cost_center, worker_type | API resource (per portal) | Required + tenant required | Picklists + custom fields vary |
| Worker / Assignment Assignment lifecycle and status |
worker_id, start/end, rate, status | API resource (per portal) | Required | Use reconciliation for drift |
| Timesheet Time entry and approval flow |
assignment_id, period, hours, status | API resource (per portal) | Required | Webhook/event if available |
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.
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
What gets produced
Portable artefacts
Important — where this platform is tenant-definedExpand
Beeline implementations frequently include custom fields, program rules and approval steps. Public docs support the base adapter; tenant discovery completes the required-field set and MappingProfile for your program.
Use this page alongside the API + Schemas docs to implement: destination connection, preflight validation, publish, webhook back-sync and reconciliation.