Platform Release Notes 26.30

API Enhancements

API Endpoint to Retrieve Overtime Hour Totals

What is changing:
A new Enterprise API endpoint is now available that allows you to retrieve overtime hour totals for employees programmatically. The endpoint functions similarly to the Daily OT Entry page in the ARCOS platform, but returns only the aggregated totals — making it ideal for pulling OT data into your internal systems for equitable job assignment, reporting, and workforce planning.

This endpoint enables your IT and integration teams to automate the retrieval of overtime data that was previously only accessible through the ARCOS web application.

Endpoint: POST /arcos/rest/listmnt/ottotals

How it works:
•Submit a POST request to the endpoint with the search parameters
•The response includes, for each matched employee:

• Contact ID, VRU ID, and Web ID
• Total hours for each requested paycode (name and ID)
• A grand total summing only the paycodes included in the request

If no paycodes are specified, the response returns totals for all available paycodes.
•You can mix different ID types across requests, but all IDs in a single request must be the same searchType.
•Duplicate IDs in a request are automatically deduplicated.
•Totals are calculated based on the Start of Year Admin configuration for each employee's location, consistent with the Daily OT Entry page.
• Unrecognized IDs and inactive employees are clearly indicated in the response with descriptive error messages, while valid employees are still returned successfully.

Who is involved:
•IT / Integration Teams — The primary audience. They will use this endpoint to build integrations that pull OT totals into internal systems.
•System Administrators — Should be aware of the new endpoint.
•Operations / Workforce Management — Stakeholders who will benefit from the automated OT data in downstream reporting and equitable assignment systems.

What you need to do:
•Enterprise API access is required. This endpoint is available through the existing ARCOS Enterprise API. If your organization already has Enterprise API access configured, no additional setup is needed to begin using this endpoint.
•Review the API documentation. Your integration team should review the endpoint specification (request parameters, response format, and error handling) provided alongside this release to build or update your integrations.
•Verify paycode IDs. If you plan to filter by specific paycodes, confirm the correct paycode IDs in your ARCOS environment before building your requests. An invalid paycode ID will return an error.
•Test in your QA environment before deploying to production to validate the response format and data accuracy against your existing Daily OT Entry page results.

Detailed API Documentation for POST /listmnt/ottotals

POST /arcos/rest/listmnt/ottotals

Request body expects the following fields:
•searchIds – [Required] - list of ids (contact ids, web ids, or vru ids) to get OT data for
•searchType – [Required] - what type of id lookup should be user: contactId, webId, or vruId
•paycodes – [Optional] - list of paycode ids (preference ids)
•Only these values will returned and the grand total will be based on those codes as well
•asOfDate – [Required] - A string date of format MM/dd/yyyy that will denote the totals on that date

The searchIds and searchType fields follow the employee search format where all values in searchIds are expected to be of the same searchType. Any duplicate values in the searchIds input will be removed and data only returned once per unique ID.

Example POST Calls

All fields are used
Lookup the 1027 Paycode (HRS Worked) for Contact ID 18996 for 06/25/2026
{
"searchIds": [
18996
],
"searchType":"contactId",
"paycodes": [
1027
],
"asOfDate": "06/25/2026"
}

Request Body - No Paycodes
If no paycodes field is present or the field is empty, then all paycodes will be returned.
The request bodies below will result in the same response
{
"searchIds": [
18996
],
"searchType":"contactId",
"asOfDate": "06/25/2026"
}
------------------------------------------------------------------------------------
{
"searchIds": [
18996
],
"searchType":"contactId",
"paycodes": [],
"asOfDate": "06/25/2026"
}

Request Body - Search Types
Examples of using searchType for contactid, webid and vruid
The below examples are different ids for the same user and will result in the same response returned.

{
"searchIds": [
18996
],
"searchType":"contactId",
"paycodes": [
1027
],
"asOfDate": "06/25/2026"
}
------------------------------------------------------------------------------------
{
"searchIds": [
"ktiao_ai"
],
"searchType":"webId",
"paycodes": [
1027
],
"asOfDate": "06/25/2026"
}
------------------------------------------------------------------------------------
{
"searchIds": [
9739700674
],
"searchType":"vruId",
"paycodes": [
1027
],
"asOfDate": "06/25/2026"
}

