Beeline (platform)

Beeline is a vendor-neutral VMS commonly chosen for best-of-breed contingent workforce programmes, and the first destination composerID is integrating. Its developer portal publishes machine-readable OpenAPI specifications for a current generation of Client APIs: worker management (request, intake form, candidate, assignment, worker), business intake, project agreement (SOW) reads and approvals, supplier, invoice, time-and-expense, attachment, program and foundational data. Alongside them sit a Webhook Management API and Reporting-as-a-Service for programme-scale reads. The request objects carry a client-supplied externalId, filterable on reads, which is where the Intent ID travels. Beeline's own integration scenarios include exactly composerID's pattern: an intake started in an external system, automated into Beeline, and completed there.

API at a glance How it runs Minimum viable mapping Deep links & scenarios What crosses the boundary Custom fields & tenant mapping

Publish path

Direct API

composerID adapter → Beeline 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 →

Shape of the integration

How the Beeline integration runs

One decision, one publish, one identifier that survives the whole round trip. Everything drawn here is an endpoint or event in Beeline’s published specifications.

The dark line is the Intent ID: minted at the decision, carried into Beeline as the request's externalId, and used to re-find the record on every read. The dashed step inside the tenant is the MSP's, not ours. The accent return path is how the engagement reports back: real-time webhooks, the event-history endpoint when a push is missed, and RaaS reports for a whole programme at once.

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: POST https://integrations.auth.beeline.com/oauth/token (EU: integrations.eu-auth.beeline.com) with audience set to the target API's base URL. Tokens last 24 hours. Scopes are granted per API product and listed on each spec under Authorizations; a 403 means a missing scope for the site.
API style	REST/JSON. Current-generation Client APIs (worker-management, business-intake, sow, supplier-management, invoice-management, attachment, reference-data, program-data, foundational, bte, webhook-management, each a dated version such as worker-management_2023-07-01) alongside Bulk APIs (client onboarding, worker; async import/export) and RaaS (the supplemental-data_2025-09-01 spec), which exposes any Report Builder report as a JSON endpoint.
Base URL	Three regional gateway pairs. Client APIs at https://client.beeline.com/api and https://client-eu.beeline.com/api (paths under /sites/{clientSiteId}/…), Bulk APIs at https://edge.beeline.com and https://edge-eu.beeline.com (/client-onboarding, /worker), RaaS at https://raas.beeline.com/api and https://raas-eu.beeline.com/api. The site id and credentials are issued at onboarding.
Objects	Business Intake Request, Intake Form, Request, Candidate, Assignment, Worker, Statement of Work (read/approve), Project, Task, Timesheet, Invoice (read), Supplier, Attachment; Purchase Order via the Bulk gateway only
Events / webhooks	Webhook Management API: subscribe to events for assignments, candidates, suppliers, timesheet submission, SOW approvals, bids and more (~98 event types). Delivery auth is chosen per subscription: HMAC (Beeline stores a base64 secret the subscriber supplies) or OAuth2 against the subscriber's issuer, with a validate-code handshake proving endpoint ownership. Events fire in real time and duplicates can occur; missed events can be retrieved from the event-history endpoint, so recovery does not depend on the push arriving.
Rate limits	Client APIs: 1,000 requests/minute. Client Bulk APIs: 750 PUT/POST and 100 GET requests/minute (portal FAQ).

