HUB_ / TECHNICAL BRIEFING FOR ONRENT EVENTS

Hub: architecture
& data flow.

How Hub extends OnRent Events (formerly Current RMS): browser runtime, API interaction, and data storage and retrieval.

Technical briefing · October 2026Desktop integrationTransport · Settings Hub · Bay Hub

01 / CONTEXT

Purpose and scope.

Hub is a modular Chrome extension for OnRent Events, developed from operational use in event production and equipment hire.

Its modules add views, checks and grouped actions around existing workflows, including shortages, supplier coordination, warehouse processing and transport. They combine platform records with additional module state where needed. An Opportunity is the job record used in the examples below.

02 / BROWSER RUNTIME

How the interface is injected.

Hub uses Chrome Manifest V3. URL patterns in the manifest determine which content scripts load. Module checks then apply user and organisation settings, page context and, where relevant, licence status before showing controls.

Initialise

Scripts load at document_start or document_idle and derive context, such as an Opportunity ID, from the URL or page.

Insert controls

Scripts add DOM elements, styles and event handlers. Most run in the extension's isolated context; selected guards run in the page's main context.

Handle page updates

Relevant modules use DOM observers or lifecycle events when content is replaced. Initialisation guards help prevent duplicate instances.

The interface runs in Chrome. Data persists through explicit writes to platform records, browser storage or a configured service.

03 / READING AND WRITING

Two interaction paths.

CHROME

Hub modules

Content scripts · DOM controls
Extension storage · background worker

ONRENT EVENTS

API + web interface

Records · custom fields · attachments
Authenticated page and form requests

Public API

Modules use JSON request and response bodies with api.current-rms.com/api/v1, using the configured API key and company subdomain in X-AUTH-TOKEN and X-SUBDOMAIN. Endpoints cover records such as Opportunities, items, members, Activities, purchase orders and attachments.

Page workflows

Some features read rendered page data, use existing controls or make authenticated same-site form requests. Message Hub, for example, can fall back from an API notes update to the Opportunity edit form.

API requests use the configured credentials; page requests use the signed-in browser session. These access paths can have different permissions. URLs and field identifiers below are retained as used by the integration.

04 / PERSISTENCE

Storage and retrieval.

Location	Stored data	Retrieval
Platform records	Native values and module-specific custom fields, including serialised Hub text where a module needs structured state.	Read the relevant record through the API or page workflow.
Hub Data attachments	Module data saved as text attachments associated with an Opportunity or shared configuration record.	Match the record association and attachment metadata, download the file and parse it.
Chrome storage	Client preferences, connection settings and caches in `chrome.storage.local` or `chrome.storage.sync`.	Load settings at initialisation and reuse cache entries according to the module's freshness rules.

Saved format. The three examples below use HUB-KV/1: line-based key/value text stored in an attachment or custom field. Attachment uploads send a Base64 data URI in attachment_base64; custom-field updates send the text as a string. Both use a JSON API request body. Headers identify the module, schema and update time. Dot-separated paths and __hub_type markers preserve structure; str:, bool: and num: identify value types. Strings are percent-encoded, so a space appears as %20. All examples use fictitious data and show excerpts.

Transport schedule ↓Shared policy ↓Bay assignment ↓

Example 1: edit and reload a Transport Hub schedule

Open. The user opens Transport Hub on Opportunity /opportunities/12345.
Load. Hub finds Hub Data - Transport Hub Schedules on that Opportunity and parses its schedule list. A stable thub_uid identifies “Demo delivery run”.
Edit. The user changes driver_notes from “Use main entrance” to “Use loading bay 2”.
Save. Hub merges the edit by schedule ID into the latest available list, serialises it as HUB-KV/1 text and uploads it using PUT /attachments/{id}, or POST /attachments for a new attachment. It updates the transport_hub_flags reference, preserving any separate status block, then refreshes the readable transport_hub report.
Reload. Reopening the job retrieves and parses the saved attachment. Opening the same schedule restores the updated instruction.

Excerpt from the saved attachment; other schedule fields and rows are omitted.

HUB-KV/1
module=transport_hub_schedules
schema=1
updatedAt=2026-10-17T09%3A00%3A00.000Z

schedules.__hub_type=array
schedules.0.__hub_type=object
schedules.0.driver_notes=str:Use%20loading%20bay%202
schedules.0.name=str:Demo%20delivery%20run
schedules.0.thub_uid=str:thub_demo_delivery
version=num:1

File: hub-data__transport_hub_schedules.txt · Module: transport_hub_schedules · Owner: the Opportunity.

Transport-specific save and load behaviour

