Hi.Events: 258 title matches and an account-scoped API
Hi.Events is a self-hosted event-management and ticket-selling platform. An instance can hold organizer profiles, events, teams, orders, attendees, payment settings, API keys, and webhooks. The product's public event page is only one part of the application. The more sensitive data sits behind the organizer and account surfaces.
ZoomEye count-only measurements on 2026-11-09 between 23:46 and 23:47 UTC returned 258 assets for title="Hi.Events", 334 for the product name in the HTTP body, and zero for app="Hi.Events". The query used sub_type=all, page 1, and page size 1. The counts are matched records, not counts of active organizers or exposed attendee records.
The title and body counts are close, which suggests that the string is a useful discovery marker. The absent application fingerprint means the index should not be used to claim a complete Hi.Events population. A title match may be a public event, an instance landing page, or a custom organizer portal.
Account, organizer, and event scope
Hi.Events documentation describes API keys as belonging to one account. A key created in one account cannot see another account's organizers. The API reference also says some endpoints cannot be used with a key even when the key has read-and-write permission, including profile and security operations, teams, API-key management, payouts, card readers, VAT settings, and account settings.
That is a useful role ceiling, but it still leaves a review task. A key can list and create organizers and events, update event settings, publish events, and manage webhooks depending on its permissions. The owner should know which organizer or event a key can reach and whether it can change payment or publication state.
The help center describes Admin, Organizer, and view-only team roles, with access limited to the organizers or events assigned to each person. It also documents two-factor authentication and SSO. These controls are only effective when the deployment's account model matches the team's actual structure. A shared admin account defeats per-person review.
Measurement method
The SDK requested one record per dork with sub_type="all", page 1, and page size 1. It read exact totals only and did not download asset records. The public search link uses the title query. Operators can confirm a candidate through the public organizer page and then verify the hosted application from an authorized session.
The count does not tell whether a host is a demo, a cloud instance, or a self-hosted deployment that has been patched. It does not reveal whether API documentation is enabled or whether registration is open.
A practical Hi.Events review
Inventory accounts and organizers first. Identify the account owner, every team member, and any API key used by a website, CRM, badge printer, or accounting integration. Check the last-use date and the event scope attached to the key.
Test the API key boundary. With a key limited to one organizer, attempt to read or update a second organizer. Confirm that the API returns an access-restricted result rather than silently broadening the scope. Repeat the test for event-specific operations and webhook management.
Review public event pages and checkout flows. Determine whether attendee data, order data, or payment settings can be reached through a guessed API path. The public checkout is designed to create an order, not to expose internal records.
Check SSO and two-factor enforcement. A team that has multiple administrators should not rely on a single shared password. If SSO is enabled, confirm that the identity provider's group mapping matches the Hi.Events roles and that removed users lose access.
What the title count supports
The 258 title matches and 334 body matches show a measurable application footprint. They do not prove that 258 organizations are running Hi.Events or that any organizer boundary is broken. The zero app count is an inventory gap, not a security verdict.
The useful conclusion is that Hi.Events is a discoverable self-hosted ticketing product with a well-documented API-key scope model. The defender's next step is to compare that model against the configured team and event boundaries, then test one key beyond its declared scope.
Top comments (0)