Workflow API

Every legacy endpoint in this category and its replacement in the new Oneserve API (where one exists).

Legacy	Status	Replacement	Notes
addEvent	Replaced	POST /v1/jobs/{id}/events	POST /v1/jobs/{id}/events creates a typed JobEvent. The eventType code replaces legacy sigEventCode — look up valid codes from GET /v1/jobs/job-events. (see the endpoint page for the full call sequence) Not to be confused with the new /v1/events/* family, which is the OneCore integration/webhook subscription layer (a different concept).
addEventByClientRef	Replaced	POST /v1/jobs/{id}/events	The new endpoint addresses jobs by numeric id only — legacy clientRef lookup is gone. Resolve the clientRef first, then post the event. (see the endpoint page for the full call sequence) Cache the valid eventType codes from GET /v1/jobs/job-events rather than fetching per call.
cancelJob	Replaced	POST /v1/jobs/{id}/cancel
cancelJobV1	Replaced	POST /v1/jobs/{id}/cancel
clientLibraryActivities	Replaced	GET /v1/library-activities	Legacy getClientLibraryActivities filtered library activities by the calling user's resource (via Resource -> User -> ClientUsers -> ClientActivity). The new endpoint returns all library activities visible to the caller and supports a free-text search parameter only - it does not filter by resource id.
createJob	Replaced	POST /v1/jobs	Latest legacy createJob also accepted appointmentDate + zoneType to attempt a pooled appointment booking, plus a freeform attributes section for WorkType Attributes. Neither is present in the new POST /v1/jobs body - book appointments separately via POST /v1/appointments. Contact details are no longer accepted inline.
createJobV1	Replaced	POST /v1/jobs	Legacy expected a wrapped form-encoded body (jobs=<json-array>) with multiple jobs per call. The new endpoint creates a single job from a flat JSON object; contact and worklog info are no longer bundled in the same call (contacts/sites must exist first). If no teamId is supplied the new API picks a default team based on the workType.
getJob	Replaced	GET /v1/jobs/{id}
getJobs	Replaced	GET /v1/jobs	Legacy getJobsWithUnassignedActivities/{text}/{resourceId}/{maxResults} returned jobs with unassigned activities for a given resource's supplier, filtered by free text against job ref / site name / postcode. The new endpoint exposes a searchTerm query param but does not filter by "has-unassigned-activities" or by resource - check results client-side.
getNotes	Replaced	GET /v1/jobs/job-events	GET /v1/jobs/job-events returns the catalogue of job event types usable with POST /v1/jobs/{id}/events. Schema differs: legacy returned {id, note} filtered by a noteTypeId path param; the new endpoint returns {id, code, description} (where description ≈ legacy note) with no type filter, so clients filter client-side via the code field. To create a note on a job use POST /v1/jobs/{id}/notes.
jobApproval	Replaced	POST /v1/jobs/{jobId}/versions/required-approvals/{requiredApprovalId}/approve	The new API splits approvals into separate approve and reject endpoints with explicit approval IDs. Use GET /v1/jobs/{jobId}/versions/required-approvals to list pending approvals first.
jobs	Replaced	GET /v1/jobs	Legacy GET /rest/workflow/job/jobs/{startDate}/{endDate}/{clientIDs} returned jobs changed within a date range (max 1 month). The new endpoint filters by jobRefs/clientRef/workLogId/searchTerm only - there is no "changed-since" date filter. For change feeds use OneCore webhook event subscriptions instead of polling.
updateDescription	Replaced	POST /v1/jobs/{jobId}/version	No usage observed (April to June 2026); candidate for retirement. Legacy let you update a job's description (with appendDescription flag) preferably without creating a new version. The new API has no description-only update path - changes go via the standard versioning flow, which always creates a new job version. No "append vs replace" toggle in the new API.
updateJob	Replaced	POST /v1/jobs/{jobId}/version	The new API has no PATCH/PUT endpoint for jobs - all changes go via versioning. Open a new job version with POST /v1/jobs/{jobId}/version, apply your changes, then either submit/approve (POST /v1/jobs/{jobId}/versions/required-approvals/...) or cancel (POST /v1/jobs/{jobId}/version/cancel). Activity diffing (add/update/delete) from the legacy body is handled implicitly by supplying the desired activity set in the version payload.
updateJobV01	Replaced	POST /v1/jobs/{jobId}/version	Earlier-version updateJob always created a new job version and used a submitVersion flag to choose whether to submit it. In the new API the version creation and submission/approval are separate steps - POST /v1/jobs/{jobId}/version creates the version; approve/reject endpoints submit it.
updateJobV20	Replaced	POST /v1/jobs/{jobId}/version	All job updates go through versioning in the new API. POST a new version with the changed fields and activity set; supply changes per job id (the legacy bulk-array form is not supported).
activityHistory	No replacement	—	No usage observed (April to June 2026); candidate for retirement. Legacy GET /rest/workflow/activity/history/{startDate}/{endDate}/{clientGroupId}/{clientIdList}/{eventId} returned activity-history events across many jobs in a date range, filtered by client group and event ID. The new GET /v1/jobs/{id}/activities requires a single job id and does not support date-range or cross-job filtering. No equivalent cross-job activity history endpoint exists.
addActivity	No replacement	—	Legacy POST /rest/workflow/activity/addActivity added activities to a job/appointment (creating a new job version if versioning is enabled). The new API has no direct write endpoint for activities - only GET /v1/jobs/{id}/activities. Activities are part of the job create/version request body (POST /v1/jobs and POST /v1/jobs/{jobId}/version); use those flows to add activities.
addActivityByClientRef	No replacement	—	Legacy POST /rest/workflow/activity/addActivityByClientRef added activities to a job looked up by client ref (with optional submitVersion flag). The new API has no direct write endpoint for activities - lookups by client ref are also no longer supported on this path. Add activities via POST /v1/jobs (on create) or POST /v1/jobs/{jobId}/version (on existing jobs); jobs are addressed by internal id, not client ref.
deleteActivity	No replacement	—	No usage observed (April to June 2026); candidate for retirement. Legacy DELETE /rest/workflow/activity/deleteActivity soft-deleted an activity (and reflected the change in associated cost records, creating a new job version if versioning is on). The new API has no activity-delete endpoint - activity removal is handled implicitly via the job-version create flow (POST /v1/jobs/{jobId}/version).
deleteActivityByClientRef	No replacement	—	Legacy supported deleting an activity (or all activities, with activityRef=-1) on a job looked up by client ref. No equivalent in the new API - activity deletion is not exposed and jobs are addressed by internal id.
getJobsByEvent	No replacement	—	Legacy returned jobs filtered by job-event IDs that fired in a given date range. The new GET /v1/jobs only filters by jobRefs/clientRef/searchTerm - it has no concept of "jobs that experienced event X between dates Y and Z". For event-driven integrations use the OneCore webhook event subscriptions (/v1/events/*) instead.
jobEventsXml	No replacement	—	Legacy job-event recording. The new /v1/events endpoints are OneCore webhook subscriptions, a different concept despite the name. There is no direct equivalent for this endpoint; to record an event against a job use POST /v1/jobs/{id}/events, and for event feeds use webhook subscriptions instead of polling. Contact Oneserve support to discuss your use case.
jobEventsXmlV1	No replacement	—	Legacy job-event recording. The new /v1/events endpoints are OneCore webhook subscriptions, a different concept despite the name. There is no direct equivalent for this endpoint; to record an event against a job use POST /v1/jobs/{id}/events, and for event feeds use webhook subscriptions instead of polling. Contact Oneserve support to discuss your use case.
jobEventsXmlV2	No replacement	—	Legacy job-event recording. The new /v1/events endpoints are OneCore webhook subscriptions, a different concept despite the name. There is no direct equivalent for this endpoint; to record an event against a job use POST /v1/jobs/{id}/events, and for event feeds use webhook subscriptions instead of polling. Contact Oneserve support to discuss your use case.
jobStateChange	No replacement	—	Legacy job-event recording. The new /v1/events endpoints are OneCore webhook subscriptions, a different concept despite the name. There is no direct equivalent for this endpoint; to record an event against a job use POST /v1/jobs/{id}/events, and for event feeds use webhook subscriptions instead of polling. Contact Oneserve support to discuss your use case.
jobVersion	No replacement	—	No usage observed (April to June 2026); candidate for retirement. Legacy GET /rest/workflow/job/version/{startDate}/{endDate}/{versionAction}/{clientId}/{supplierIdList} returned jobs that had a new version submitted or approved within a date range, optionally filtered by supplier. The new API has no equivalent cross-job version-activity feed - it only exposes GET /v1/jobs/{jobId}/versions/required-approvals for a single job, and the broader change feed should come from OneCore webhook event subscriptions.
updateActivity	No replacement	—	Legacy POST /rest/workflow/activity/updateActivity/{activityId} updated quantities, notes, site-location and category on an activity (creating a new job version if versioning is on). The new API has no per-activity update endpoint. Make activity changes via the job-version flow (POST /v1/jobs/{jobId}/version) which accepts the full activity set.
updateJobClientRef	No replacement	—	Legacy POST /rest/workflow/job/updateJobClientRef updated a job's external client reference (with an appendClientRef toggle to replace or append). The new API has no targeted endpoint to change a job's clientRef; it is not part of the POST /v1/jobs/{jobId}/version payload either. Flag for product/back-end input if migrators still need this.