Response
An array of contacts with their contact id, web id, vru id, grand total of all OT hours based on the paycodes passed in, and a list of totals for each paycode. Each paycode total have the id, name, and the total.
Below is an example of a single employee OT Total lookup
[
{
"contactId": 18996,
"vruId": "9739700674",
"webId": "ktiao_ai",
"grandTotal": 30.0,
"paycodeTotals": [
{
"paycodeId": 1027,
"paycodeName": "HRS Worked",
"totalHours": 24.0
},
{
"paycodeId": 1174,
"paycodeName": "210",
"totalHours": 4.0
},
{
"paycodeId": 1176,
"paycodeName": "211",
"totalHours": 1.0
},
{
"paycodeId": 1069,
"paycodeName": "ST",
"totalHours": 1.0
},
{
"paycodeId": 1070,
"paycodeName": "1.5T",
"totalHours": 0.0

LLC – CONFIDENTIAL AND PROPRIETARY Page 8
© 2000–2026 ARCOS LLC. The trademarks ARCOS, the ARCOS LOGO, SAMsix and the SAMsix logo, and RosterApps, and other names and symbols
used in this document are owned by ARCOS LLC, its subsidiaries, or its third-party business partners. All rights reserved.
},
{
"paycodeId": 1031,
"paycodeName": "HRS Refused",
"totalHours": 0.0
},
{
"paycodeId": 1004,
"paycodeName": "027",
"totalHours": 0.0
},
{
"paycodeId": 1492,
"paycodeName":
"SOTM Callout",
"totalHours": 0.0
},
{
"paycodeId": 1050,
"paycodeName": "781",
"totalHours": 0.0
}
]
}
]

Errors
The errors below are returned with a 400: 

Response Employee Errors
If there is a single valid ID and matching active employee, the response will be a 200 and all invalid employees will have a default element with an error message.

Similarly, another error is shown when a requested employee is not in active status.

No Matching Employee
In the response below, a request was sent with vruId's: ktiao_ai and 9739700674, of which the former is not a VRU ID and thus returns an error in the employee’s section. The latter ID which has a matching employee, was returned properly with the needed data.

It shows no other data and results in an error field appearing with a brief description for why no other data is shown: No matching employee for vruId: <id>. That message will change based on the searchType passed in.
[
{
"contactId": 0,
"grandTotal": 0.0,
"paycodeTotals": [],
"error": "No matching employee for vruId: ktiao_ai"
},
{
"contactId": 18996,
"vruId": "9739700674",
"webId": "ktiao_ai",

"grandTotal": 24.0,
"paycodeTotals": [
{
"paycodeId": 1027,
"paycodeName": "HRS Worked",
"totalHours": 24.0
}
]
}
]

Non-Active Employee
If an ID matches an employee that is no longer in an active status, no OT data will be shown. Only their IDs (contactId, webId, and vruId) and the error Employee not active. Employee skipped. is displayed. The Overtime data and paycodes breakdown will be set to 0/empty list.
[
{
"contactId": 18996,
"vruId": "9739700674",
"webId": "ktiao_ai",
"grandTotal": 80.0,
"paycodeTotals": [
{
"paycodeId": 1027,
"paycodeName": "HRS Worked",
"totalHours": 80.0
}
]
},
{
"contactId": 55961,
"vruId": "973970077",
"webId": "973970077",
"grandTotal": 0.0,
"paycodeTotals": [],
"error": "Employee not active. Employee skipped"
}]

Mobile Plus Enhancements

My Callout History – View other accepted employees on the callout

What is changing:
The ARCOS Mobile App now includes a new "Other Accepts" section on the My Callout History detail page. When viewing the details of a callout you accepted, you can now see a list of all other employees who also accepted the same callout.

Previously, once you accepted a callout — especially one spanning multiple lists — there was no way to see who else was called in and accepted without contacting dispatch. Field crews can now immediately see who they'll be working with when responding to a callout, improving coordination, reducing the need to call dispatch, and helping employees plan for reporting to work.

How it works:
•Navigate to My Callout History in the mobile app and tap into a callout to view its details.
•Below the existing Callout Details and Accept Details sections, a new "Other Accepts" section displays the names of all employees who accepted the callout.
•This includes accepts from the same sub-callout, different sequences, different sub-callouts, and other locations — matching what is shown on the web Filled page.
•Employee names are displayed in the format: LastName, FirstName Mi. (Nickname).
•If an employee's response was changed to a result other than "accepted," they will not appear in the list.

This feature was a direct result of customer feedback submitted through the IdeaBank.

Who is involved:
•System Administrators / Security Admins — They will need to grant the new security permission to the appropriate security groups beyond Admin.
•Dispatchers & Operations Managers — Awareness that field employees can now self-serve this information, which may reduce inbound calls to dispatch.
•Mobile App End Users (Field Employees) — Anyone who uses the mobile app to view their callout history will benefit from this new feature.

What you need to do:
This feature is controlled by a new security permission called "My Callout History - View Accepts". Here's what to know:
•Auto-enabled for the Admin security group: The new security permission has been automatically enabled for the Admin security group on all customer schemas that already have the mobile app enabled.
•Enable for other security groups: To allow non-Admin users (e.g., field employees, supervisors) to see the Other Accepts section, a System Administrator must manually enable the "My Callout History - View Accepts" permission option for the desired security groups.
•Important: Users must have both the existing "My Callout History" permission and the new "My Callout History - View Accepts" permission to see the Other Accepts section. Having only one of the two will not grant access.
•No additional setup or configuration is required beyond enabling the security option for the appropriate groups.