Calendar Entries

Simple date/time entries that appear in the employee calendar. Automatically published and added to the calendar on creation. The body is optional; entries can be global (no groups) or targeted. Entries can be categorized with an event type via calendar_event_type_id — when omitted, the default event type is used.

Required scope: read:calendar_entries, write:calendar_entries.

Endpoints

GET

/api/open/v1/calendar-entries

List calendar entries (published by default, paginated)

GET

/api/open/v1/calendar-entries/{id}

Get a single calendar entry

POST

/api/open/v1/calendar-entries

Create a calendar entry

PATCH

/api/open/v1/calendar-entries/{id}

Update a calendar entry (partial update)

DELETE

/api/open/v1/calendar-entries/{id}

Delete a calendar entry (returns 204)

Filtering by status

By default, the list returns only published entries. Use the status query parameter to retrieve drafts:

`status`	Returns
`published` (default)	Currently-live content only (published, with a publish time in the past).
`draft`	Unpublished content only — drafts, plus items awaiting a scheduled publish.
`all`	Every item, regardless of state.

curl "https://customer.monotree.com/api/open/v1/calendar-entries?status=draft" \
  -H "Authorization: Bearer mono_your_token_here"

An unrecognised value returns 422. Fetching a single entry by id (GET /calendar-entries/{id}) always works regardless of state.

Create

curl -X POST https://customer.monotree.com/api/open/v1/calendar-entries \
  -H "Authorization: Bearer mono_your_token_here" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Company Holiday",
    "starts_at": "2026-06-01",
    "starts_time": "09:00",
    "ends_at": "2026-06-01",
    "ends_time": "17:00",
    "body": "Optional description",
    "groups": [1, 3],
    "calendar_event_type_id": 2
  }'

Instead of body, pass article_id to attach a pre-built standalone article (see Articles) — the two are mutually exclusive.

Published by default — pass is_published: false to create a draft, then publish later via the update endpoint.

calendar_event_type_id must reference an event type from GET /calendar-event-types (422 otherwise). Omit it to use the default event type.

Update

PATCH accepts the same fields as create — all optional; only the fields you send are changed. PUT is accepted as an alias for backwards compatibility and behaves identically.

curl -X PATCH https://customer.monotree.com/api/open/v1/calendar-entries/101 \
  -H "Authorization: Bearer mono_your_token_here" \
  -H "Content-Type: application/json" \
  -d '{ "starts_time": "10:00", "calendar_event_type_id": 2 }'

Response

{
  "data": {
    "id": 101,
    "article_id": 93,
    "title": "Company Holiday",
    "body": null,
    "starts_at": "2026-06-01",
    "starts_time": "09:00",
    "ends_at": "2026-06-01",
    "ends_time": "17:00",
    "calendar_event_type": { "id": 2, "name": "Kunde information", "translations": { "da": "Kunde information", "en": "Customer information" } },
    "author": { "id": 1, "name": "John Doe", "email": "john@example.com", "avatar_url": "https://images.monotree.com/avatars/john-doe.jpg" },
    "groups": [],
    "created_at": "2026-06-01T10:00:00+00:00",
    "updated_at": "2026-06-01T10:00:00+00:00"
  }
}

article_id links the entry's rich content — manage it through the articles endpoints.