One account. Every fan. Every app.

Most leagues and clubs only know their fans in fragments – spread across as many systems as they have digital services.

• One account per service. Ticket shop, fan shop, app, streaming and prize draw each have their own registration. Fans enter the same details five times and forget five passwords.
• No complete picture. Whether someone holds a season ticket, buys regularly in the fan shop and reads the newsletter is stored in three databases – with no connection between them.
• Consent without proof. Opt-ins sit as checkboxes in different systems. Which text a fan agreed to, and when, often can no longer be proven.
• One newsletter for everyone. Without connected data, everyone gets the same email – instead of the fans an offer is actually right for.
• Data protection by hand. Access requests, withdrawals and deletions have to be handled in every system separately.
• Every new app starts from zero. Login, password reset, two-factor protection and registration are built and maintained over and over again.

One login for all applications of your league or club – secure, in your design and in your fans’ language.

• Single sign-on. Sign in once, then use every other application without entering the password again. Without “Keep me signed in”, the session lasts until the browser is closed, at most 12 hours; with it, 30 days from last use.
• Open standard. PuckID speaks OpenID Connect (authorization code flow with PKCE). Server applications can additionally authenticate with a client secret.
• Two-factor protection. Authenticator app with QR code and recovery codes, or a code by email. Fans set it up voluntarily; you can require it per application. The admin portal always requires it.
• Registration on your terms. Open to everyone, limited to specific email domains or by invitation only. New members automatically receive the project’s default roles.
• Invitations with a role. Invite staff, partners or licensees by email – their role is already set.
• Roles per project. Your applications receive the fan’s roles directly in the token and decide for themselves what the fan may do.
• Password rules. Minimum length as well as upper- and lowercase letters, digits and special characters are configurable. “Forgot password” sends a link that is valid for 15 minutes.
• Your design. The login pages carry your logo, colors and fonts, optionally with a large image. Every project and every application can have its own design.
• Multilingual. German and English, more languages prepared. PuckID picks the browser language, fans can switch, and the choice is saved to the account. Applications can set the language at login.
• Versioned terms of use. When you release a new version, fans accept it at their next login – every acceptance is stored.
• Full control for applications. Silent sign-in in the background, forced re-authentication for sensitive actions, and sign-out that ends the PuckID session – after that, no application starts without a password.

You decide which details you need – PuckID asks for them at the right moment and records which text a fan agreed to, and when.

• Custom form fields. Text, email, phone, number, date, select list with groups, radio buttons, checkbox, multi-line text and info texts without input. With required fields, placeholders, length and date limits.
• System fields for everyone. First name, last name, date of birth, gender and address with country – 250 countries, shown in the fan’s language.
• Forms per project. Arrange fields in groups, on one page, in steps or in tabs, with widths from 25 to 100 percent. Each project can make a field mandatory.
• Missing details at login. If a project requires a detail that is still missing, PuckID asks for it at the next login – once, not every time.
• Consent belongs to the account. A fan gives an opt-in once, and it applies to all projects of your league or club. Where a project needs its own value – such as a jersey number per team – the most recent value is already filled in.
• Proof of every answer. Every change to a question, description, options or required status creates a new version. Every answer remembers the version it was given under. That way you can prove which wording a fan agreed to.
• Data sharing per application. You decide what an application learns: email, name, individual fields, events, segments. The setting applies to the token, the API and webhooks.

Logins, profile details and what your applications report become segments – and you reach them directly in your newsletter tool.

Events from your applications

• Ticket shop, fan shop, app or prize draw report what a fan does: ticket bought, item viewed, game watched. A dedicated data API receives the events.
• For each event type you define its fields (text, number, yes/no, date, also lists such as the items in a shopping cart) and how long it is kept.
• Events always belong to your tenant. They are never shared with another league or club – not even for the same person.

Segments

• Conditions on events: count or sum (“at least 4 tickets”), ever, in the last N days, since or between two dates, with up to five filters on fields.
• Conditions on the profile: access to a project, role, first access within a period, value of a profile field (e.g. opt-in “Yes”), newsletter subscribed.
• Combine with “all” or “at least one”, every condition can be negated. A preview counts the matches before saving and shows examples.
• PuckID recalculates segments after saving and every 15 minutes. You see the members, since when they have belonged, and how the size develops.
• Your applications ask the API which segments a fan belongs to – for personalized offers, for example.

Analytics

• Charts for events, field values and the history of every segment, with time ranges and a table view.

Newsletters

• Fans subscribe to newsletters directly in “My Account”. PuckID sends the confirmation (double opt-in) itself and stores the wording, timestamps and IP addresses.
• PuckID syncs with your newsletter tool every 5 minutes – in both directions. Anyone who unsubscribes via the link in an email is unsubscribed in PuckID too. listmonk is connected; further tools can be added via an adapter interface.
• Segments to your newsletter tool: PuckID creates a dedicated list for a segment and keeps it up to date. Via a newsletter, only fans who have confirmed their subscription end up there – and only once you have confirmed that your subscription text mentions personalization.
• Custom lists: Alternatively, a list is built directly from all members of a segment, such as everyone with opt-in “Yes”. Whoever is responsible for the consent confirms this when creating the list; PuckID stores who and when.
• When an account is deleted, PuckID removes the address from all lists in the tool and deletes it there if it is no longer on any other list.

