Door codes day-to-day: view, share, and manage access codes

After your locks are connected, this is how door codes behave every day — where to look one up, what the customer sees, and what happens when a booking changes.

Your locks are connected and mapped — this is the day-to-day: where to find any booking's door code, what the customer already sees, and what happens to a code when a booking is cancelled, rescheduled, or moved. (For admins and front desk. No setup needed if your locks are already connected.)

Access codes live under Settings → Access Controls in the admin app, on the Access Codes tab. If you haven't connected a lock yet, start with How access controls work in OpenCourt.

Where do I see a booking's door code?

Front-desk answer first. Go to the Access Codes tab. It lists every code across all your locks, with a link from each row's Event to the booking it belongs to.

The Access Codes table listing door codes with their lock, booking, space, validity window, and status.

There's a search box above the table, so you can type a customer's event name or a code to jump straight to it.

Per lock. Open a lock from the Locks tab and scroll to Lock Activity for just that lock's history. A lock with no codes shows No access codes have been generated for this lock.

Each code is created the moment a booking is made on a lock-mapped space — your courts, bays, or fields. By default it's active from 30 minutes before the start to 10 minutes after the end — if you've customized a lock's access rule, the window follows that rule instead. The Status column tells you where each code stands:

Status	Meaning
Active	The code works right now.
Upcoming	Issued, but its window hasn't started yet.
Expired	The booking window has passed; the code no longer works.
Revoked	The code was removed (for example, the booking was cancelled).
Unknown	OpenCourt can't confirm the code's state on the lock — check that the lock is online.

On Native scheduling, a far-future booking may show a code that isn't on the lock yet — the real PIN appears once it's pushed (~72 hours ahead; Just-in-Time pushes ~60 minutes ahead). This is expected. See Access codes & scheduling.

What does the customer see?

Sharing is automatic — you don't send codes out. The customer already has theirs:

In the app, on the booking or event details as Access code. Before it's usable they see Access code will be available at {time}. It also appears in their reservations list.
In email — the booking confirmation, event-joined, and event-reminder emails each include a line Access Code: {code}.

So the front desk only needs the Access Codes table for walk-up questions ("what's my code?") — everyone who booked already received theirs.

What happens when a booking changes?

Change	What happens to the code	What the customer gets
Cancelled	Code is revoked.	Their code stops working.
Rescheduled (same space/door)	Same PIN, validity window updates.	No new code to learn.
Moved to a different space/door	Old code revoked, new code issued.	An automatic Your access code changed email.
Extended	Same PIN, window extends.	No new code to learn.

Using manual codes without a smart lock

You don't need a smart lock to hand out door codes. Under Settings → Access Controls, the access-code mode has three options:

Off — No access codes are used.
Manual Access Codes — Set access codes manually on events and reservations. A default code can auto-apply to court bookings. Pick this and fill the required Default access code for court bookings field (for example 1234). Every booking then shows that code. (Those labels follow your club's wording — "bay" or "field" instead of "court" where that applies.)
Smart Lock ({provider}) — the connected-lock behavior described above, with per-booking generated codes.

In Manual Access Codes mode, any single event or reservation can override the default in its own Access Code field. Manual codes have no time window — they're always shown to participants, not just around the booking.

Switching away from Smart Lock mode warns: New events and reservations will no longer generate {provider} access codes. Existing codes on previously created events will remain active. Your {provider} connection and lock mappings will be preserved if you switch back. Nothing is lost — you can switch back later.

The activity trail

Per lock. Each lock's page has a Lock Activity section showing the last 2 days by default.
Club-wide. The Unlock History tab logs every event with Date & Time, Lock, Action, Method, and Details.
Club activity log. In-app unlock attempts — successes and failures — also land in the club activity log with the customer's name, because the customer was signed in when they tapped. Keypad entries can't be attributed to a person: a door code is shared by everyone on the booking, so it identifies the booking.

Reading the Method column

Method is the most useful column, because it tells you how the door opened — and that determines whether there's a booking to trace it back to.

Method	What happened	Can you tie it to a booking?
Keycode	Someone typed a code on the keypad.	Usually yes — Details shows the code and links to the event, e.g. 1027 · Coach-Led Drill Sessions.
Manual	The door was operated by hand — a thumb-turn from the inside, a key, or the lock's own button.	No. There's no code involved, so Details just reads Reported by lock.
Auto-lock	The lock re-locked itself after its timer.	No — it's the lock's own housekeeping.
Unknown	The lock reported a change without saying how.	No.

So a run of Manual unlocks isn't a mystery — that's people leaving through the door from inside. When you need to know who, look for Keycode rows: those are the ones that carry a code and a linked booking.

Not every Keycode row resolves to a code. If someone typed a code the lock knows but OpenCourt didn't issue — a staff code you set up directly on the hardware, for example — you'll see Keycode with Reported by lock and no link. That's expected, and a useful signal that a non-OpenCourt code is in circulation.

If something goes wrong

A customer says their code doesn't work — check the row's Status and the lock's Lock Activity, then see When a customer can't get in.
The code shows but isn't on the lock yet — this is the Native "not-yet-materialized" case; the deep triage is in When a customer can't get in.
The unlock history shows "Access Denied" or "Access Code Failed" — start the diagnosis in When a customer can't get in.