Event types and availability

Modified on Tue, 25 Aug at 2:49 PM

Event types and availability

Event types define what services can be booked (duration, color, resources, custom fields). Availability settings control when those services are bookable - through default hours, public holidays, locations, and special dates. Event color is normally set on the event type; it can also be changed dynamically via HTTP requests when you need conditions that event type alone cannot cover.

TL;DR

Event types: Calendar → Settings → Event types - name, duration, color, resources, custom fields. Booking forms use Created event type so new bookings pick up that type’s color. Dynamic color: after an event exists, an automation/HTTP request can update it (e.g. PATCH the calendar event’s color). Availability hierarchy (highest to lowest): Special dates → Resource hours → Default hours - public holidays block all. More calendar/API options: see the Hubhus API docs.

3 things to configure

1

Event types (incl. color)

Go to Calendar → Settings → Event types → + New type (or edit an existing type). Set name (e.g. "Telephone consultation"), default duration, Color, and default title/location/description. Use Use defaults proactively: Yes to auto-populate these in booking forms. Assign resources and add custom fields as needed. Link to campaigns that may book this type. On each booking form, set Created event type so new events get that type’s color.

2

Default hours and public holidays

Go to Calendar → Settings → Available hours. Default hours are the system-wide fallback (e.g. Mon-Thu 09:00-17:00, Fri 09:00-16:00). Add blocks with the + button. Under Public holidays and closure dates, click Add public holidays to import standard holidays for your country (do this each year). Add custom company closure dates with Add closure date. Public holidays override all other availability - no bookings are possible on those days.

3

Special dates and locations

Special dates (Calendar → Settings → Special dates) override regular hours for specific periods - e.g. adjusted hours, different base address, or closure for a specific resource. Create one per exception, set the date range, select affected resources, and configure the changed settings (Is closed, custom hours, alternative address).
Locations (Calendar → Settings → Locations) configure service areas per resource: base address (start/end of day) and operable postal codes. An interactive map shows coverage visually.

Color default: Event type → Created event type on booking form  ·  Color dynamic: HTTP / automation after create  ·  API: leadvalidator.dk/docs
Read more

Event colors: fixed vs dynamic

Fixed (most common): Set Color on the event type. Ensure the booking form’s Created event type points to that type. All events created that way show in that color. Use separate event types when different services or “special demand” flows need different colors.

Dynamic (when type alone is not enough): After the event exists, update its color with an HTTP request from an automation, action listener, or action button - for example when a field/checkbox marks special demands. Typical pattern: PATCH the calendar event and send a JSON body with a color value (hex). Authenticate with your Hubhus API token as documented.

Example shape (illustrative): method PATCH, URL to the calendar-events endpoint for the event id, header Content-Type: application/json + Authorization, body like { "color": "#de5d83" }. Exact paths and fields: check the live API docs - do not invent endpoints.

HTTP requests for more options

Many calendar and lead behaviours beyond the standard UI can be automated with HTTP requests (create/update events, set fields, integrations). What is possible depends on the API. Always read the current documentation: https://leadvalidator.dk/docs/. Build templates under Campaign settings → HTTP & webhooks - see HTTP requests: Creating custom templates.

Availability hierarchy

When calculating available time slots, Hubhus applies settings in this order (highest priority first):

  1. Special dates - date-specific overrides for individual resources
  2. Resource available hours - individual resource working schedule
  3. Default available hours - system-wide fallback
  4. Public holidays - override everything, block all availability

Example: Resource hours 10:00-16:00, default hours 09:00-17:00, no special date → available 10:00-16:00. Same day + special date 08:00-12:00 → available 08:00-12:00 (special date wins).

Troubleshooting: no available times showing

  • Check default available hours are configured
  • Verify the resource has available hours set
  • Check for blocking special dates (Is closed = Yes)
  • Confirm date is not a public holiday
  • Review operable postal codes - customer address may be outside the service area

Common searches

event types • event color • change calendar color • Created event type • PATCH calendar event • HTTP request calendar • availability • working hours • public holidays • special dates

Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article