> ## Documentation Index
> Fetch the complete documentation index at: https://www.composer.id/llms.txt
> Use this file to discover all available pages before exploring further.
# Beeline
> Beeline (Vendor Management & Sourcing): the API posture, publish target and field mapping composerID publishes a decision reference through.
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](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
## API posture
| Aspect | Detail |
| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Authentication | OAuth 2.0 client credentials: POST [https://integrations.auth.beeline.com/oauth/token](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](https://client.beeline.com/api) and [https://client-eu.beeline.com/api](https://client-eu.beeline.com/api) (paths under /sites/\{clientSiteId}/…), Bulk APIs at [https://edge.beeline.com](https://edge.beeline.com) and [https://edge-eu.beeline.com](https://edge-eu.beeline.com) (/client-onboarding, /worker), RaaS at [https://raas.beeline.com/api](https://raas.beeline.com/api) and [https://raas-eu.beeline.com/api](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.
| 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 |
| 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 |
| 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 |
| 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 |
| 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.
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)`
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)`
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)`
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)`
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)
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
The five ways composerID reaches a destination, and the minimum a destination must offer.
Plan, preflight and publish: how a decision becomes a valid record in a destination.
Every destination composerID documents, with its category and coverage status.