Page 1 of 1

Schedule missing from list endpoint, but available by ID

Posted: Wed Jul 29, 2026 4:27 am
by gavinhodge
Hi there,

We have a situation on a customer account where a record (ID=1589347) has dropped off the Schedule list endpoint, but is available when we query it by ID.

Example List:
GET https://{customer}.simprocloud.com/api/v1.0/companies/47/schedules/?orderby=DateModified&pageSize=100&page=1&columns=ID%2CDateModified

Result: 200 OK. Schedule ID 1589347 is not listed on any pages


Example Detail:
GET https://{customer}.simprocloud.com/api/v1.0/companies/47/schedules/1589347

Result: 200 OK. Schedule information is shown.

Is this expected? Customer is reporting that the schedule isn't deleted (which I can't confirm by hand). Is there some status which would cause the record to be skipped by the list endpoint? Is it actually deleted but the detail endpoint isn't filtering correctly?

Gavin.

Re: Schedule missing from list endpoint, but available by ID

Posted: Wed Aug 05, 2026 11:07 pm
by gavinhodge
Hi Simpro team, it has been more than a week.

What needs to happen next? More information required? Escalation from customer to their account manager?

Gavin.

Re: Schedule missing from list endpoint, but available by ID

Posted: Thu Aug 06, 2026 11:05 pm
by SimproAPITeam
Hi Gavin,

Apologies for the delay in getting back to you on this.

We've looked into the discrepancy you reported with Schedule ID 1589347. The most likely explanation is that this schedule spans midnight (i.e. it runs from one day into the next). When a schedule crosses midnight, simPRO records it as two linked entries — the hours from the second portion are rolled up into the original schedule for reporting purposes, so that second entry is intentionally excluded from list views to avoid double-counting. It's still a valid, active record though, which is why it returns correctly when queried directly by ID.

Could you confirm whether schedule 1589347 is the "second half" of a shift that crosses midnight? If so, this is expected behaviour rather than a fault, and no action is needed.

If it turns out that isn't the case, please raise it via our helpdesk so it can be investigated further:

https://helpdesk.simprogroup.com/

Thanks again for your patience, and sorry for the wait on this one.

Regards