The main save path checks HTTP responses for the attachment, pointer and report. Legacy migration also checks the converted format and reads saved data back. If no attachment is found or retrieval fails, the loader tries legacy transport_hub_flags data or supplied schedules. A downloaded attachment with an unparseable format can return an empty list.

Transport Hub reference ↗

Example 2: store shared policy in Settings Hub

Resolve the owner. Hub looks up Settings Hub (do not delete), creating the service with active: false if missing. This record holds company configuration independently of jobs.
Set a policy. An administrator adds enableBayHub: true to the organisation's force policy.
Save. Hub creates or updates Hub Data - Settings Hub through the attachments API. It links the attachment to the service ID with attachable_type: "Item", the API's attachment type for services.
Read and apply. The save path checks that the attachment is present on the service, then reloads and parses the document. At the next policy load, a client resolves the current member's applicable rules: defaults fill unset values, while forced values replace the applicable local choice.

Excerpt from the saved HUB-KV/1 attachment. Other document fields, including encrypted connection details, are omitted.

HUB-KV/1
module=settings_hub
schema=1
updatedAt=2026-10-17T09%3A00%3A00.000Z

policy.__hub_type=object
policy.force.__hub_type=object
policy.force.enableBayHub=bool:1

File: hub-data__settings_hub.txt · Module: settings_hub · Owner: the Settings Hub service. Module reference ↗

Example 3: a Bay Hub assignment

Configuration. Bay labels, slot IDs, owner options and ticker settings live in hub-data__bay_hub_settings.txt, attached to the existing Bay Hub Settings (do not delete) service using type Item.
Job data. Assigning Bay 2 and status “In prep” serialises the values as HUB-KV/1 text in the Opportunity's bay_hub custom field through PATCH /opportunities/{id}.
Reload. Hub combines the shared bay configuration with the job field to restore the assignment, status and notes.

Excerpt from the saved bay_hub custom field; other job fields are omitted.

HUB-KV/1
module=bay_hub_job_data
schema=1
updatedAt=2026-10-17T09%3A00%3A00.000Z

bays.__hub_type=array
bays.0=str:Bay%202
notes=str:Pack%20cables%20first
status=str:In%20prep

Job-field module: bay_hub_job_data. Bay Hub reference ↗

05 / RELIABILITY AND DEPENDENCIES

Runtime and save behaviour.

Caching. Shared helpers reuse record reads and deduplicate in-flight requests. The shared TTL helper keys persistent entries by company subdomain and namespace. Some paths return stored data after a failed refresh, so freshness depends on the module.
API limits and authentication. The page-level fetch guard pauses API calls in its script context after a 429, an exhausted remaining-request header, or repeated 401 responses. Certain network/CORS failures also trigger a pause.
Attachment downloads. Relevant helpers can use the background service worker when a direct browser download fails.
Interface changes. DOM-based features depend on page selectors, form fields and lifecycle events; platform UI changes can require corresponding Hub updates.
Separate writes. Attachment and field updates are separate requests. A later failure does not roll back an earlier write. Write coordination is local to the relevant browser or module instance; separate browsers can still issue competing writes. Read-back checks and recovery handling vary by feature.

06 / CONNECTED SERVICES

Hub Cloud
and Hub Mobile.

Hub Cloud is a separate hosted service with a company OnRent Events connection and its own account and module access configuration. Hub Mobile exposes selected workflows in a phone, tablet or desktop browser.

Its scope includes warehouse scanning, stock checks, equipment locations, inspections, repairs, availability and workshop work. Separate cloud interfaces cover transport, client access and fault reporting.

This introduces a service boundary in addition to the desktop extension. Data handling and access need to be understood for each enabled service. The desktop storage patterns above should not be assumed to describe every cloud workflow.

Mobile purchase order approval currently supports review and tracking; approval decisions use the desktop extension.

Cloud workflow reference ↗Mobile sample-data demo ↗Transport demo ↗Client demo ↗Fault reporting demo ↗

07 / MODULE REFERENCE

Further workflow references.

Module guide	Workflow	Platform data involved
Shortages Hub ↗	Calculate and present job shortages.	Opportunity items, availability dates and quarantine-related stock.
Suppliers Hub ↗	Group supplier items and PO progress.	Item supplier assignments, member details and purchase orders.
Check-In Hub ↗	Process equipment and container returns.	Assets, serials/barcodes, containers and check-in operations.
Warehouse Hub ↗	Display operational schedules and status.	Opportunities, Activities, preparation and return progress, and overdue inspections.

Complete module index ↗Smaller tools reference ↗