Hubhus
CRMConnect AI agents to Hubhus, a Danish sales and field service platform that runs lead to order. Agents capture and update leads into the right campaign, book and reschedule calendar work, manage users, and read fleet tracking, time, and consent records.
What This Integration Enables
Hubhus is a Danish sales and field service platform that takes a service business from lead to order, and the part of it that is genuinely hard to replicate is the booking engine. Most calendars answer the question "when is there a gap". Hubhus answers "which gap costs least to reach", ranking available appointments by travel time and CO2 cost across a real fleet, which is a different and much better question for a business whose margin is decided by how far the van drove. Around that sit the lead pipeline, the calendar resources and teams behind it, GPS fleet tracking, time tracking, a product catalog, and consent records. An agent working here is not tidying a CRM. It is deciding where somebody drives tomorrow, and what a company can later prove about a person's permission.
Leads live inside campaigns, and each campaign defines its own field schema, so field values are addressed by field slug or by dynamic type keys such as %name%, %email%, %phone%, and %full-address% that resolve to the first campaign field of that type. That is what lets one flow feed several campaigns without hardcoding slugs, and Get Campaign is how a flow reads the real slugs, select options, and statuses at runtime rather than baking them in. Booking is deliberately a three step flow: List Available Booking Dates covers a single month at a time, List Available Booking Time Slots returns the slots on one chosen date, and Check Calendar Resource Availability re-checks a single resource for the exact window, which is the guard against a slot being taken between the search and the booking. Hubhus provides no triggers to FlowRunner. The product does have outbound webhooks configured as action listeners, but it exposes no webhook subscription API and publishes no delivery payload shape, so no trigger could be built against it honestly. Change detection is the Updated After parameter, with List Leads and List Calendar Events as the natural polling targets, and updated_at on a lead reflecting changes to field values, status, assignee, comments, checklist submissions, anonymization, followup, and NPS score. Several behaviours will bite a flow that assumes otherwise, and they are worth designing around rather than discovering: when a timestamp carries no timezone the API assumes Europe/Copenhagen rather than UTC; relation lists on Update Lead, Update Calendar Event, and Update User are full replacements, so an empty array decouples every existing relation and omitting the parameter is how you leave them alone; deleted records are hidden from normal reads entirely unless you filter on deleted_at; and LIKE filter values must be uppercase with IN lists separated by semicolons rather than commas, because commas split a filter into independent expressions. Products and Time tracking are marked by the vendor as work in progress and are read only today.
Without FlowRunner
With FlowRunner
Use Case Scenarios
A booking that picks the cheapest van, not the first gap
A customer requests a service visit. The agent calls Get Booking Form to load the form's requirements, then List Available Booking Dates for the month containing the requested start, remembering that the search covers one month only so a quarter means three calls. With a date chosen it calls List Optimal Booking Slots against the customer's full address, which ranks the options by travel time and CO2 rather than by which technician happens to be free first. Immediately before writing, Check Calendar Resource Availability re-checks that single resource for the exact window, closing the gap in which another booking could have taken it. Create Calendar Event then books it, and the customer gets a confirmation with the arrival window through Gmail. An address the geocoder cannot resolve returns a validation error rather than a booking, so the flow routes those to a person instead of guessing a location.
A warehouse that stays current without re-reading the whole table
A reporting warehouse needs Hubhus data without a nightly full extract. On a schedule the agent calls List Leads with Updated After set to the last successful run, passing an explicit timezone offset because a naive timestamp would be read as Europe/Copenhagen and silently shift the window by an hour or two. It pages the Laravel paginator envelope, reading meta.last_page and stopping when links.next is null, and respects the tighter maximum of one hundred per page that applies to List Leads and List Calendar Events specifically. Get Campaign supplies the field slugs and status labels so the extracted rows are readable rather than a wall of slugs. The same pattern runs against List Calendar Events, and the results land in Google Sheets for the operations review. Bulk pulls are paced deliberately, because the rate limit headers Hubhus returns are not readable from inside a flow.
Field work reconciled against what was actually booked
At the end of each day the agent pulls List Time Tracking Entries and List GPS Stops for the date, and List Calendar Events for the same window. Each booked appointment is matched to a GPS stop near the customer address and to a time entry from the technician, filtering GPS records on started_at rather than created_at, because created_at is when the record was imported from the tracker and not when the vehicle actually stopped. Appointments with no corresponding stop, stops far from any booking, and time entries whose duration is well outside the service definition from Get Calendar Service are collected into a daily job verification report. Nothing is corrected automatically. The report goes to the operations manager, because the interesting cases are almost always a customer who was not home or a job that turned out bigger than the booking said, and both of those are conversations rather than data fixes.
Human-in-Loop Highlight
Store Consent is the write on this connector where the agent is not recording an operational fact but making an assertion about a person to a regulator. The action records that a named individual agreed to something at a specific time, and the vendor is explicit that you should pass the real time of agreement rather than the time the flow happens to run. That distinction is the whole compliance value of the record, and it is exactly what an automated pipeline degrades: a lead is imported from an advertising platform at 02:00, the source system's own consent timestamp is missing or ambiguous, and the path of least resistance is to write now. Two things then compound it. When no timezone is given the API assumes Europe/Copenhagen, so a naive timestamp carried from an upstream system in UTC lands one or two hours away from the moment it describes. And multiple identifiers can be registered in a single call by separating them with a pipe character, so one malformed field turns a single record into consent asserted for several identifiers at once. The result is a compliance record that looks authoritative, is used by Check Consent to authorise every future marketing send, and quietly does not describe what happened. So the agent gathers and stops. It posts to the compliance owner: "412 leads imported from the landing page batch. 361 carry a consent timestamp from the source with an explicit UTC offset and a declaration id matching Marketing samtykke. 34 carry a timestamp with no timezone, which the API will read as Europe/Copenhagen and shift by two hours. 17 carry no timestamp at all, only a ticked box in the export. Store the 361 now, and tell me how to handle the 34 and the 17." The owner answers. Store Consent then runs on the confirmed set with explicit offsets, and Check Consent gates every outbound step afterwards, so no connectors downstream send to a person whose permission the business cannot actually evidence. The agent is fast at the 361. It is deliberately useless at the 17, which is the correct behaviour when the alternative is inventing a fact about a human being's consent.
Agent Capabilities
48 actionsLeads
5- List Leads Returns leads with the vendor bracket filter syntax and an `Updated After` parameter for incremental pulls. Maximum page size is one hundred here rather than the usual five hundred. This is the primary polling target, since Hubhus exposes no trigger.
- Get Lead Retrieves a single lead with its campaign field values. Used to load full context before an update or an outbound step.
- Create Lead Creates a lead in a campaign, addressing field values by slug or by dynamic type keys such as `%name%`, `%email%`, `%phone%`, and `%full-address%`, with UTM attribution and consent captured in the same call.
- Update Lead Updates a lead. Supplying `Parent Lead IDs`, `Child Lead IDs`, or `Calendar Event IDs` replaces those relations entirely and an empty array decouples all of them, so omit the parameter to leave relations untouched.
- Delete Lead Deletes a lead. Deleted records are recoverable through the Hubhus interface but are hidden from normal API reads unless a `deleted_at` expression filter is used, which makes an accidental delete effectively invisible to a flow.
Campaigns
2- Get Campaign Returns a campaign including its `fields`, `select_fields.options`, and `statuses`. This is the runtime read that lets a flow use real slugs instead of hardcoding account specific values.
- List Campaigns Returns the campaigns on the account. Used to route an inbound lead to the right campaign before it is created.
Contacts
2- Get Contact Retrieves a single contact. Used to load the person behind a lead or a booking.
- List Contacts Returns contacts with filtering and paging. Used for reporting and for reconciling against an external CRM.
Calendar Events
5- List Calendar Events Returns calendar events with filtering, `Updated After`, and a maximum page size of one hundred. Used as the polling target for schedule changes and for daily job verification.
- Get Calendar Event Retrieves a single event. Used to confirm the booked window and assigned resource before acting on it.
- Create Calendar Event Books an appointment. Setting `All Day` forces the start time to 00:00 and the end to 23:59:59 regardless of the times supplied, and setting `Private` makes calendar services, lead IDs, and leads invalid in the same request.
- Update Calendar Event Updates an event. `Lead IDs` is a full replacement, so an empty array decouples every lead from the appointment. Content Visibility writes as `default`, `all`, `attendants`, or `none` but reads back as a human readable label, so a response value must not be sent straight back into an update.
- Delete Calendar Event Deletes a calendar event. Recoverable in the interface but hidden from ordinary API reads afterwards.
Booking
6- Check Calendar Resource Availability Re-checks a single resource for an exact window. This is the guard that closes the gap between searching for a slot and booking it, and it runs immediately before Create Calendar Event.
- Get Booking Form Retrieves a booking form and its requirements. `Full Address` is required for any form with location enabled.
- List Available Booking Dates Returns available dates within the single month containing the supplied From Date. Earliest Date and Latest Date narrow within that month rather than extending past it, so covering a quarter takes three calls.
- List Available Booking Time Slots Returns the available slots on one chosen date. The second step of the three step booking flow.
- List Booking Forms Returns the booking forms configured on the account. Used to select the right service journey for an enquiry.
- List Optimal Booking Slots Returns appointment slots ranked by route optimization, so the chosen slot is the one with the lowest travel time and CO2 cost rather than the first free gap in the calendar.
Calendar Setup
8- Get Calendar Resource Retrieves a single calendar resource. Used to confirm which technician or asset a booking will consume.
- Get Calendar Resource Group Retrieves a resource group. Used to understand how resources are pooled before booking against them.
- Get Calendar Resource Team Retrieves a resource team. Used to route work to the team that covers an area or a service.
- Get Calendar Service Retrieves a calendar service with its definition. Used to check that a logged job duration is inside what the service actually describes.
- List Calendar Resource Groups Returns the resource groups on the account.
- List Calendar Resource Teams Returns the resource teams on the account.
- List Calendar Resources Returns the bookable resources on the account. Used to resolve a resource before checking its availability.
- List Calendar Services Returns the services that can be booked. Used to attach the right service to an appointment.
Users
4- Create User Adds a regular user to the workspace. This provisions a real account and may consume a seat under the plan, and there is no delete endpoint for users.
- Get User Retrieves a single user. Used to resolve an assignee or a technician.
- List Users Returns the users on the account. Used for joiner and leaver reconciliation against an HR source.
- Update User Updates a user, and doubles as the deactivate and reactivate control through its `Deactivated` parameter, since users cannot be deleted. `User Tag IDs` is a full replacement, so an empty array clears every tag.
Consents
4- Check Consent Checks whether consent exists for a person and a declaration. Used as the gate before any outbound marketing step, so a send only happens inside recorded permission.
- Get Consent Declaration Retrieves a single consent declaration. Used to confirm which permission a record is about to assert.
- List Consent Declarations Returns the consent declarations configured on the account. Used to resolve the right declaration before storing anything.
- Store Consent Records that a person agreed at a specific time, with multiple identifiers registerable in one call separated by a pipe character. Because this is a compliance record rather than an operational one, the source and the exact time of agreement are confirmed by a person before it is written.
Fleet Tracking
6- Get GPS Stop Retrieves a single GPS stop. Note that `created_at` is the import time from the tracker, not the time the vehicle stopped, so filter on `started_at` when you mean when it happened.
- Get GPS Trip Retrieves a single GPS trip, with the same import time caveat.
- Get Vehicle Retrieves a single vehicle. Used to attach a real vehicle to a reconciliation report.
- List GPS Stops Returns GPS stops with filtering. Used to verify that a technician actually arrived at a booked appointment.
- List GPS Trips Returns GPS trips with filtering. Used to measure real travel against the route optimization the booking assumed.
- List Vehicles Returns the vehicles tracked on the account.
Microsoft Calendar
2- Get Microsoft Event Retrieves a single Microsoft calendar event. Read only, and returns data only when the Microsoft Calendars integration is enabled on the account.
- List Microsoft Events Returns Microsoft calendar events, which are read only and separate from native Hubhus calendar events. Used to see external commitments that constrain availability.
Products
2- Get Product Retrieves a single product. The vendor marks Products as work in progress and read only today, so treat the response shape as provisional.
- List Products Returns the product catalog. Read only, and subject to change without notice per the vendor.
Time Tracking
2- List Time Tracking Entries Returns logged time entries. Read only, and used to reconcile actual job duration against booked appointments.
- List Time Tracking Tags Returns the time tracking tags on the account. Read only, used to categorise logged work in a reconciliation report.
Frequently Asked Questions
What can FlowRunner do with Hubhus?
FlowRunner agents can run List Leads, Get Lead, and Create Lead in Hubhus, plus 45 more actions.
Does connecting Hubhus to FlowRunner require OAuth?
No. Hubhus connects to FlowRunner with an API key, no OAuth flow required.
Can Hubhus trigger a FlowRunner workflow automatically?
Hubhus doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Hubhus
$100 in credits. No card required. Connect in minutes.