Working hours your workflows actually respect.
Finomium's business calendar - office hours and holidays - is the same engine that already drives Workflow's SLA timers, now a first-class product of its own.
curl -X POST https://api.finomium.co/api/v1/business-calendar/holidays \
-H "Authorization: Bearer $TOKEN" \
-d '{"date": "2026-12-25", "label": "Company holiday"}'
# {"date":"2026-12-25","label":"Company holiday"}Office hours
Define your team's real working hours per weekday - the same rule every SLA/breach calculation and business calendar decision reads from.
Holiday management
Add or remove specific dates as holidays - a workflow due today on a holiday rolls to the next working day automatically, not silently late.
One calendar, every consumer
The same office-hours/holiday configuration backs Workflow's SLA timers and Rule Engine's time-aware decisions - set it once.
Workflow SLA integration
Task due dates and case milestone deadlines are computed against this calendar, not a raw 24/7 clock - a Friday-evening task due "in 2 business days" lands Tuesday, correctly.
Live updates, no redeploy
Change office hours or add a holiday and every in-flight SLA calculation picks it up immediately - calendars are data, not configuration baked into a process definition.
Per-tenant calendars
Every tenant gets its own office-hours and holiday configuration - a shared platform, never a shared calendar.
Same auth, same API keys
Calendar management runs behind the exact bearer-token/API-key auth every other product here already uses - nothing new to wire up.
A real, documented API
GET/PUT office hours, GET/POST/DELETE holidays - a small, deliberately simple surface, not a hidden internal-only mechanism.
Not a second calendar to keep in sync
Office hours and holidays configured here are the exact same records Workflow reads for SLA/breach timing and Rule Engine can read for time-aware decisions - one calendar per tenant, consumed everywhere, never duplicated.