Beeline

This page records how composerID publishes into Beeline: the vendor’s API posture, the publish target and field mapping, and the documentation each claim rests on. It is for anyone evaluating the connection or building against it. 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.

Category: Vendor Management & Sourcing. Coverage status: Specification mapped. Vendor documentation: public developer portal.

Integration path

How composerID connects to this destination, at a glance.

Step	Detail
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.
composerID publishes	Business Intake Request: POST /sites/{clientSiteId}/business-intake-requests (business-intake_2025-01-01)
Intent ID lands on	`business_intake_request` `externalId`, written into the destination record
Back-sync	Webhooks: the destination pushes events; composerID verifies each delivery and lands it on the intent’s timeline.

Vendor documentation

Beeline Developers Portal

API catalog

Authentication overview

Integration use cases

FAQ (rate limits, tokens, webhooks)

Reporting as a Service (RaaS)

Supplemental Data Service (report-based reads)

API posture

Aspect	Detail
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.
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.
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.
Events posture	Webhooks
Rate limits	Client APIs: 1,000 requests/minute. Client Bulk APIs: 750 PUT/POST and 100 GET requests/minute (portal FAQ).
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

Publish target and field mapping

Each object below pairs the canonical intent fields with the destination’s own fields and operations. The mapping is indicative until it is confirmed against a tenant at onboarding.

Business Intake Request

Create the worker request

Mapping	Detail
Canonical to destination	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
Target	POST /sites/{clientSiteId}/business-intake-requests (business-intake_2025-01-01)
Requirement	jobTitleId, hiringManagerId, workLocationId, quantity, startDate + tenant required
Notes	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

Mapping	Detail
Canonical to destination	intent_id → externalId
Target	externalId on the business intake request: client-supplied and filterable on the list endpoint (?externalId=). trackingNumber on the intake-form path
Requirement	Required
Notes	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

Mapping	Detail
Canonical to destination	sow.status, milestones, payments, dates ← reads; approve/reject → approvals
Target	Project Agreement Management API (sow_2025-01-01): GET SOWs/milestones/payments + POST approvals; SOW lifecycle webhooks
Requirement	Read scope only
Notes	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

Mapping	Detail
Canonical to destination	worker_id, assignment_id, start_date, end_date, rate, status
Target	worker-management_2023-07-01 (#tag/Assignment, #tag/Worker)
Requirement	Required
Notes	Drives reconciliation: assignment amendments, extensions and terminations show as drift against the Intent Record

Bulk read

Reconciliation at programme scale

Mapping	Detail
Canonical to destination	intent_id (filter), status, updated_at
Target	RaaS (supplemental-data_2025-09-01): GET /sites/{clientSiteId}/RunReport/{reportId}, one report per call
Requirement	Recommended
Notes	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

Deep links and scenarios

Each scenario names the direction of travel (publish, read or round-trip), the flow, and the vendor APIs it uses. Deep-link shapes are illustrative and confirmed per tenant.

Open a job (contingent request)

Publish

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

Read

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)

Read

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

Read

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

Read

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

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.

Sent

Field	Content	Source
`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

Read 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.

Never sent

This list is a promise composerID keeps true: none of the following crosses the boundary.

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.

Access we ask for

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

Excluded: 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.

What proven will mean

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.

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.

Next steps

How composerID connects

The five ways composerID reaches a destination, and the minimum a destination must offer.

Publishing

Plan, preflight and publish: how a decision becomes a valid record in a destination.

All destinations

Every destination composerID documents, with its category and coverage status.

⌘I

Get started

Concepts

Guides

Destinations

Upstream connectors

API reference

Endpoints

Manuscript API (Triage)

Manuscript endpoints

Resources

Integration path

Vendor documentation

Beeline Developers Portal

API catalog

Authentication overview

Integration use cases

FAQ (rate limits, tokens, webhooks)

Reporting as a Service (RaaS)

Supplemental Data Service (report-based reads)

API posture

Publish target and field mapping

Deep links and scenarios

What crosses the boundary

Sent

Read back

Never sent

Access we ask for

What proven will mean

Next steps

How composerID connects

Publishing

All destinations

​Integration path

​Vendor documentation

Beeline Developers Portal

API catalog

Authentication overview

Integration use cases

FAQ (rate limits, tokens, webhooks)

Reporting as a Service (RaaS)

Supplemental Data Service (report-based reads)

​API posture

​Publish target and field mapping

​Deep links and scenarios

​What crosses the boundary

​Sent

​Read back

​Never sent

​Access we ask for

​What proven will mean

​Next steps

How composerID connects

Publishing

All destinations

Integration path

Vendor documentation

API posture

Publish target and field mapping

Deep links and scenarios

What crosses the boundary

Sent

Read back

Never sent

Access we ask for

What proven will mean

Next steps