PuckID is built so that fans can trust it with their data – and so that you can prove consent, withdrawal and deletion without manual work.

Privacy

• Consent with proof. Opt-ins and terms of use are versioned; for newsletters, PuckID stores the wording, timestamps and IP addresses of the confirmation.
• Separate tenants. Each league and club sees only its own fans, details, events and segments. No data is shared between tenants.
• Data minimization per application. Each application receives only the details you release to it.
• Right to erasure, built in. Fans end individual accesses, delete everything held by your organization or their entire account. Your applications learn about it immediately via webhook, including the reason; addresses disappear from the newsletter lists, and events are removed within 15 minutes.

Security

• No secrets in plain text. PuckID stores passwords, client and API secrets, login codes and the values of session cookies only as hashes. Credentials for newsletter tools and the keys of authenticator apps are stored encrypted.
• Two-factor protection for fans on request, enforceable per application, always in the admin portal.
• Protection against guessing. Password, two-factor codes and password reset are rate-limited against repeated attempts.
• Sessions that end when they should. After a password change, a change to the second factor or a block, no old session remains valid. Cookies are HttpOnly and Secure.
• Strict rules for applications. Only registered redirect URIs, PKCE for public applications, signed tokens with rotatable keys.

Fans manage their details, security and consents in one place – in your design, without contacting your support team.

• Overview: name, email address, two-factor status and all accesses with your organization, with dates.
• Personal details: name, address and every detail your projects ask for. Opt-ins appear once, even if several projects ask for them.
• Change password: with the current password and according to your password rules. Other devices have to sign in again afterwards.
• Two-factor protection: set up, switch or turn off an authenticator app or email code, or generate new recovery codes – each with the password, and when first setting it up also with a code sent to the fan’s own inbox.
• Newsletters: subscribe and unsubscribe, request the confirmation email again.
• End access: for projects that allow it (for example with self-registration). The page explains beforehand what will be deleted and what remains.
• Delete data: everything held by your organization – or the entire PuckID account with all providers. With password and explicit confirmation, followed by a confirmation email. Anyone who is the only administrator of an organization can delete their account only once someone else takes over.
• Language: can be switched at any time, the choice is saved to the account.

Your team manages projects, applications, forms and segments itself – no developers, no support ticket with the vendor.

• Projects and roles. A project for each service (fan portal, licensing, newsletter …), with its own roles, registration rules, allowed email domains and the choice of whether fans may end their access themselves.
• Users. Assign roles, block or remove accesses, send invitations. The detail page shows a fan’s details together with the wording of the question at the time, as well as their events and segments.
• Applications. Register applications, manage redirect URIs, generate client and API secrets, require two-factor protection and assign a dedicated design.
• Data sharing and webhooks. Decide per application what it sees; webhooks for new, changed and removed accesses. Webhooks are signed, retried on errors and paused if a receiver stops responding for good. A log shows every delivery, and individual deliveries can be resent.
• Form fields. Create fields with version history and arrange them in groups per project by drag & drop.
• Designs. Give the login pages your own look – logo, colors, font, background image.
• Terms of use. Upload new versions as text or PDF and release them.
• Event types, segments, analytics. Define events, build segments with a preview and follow trends in charts.
• Newsletters. Connect newsletter tools, offer newsletters, hand over segments and custom lists, and start the sync yourself at any time.
• Protected and multilingual. Sign-in always with a second factor; interface in German and English.

PuckID is an OpenID Connect provider: any common OIDC library connects to it with the issuer URL, client ID and redirect URI – no proprietary SDK.

Login (OpenID Connect)

• Discovery at /.well-known/openid-configuration, plus authorize, token, userinfo, JWKS, token revocation and logout (RP-initiated logout).
• Authorization code flow with PKCE (S256); confidential clients optionally with a client secret (client_secret_basic or client_secret_post).
• Scopes openid, profile, email. ID token as a JWT signed with RS256; claims include sub, name, given_name, family_name, email, email_verified, roles, tenant, locale, amr, auth_time.
• prompt=none for silent sign-in, prompt=login and max_age for a fresh sign-in, ui_locales for the language of the login page.

Webhooks

• Events user.added, user.updated (with the names of the changed details) and user.removed (for deletion requests with the reason data_deleted or account_deleted).
• Webhooks contain only the event, the user ID and the names of changed details, no values; the application fetches the data via the API – so nothing that was not released ends up in third-party logs.
• Signed with HMAC-SHA256 in the headers webhook-id, webhook-timestamp and webhook-signature; automatic retries, paused on persistent errors.

What your application no longer has to build

Registration, login, password reset, two-factor protection, profile management, consents, terms of use, language selection and deletion requests.