Developer access

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

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
Business Intake Request Create the worker request	job_title → jobTitleId · requester → hiringManagerId · location → workLocationId · quantity → quantity · start_date → startDate (all five required by the create schema); end_date → endDate or duration; role_title → requestName	POST /sites/{clientSiteId}/business-intake-requests (business-intake_2025-01-01)	jobTitleId, hiringManagerId, workLocationId, quantity, startDate + tenant required	The four *Id fields are tenant UUIDs, resolved at preflight from program-data (job titles) and foundational (users, locations, cost centres). Beeline's Request Intake scenario is composerID's publish path
Intent ID correlation Carry the Intent ID	intent_id → externalId	externalId on the business intake request: client-supplied and filterable on the list endpoint (?externalId=). trackingNumber on the intake-form path	Required	Both are stock spec fields needing no tenant configuration. Where the programme wants the ID visible as a field on the record, a client-defined field is added via the documented client-defined-values PATCH
Statement of Work Services channel: read, approve, reconcile	sow.status, milestones, payments, dates ← reads; approve/reject → approvals	Project Agreement Management API (sow_2025-01-01): GET SOWs/milestones/payments + POST approvals; SOW lifecycle webhooks	Read scope only	SOWs are created inside Beeline. The API exposes no create endpoint, so this channel is read/approve, not publish. Approval-stage webhooks (pending initial/final approval and more) land milestones on the intent timeline
Worker / Assignment Read back the engagement	worker_id, assignment_id, start_date, end_date, rate, status	worker-management_2023-07-01 (#tag/Assignment, #tag/Worker)	Required	Drives reconciliation: assignment amendments, extensions and terminations show as drift against the Intent Record
Bulk read Reconciliation at programme scale	intent_id (filter), status, updated_at	RaaS (supplemental-data_2025-09-01): GET /sites/{clientSiteId}/RunReport/{reportId}, one report per call	Recommended	Cheaper than per-record polling across a whole programme. The spec authorises it with the same OAuth client credentials (scope run:raas); filtering by Intent ID presumes a report built with the externalId column

Developer access

The field-level mapping is for registered developers

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

Working with Beeline

Deep links & scenarios

Where composerID posts data into Beeline, where it reads data back, and where a person lands when they follow a link. Grounded in the scenarios on Beeline’s own developer portal; exact record URLs are confirmed per tenant at onboarding.

Open a job (contingent request)

composerID → Beeline

Triage classifies the request as contingent; composerID publishes it through the Business Intake API with the Intent ID in the request's externalId, a stock field that is filterable on reads, so the record is re-findable without storing Beeline internals. The intake appears in Beeline ready for the MSP to progress; the receipt links to the intake record, and the request link attaches when the MSP converts it.

APIs: business-intake_2025-01-01 · client-defined-values (optional visible field)

Deep link: {tenant_host}/intakes/{intake_id} (illustrative)

Partially complete a form

round trip

Beeline's own Request Intake scenario: an intake starts in an external system and is automated into Beeline, where the MSP reviews the form and creates the corresponding Request. The Intake Form API takes exactly one required field: a client-supplied trackingNumber, which carries the Intent ID. Everything else is free-text pre-fill for what Triage captured, and the deep link lands the MSP or manager on the form to finish the tenant-only fields. Nothing is retyped, and the form is queryable by tracking number.

APIs: worker-management_2023-07-01 (#tag/Request, intake-process/request-forms) · program-data + foundational (valid picklist values)

Deep link: {tenant_host}/intakes/{intake_id} (illustrative)

Open a bid / track supplier responses

Beeline → composerID

Once the request is live, bid and candidate-submission events arrive through the Webhook Management API. A candidate submission with its resume lands on the intent timeline as it happens, and the deep link opens the request's candidate list in Beeline.

APIs: webhook-management_2023-07-01 (bid.submitted, candidate.submitted) · worker-management (#tag/Candidate)

Deep link: {tenant_host}/requests/{request_id}/candidates (illustrative)

Follow an SoW (services channel)

Beeline → composerID

Statements of Work are created inside Beeline. Its API exposes no SOW create endpoint, and this page does not pretend otherwise. What the API does give the intent timeline: approval-stage webhooks as the SOW moves through its lifecycle, real-time reads of the SOW, its milestones and payments for reconciliation, and approve/reject calls on SOWs and milestone payments from wherever the approver works.

APIs: sow_2025-01-01 (Project Agreement Management: reads + approvals) · webhook-management (SOW events)

Deep link: {tenant_host}/sows/{sow_id} (illustrative)

Approve time and spend where it happens

Beeline → composerID

A timesheet submitted in Beeline raises a webhook; composerID retrieves the timesheet and financial detail so spend appears against the Intent ID, and can approve or reject it. Project milestone payments follow the same pattern: a pending event, a read, and an approve/reject call from wherever the approver works.

APIs: bte_2023-07-01 (#tag/Timesheet: read + approve/reject) · sow_2025-01-01 (milestone payments) · webhook-management (timesheet.submittedforapproval)

Programme-scale reconciliation

Beeline → composerID

Any Report Builder report becomes a JSON endpoint through Reporting-as-a-Service, one report per call, so composerID sweeps a programme for drift with a report keyed on externalId instead of polling record by record. Attachments come back as binary through the Attachment API when the evidence pack needs the source documents.

APIs: RaaS (supplemental-data_2025-09-01, scope run:raas) · attachment_2025-01-01

Assurance

What crosses the boundary

Triage decides and keeps the evidence; Beeline receives a valid request and the identifier that ties it back. This is the complete outbound payload of a contingent publish, taken from the create schema of business-intake_2025-01-01.

Beeline field	What it carries	Where the value comes from
jobTitleId	The job title being requested, as a Beeline UUID	Resolved from the site's own job-title list (program-data)
hiringManagerId	The requesting manager's Beeline user. The only person identifier sent	Resolved from the site's user list (foundational)
workLocationId	Where the work happens, as a Beeline UUID	Resolved from the site's work locations (foundational)
quantity	How many positions	The Triage decision
startDate, endDate or duration	When the engagement starts and ends	The Triage decision
billToCostCenterId, adminCostCenterId, timesheetApproverId	Cost coding and timesheet approver, where the site requires them	Resolved from the site's own lists
requestName, comments	A request title and a one-line provenance note. No diagnostic content	Composed by composerID
externalId	The Intent ID, so the record can be re-found and reconciled	composerID
clientDefinedValues	Only the fields a programme explicitly maps, such as a Source field	Agreed at onboarding

What comes back

Webhook events as references: the event id, type, time and the Beeline record ids needed for a deep link.
Request and intake status, so the timeline shows where the request has reached.
Assignment dates, rate and status, compared against the Intent Record to detect drift.
SOW approval state, milestones and payments for the services channel.
Timesheet and financial detail, so spend appears against the Intent ID.
Programme-wide reads through a RaaS report keyed on externalId, instead of polling record by record.

What is never sent

The diagnostic conversation: questions asked, answers given, scores, rankings or override events.
The Compliance File, or any link that would expose it without authentication.
Candidate or worker personal data. composerID collects none, and resumes stay in Beeline unless a programme puts them in scope.
Rates, budgets or commercial terms beyond what the programme's mapping explicitly includes.
Credentials, tokens or signing material belonging to any other system.

Assurance

Access we ask for, and what “proven” will mean

Beeline grants scopes per API product, so least privilege is checkable rather than promised. This is the full grant we ask for, and the grant we do not.

API product	Scopes requested	Why
Business Intake (business-intake_2025-01-01)	read:business_intake, write:business_intake, read:client_defined, write:client_defined	Publish the request and carry the Intent ID
Worker Management (worker-management_2023-07-01)	read:request, read:intake-form, write:intake-form, read:candidate, read:assignment	The intake-form path, and read-back for reconciliation
Webhook Management (webhook-management_2023-07-01)	read:webhook_management, write:webhook_management	Subscribe, validate the endpoint, recover missed events
Project Agreement Management (sow_2025-01-01)	read:sow, read:project	SOW and milestone read-back. No writes needed
Financial Time & Expense (bte_2023-07-01)	read:bte	Timesheet and spend read-back
Supplemental Data (RaaS)	run:raas	Programme-scale reconciliation reads

Not requested

No Foundational Data writes (write:iam, write:org, write:user, write:spend_authority), no supplier or invoice scopes, and no approval-write scopes. Approving time or candidates from a chat surface needs write:bte or write:candidate, which stays a separate and explicit grant rather than something bundled into the publish integration.

Sandbox exit criteria

Publish a contingent request end to end with the Intent ID in externalId, re-find it by the list filter, and replay a duplicate publish without creating a second record.
Create a webhook subscription, prove endpoint ownership with the validate handshake, verify delivery authenticity with the agreed method, and recover a deliberately missed event from event history.
Show preflight reading the site's own required fields and picklists, and rejecting an incomplete publish before it reaches Beeline.
Produce a field-level mapping document for the site. Only then does the public coverage status move beyond what the specifications alone support.

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

Everything on this page is verified against Beeline's published OpenAPI specifications (vendored with provenance in the engineering repo, 2026-08-13); it has not yet been exercised against a tenant. That is the sandbox phase, and the exit criteria are published on this page. Beeline programmes carry tenant-specific configuration: picklists and mandatory fields per programme, client-defined field definitions, and webhook subscriptions enabled per site. Scopes are granted per API product at onboarding, so preflight reads the tenant's own required-field set rather than assuming this page's list. Beeline documents no idempotency header, so duplicate safety is built on the externalId filter (find before create). Deep-link URL shapes on this page are illustrative and confirmed per tenant; the IDs they carry come from the APIs above.

Developer access

Tenant-mapping notes are for registered developers

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