Membership access integrations

A membership access integration connects a member record to supported doors, gates, lock groups, codes, or remote-opening actions. It is separate from reservation-specific access and follows the membership integration's own configuration.

Use access integration settings only when you are responsible for the venue's access policy. Coordinate material changes with the person managing the hardware provider and with Thril support where required.

What members can receive

Depending on the provider and configuration, a member may receive:

• an access code in the Thril wallet;
• access through configured lock groups or gates;
• a remote-open action in the app;
• access limited to selected weekdays and times.

The customer finds available membership access under Wallet → Memberships on web or mobile.

Configure access times

Configure allowed intervals for each weekday. Allowed access times lists them in weekday order, and days that share the same times are shown on one row, for example "Mon–Fri 06:00-08:00".

Leave every day empty and the member's code opens nothing on its own — only the doors of a reservation they hold. An empty access-time configuration can also prevent remote opening even when the member is otherwise active.

For supported membership integrations, a 00:00-00:00 interval represents full-day access. Overnight intervals can continue into the following day. Verify the intended schedule with the provider-specific configuration before launch.

Rollock

A Rollock membership configuration can include:

• lock groups for code-based access;
• specific controllable locks for in-app remote opening;
• allowed access times.

If no controllable locks are configured, code-based access can still be available through lock groups. Rollock membership PINs shown to customers include the required trailing #.

See Rollock for the wider integration setup.

Tolotrack

A Tolotrack membership configuration can include controllable gates and can be configured not to show PIN codes. The customer may therefore see a gate action, a code, or neither depending on the setup.

See Tolotrack for provider setup.

Kulku.io

A Kulku.io membership configuration contains only doors and allowed access times. There are no codes and no provider-side provisioning: the member's access is the in-app door-opening button, and Thril alone decides when it works. Door names must match the lock names configured in Kulku.io exactly.

Because nothing is provisioned on Kulku.io's side, changing the doors or access times of a live Kulku.io membership takes effect immediately, with no reprovisioning needed.

See Kulku.io for provider setup.

Thrilock

A Thrilock membership configuration contains access paths, an optional member PIN, and allowed access times.

• Access paths select which doors the membership reaches.
• Give each member a door PIN issues every member their own code. They receive it by email and see it in the app. App unlock and enrolled RFID tags work without it.

Select access paths whose doors have a credential reader. Where none of them has one, members receive a code they cannot use anywhere, and the form warns about it.

Thrilock reads an empty schedule as no restriction, so a membership with no allowed access times creates no access assignment. It mints the member's PIN credential only, and a credential opens nothing until an assignment connects it to doors. The code then works inside a reservation the member holds and nowhere else.

Where a member holds two memberships that both issue a door PIN, a booking shows the code of the membership that grants the booked resource's access path. Where neither grants it, the oldest membership answers. The booking labels the code as the member's own membership code, so it is recognizable as the number in their wallet.

A member's PIN stays readable under Credentials. Open the credential and the PIN row shows the code, so a member who forgets it does not need a new one. Only a role that may reissue the credential sees the code, and card and biometric values are not shown after creation.

See Thrilock for day-to-day use at the venue.

Membership validity and provider provisioning

In-app remote opening checks that the member is active, currently allowed to access, and not restricted by a blocking unpaid renewal.

Provider-side provisioning is not identical. Creating a future-start member can submit an integration record before the membership's active date, and a provider may create a PIN or lock-group entitlement immediately. Before adding future-start members to an access-integrated product, confirm that early provider access is prevented by the provider configuration or operational process.

Editing live access times, lock groups, gates, or controllable locks updates Thril's current configuration and in-app checks, but it does not automatically reprovision existing provider records. Sync members creates missing records; it does not refresh records already created by the provider. Coordinate reprovisioning with Thril support or the provider when live access settings change.

When access is removed or restored

Thril requests removal or suspension when relevant membership conditions change, including:

• the member expires or is removed;
• a membership pause becomes active;
• an unpaid recurring renewal restricts reservations and access;
• the member is no longer eligible under a lifecycle rule handled by the integration.

When a pause ends or an expired member is extended, Thril requests restoration only when the membership is otherwise eligible. The provider may take additional time to apply the request.

Diagnose missing membership access

Check the layers in this order:

1. Confirm the member is currently active.
2. Check for an active membership pause.
3. Check for an unpaid renewal restricting reservations and access.
4. Confirm the membership integration is active.
5. Confirm lock groups, gates, controllable locks, and allowed times.
6. Check the member's integration status for pending creation or removal.
7. Allow for the provider's processing time before retrying.

If reservation access works but membership access does not, verify that the customer is expecting the correct access type. Reservation codes and membership codes can come from different configuration paths.

When escalating, provide the membership, member, provider, expected access point, attempted time, visible wallet action or code, and current integration status. Do not send reusable access codes through an unsecured support channel.

Operational boundaries

• Hiding a membership from the shop does not remove current access.
• Editing an integration can affect Thril-side checks, but existing provider records require separate reprovisioning.
• A pause removes membership access but does not delete the membership.
• Restoring a paused integration does not override expiry or an unpaid-payment restriction.
• External provider state can update after Thril, so verify both systems when timing matters.