For organisers
Give your web developer a key, and choose which domains may use it.
Examples use a fictional festival, summer-fest. Sign in at events.grofomo.com and they switch to your own events.
Your event data belongs to you. This page is how you hand a web developer the parts they need — and nothing else.
Everything here lives in EventOS → Settings → Developers.
Give your developer a key
Two kinds of key exist, and the difference matters:
Publishable (pk_live_…) | Secret (sk_live_…) | |
|---|---|---|
| Where it belongs | A website's front-end code | A server, or a build pipeline |
| Visible to the public? | Yes, by design | Never |
| Shown to you | Any time | Once, at creation |
Hand over a publishable key. It is meant to be readable in your website's page source: it identifies your organisation, lets us rate-limit and attribute traffic, and can be revoked the moment you want it to stop working. What it is not is a password. Anyone who views source can copy it — which is exactly why it can only ever read the data you have already chosen to publish.
A secret key is for a developer whose site fetches on their server. Treat it like a password.
Choose which domains may use it
Add your developer's domains to Allowed domains — the live site, and their staging URL if they have one. Entries can be:
https://www.yourfestival.com— that exact sitehttps://*.yourfestival.com— any subdomain of it*— any site at all
This stops someone lifting your publishable key out of your page source and using it to power their site's festival listing. It is a browser-level control, so it does not affect calls made from a server.
Two access modes
Under Public API access you have two settings:
- Open — the feeds answer without a key. This is where every organisation created before we introduced keys still sits, so nothing broke.
- Key required — every request must carry one of your keys. New organisations start here, with a publishable key already minted for you.
If you are on Open and want to move: mint a key, give it to whoever builds your site, confirm their site works with it, then switch. The order matters — flipping first will break a live site mid-sentence.
One side effect worth knowing: once you require a key, your feeds stop being cached on our shared CDN (a cached copy could otherwise be replayed to someone without a key). Your site will do slightly more work; your developer can cache on their side, and we explain how.
What to send your developer
Copy this:
Event slug: summer-fest
API base: https://api.grofomo.com
Publishable key: pk_live_… (from Settings → Developers)
Docs: https://developers.grofomo.comFeedback from your own site
Switch feedback on from the event's Feedback page (under Measure). One click creates a ready-made form: overall and venue ratings, a would-you-come-again question, favourite act and stage pickers that fill themselves from your lineup, and room for comments.
Once it is on, that page shows the form's key. Hand the key to whoever builds your site: they pull the questions from the form endpoint and post answers back to the submissions endpoint, and every answer lands on your Feedback page, aggregated. The favourite-act options arrive pre-filled from your live lineup, so the site never goes stale as bookings change.
Turning a key off
Revoke it in the same place. Revocation is immediate — the next request using it gets a 401. Mint the replacement, get it deployed, then revoke the old one, so there is no gap.