Building on UniClubs
If your club has its own website, you can plug it into UniClubs instead of rebuilding logins, member lists, and event pages. There are three building blocks, all set up by a club admin under Settings → API & OAuth:
| You want to… | Use |
|---|---|
| Let students log in to your site with their UniClubs account, and know if they’re a member | Sign in with UniClubs (OAuth 2.0 / OpenID Connect) |
| Read members, memberships, events, or applications from your backend | REST API with a club API key |
| Show your events or ticket prices on your site without writing code | Events & ticket widgets |
The full technical reference is the OpenAPI spec at https://uniclubs.ch/api/external/v1/openapi.yaml (also as .json). Load it into Swagger UI, Postman, or a client generator. These pages explain how the pieces fit together; the spec has every field.
One ID per student, per club
Your club gets its own ID for each student (ucs_…). It’s the sub you get at sign-in and the userId / memberId in the REST API, and it’s the same across all of your club’s apps and API keys. Store it as your foreign key.
Other clubs get a different ID for the same student, so IDs can’t be used to match students across clubs. Your IDs also survive a student merging duplicate accounts. See Keeping IDs stable.
What isn’t there (yet)
- No outgoing webhooks. To react to membership changes, re-check at sign-in or poll the API (it supports
ETagcaching, so unchanged responses are cheap). - No CVs or documents via API. Applicant documents are only available in the panel and the event export, where every access is logged.
Data protection
Clubs act as the controller for their members’ data and UniClubs as the processor. The data processing agreement (Art. 28 GDPR / Art. 9 revDSG) is part of the Terms of Service , section 7. Anything you pull into your own systems via OAuth or the API is your club’s responsibility from that point on.