Setting Start and End Dates in Appointments via API

Question

Goal: Create an appointment via the API.

The stock API version 26 seem to allow setting of the appointment start date via the field ActualStartDate. However the End Date and Time can only be set via fields having the _Date and _Time suffixes. The Web Services management UI shows an error that the fields shouldn’t be hooked up this way, even on the default endpoint.

Using the default endpoint, I’ve tried setting the date and time in various ways, but it’s not clear what format it accepts, and I’m getting inconsistent results. Timezone errors seem common.

I cannot seem to create a custom endpoint. The UI does not appear to allow access to the end date fields, they aren’t in any of the mapped objects (what are those things anyway?), even though they are present in the DAC browser.

Currently I can set an Actual Start Date and Duration via the default endpoint. I would have expected this to populate the End Date but it does not. I cannot set the scheduled dates reliably, sometimes it works for me on my computer, but not for the client’s live installation.

Does anybody have any idea how this is supposed to be done? Thanks if you can!

Dmitrii Naumov · Accepted Answer

The default endpoint there is not ideal. We’ll try to improve it in 27R1 version.

That said, the following requests should work:

PUT {{sitename}}/entity/Default/26.200.001/Appointment
{
    "id": "b090b182-6639-ea11-8173-dab1842b9396",
    "ActualHandleManually": {
        "value": true
    }
}

PUT {{sitename}}/entity/Default/26.200.001/Appointment
{
    "id": "b090b182-6639-ea11-8173-dab1842b9396",
   "ActualStartDate": {
        "value": "2026-11-10T00:00:00+00:00"
    },
    "ActualStartTime": {
        "value": "1900-01-01T17:38:00+00:00"
    }, 
    "ActualEndDate": {
         "value": "2026-11-11T00:00:00+00:00"
    },
    "ActualEndTime": {
         "value": "1900-01-01T17:48:00+00:00"
    }
}

joegrist · Answer

Thank you - this helps. Looks like in several places in the system, using the “1900-01-01...” for the time, and‘[UTC Date]T0:00...” works more reliably than what I was doing. This might have solved the issue :)

Sign up

Social Login

Login to the community

Social Login