--- title: "Connect Luma to Rig | Rig guide" description: "Luma issues API keys per calendar, not per account. Sync events, registrations with approval and check-in status, and your calendar audience." canonical: "https://rig.so/guides/connect-luma" format: markdown --- Search guides, references, playbooks…⌘K Browse guides # Connect Luma to Rig Sync events, registrations and your calendar audience into the warehouse. Event data answers a question nothing else can: who registered, who actually turned up, and what happened to them afterwards. That last part needs the guest list sitting next to the CRM, which is the whole reason to bring it across. Requirements Luma Plus on the calendar you want to sync Time required 3 mins ## Before you start The key belongs to a calendar, not to your account This is the thing that catches people out. Luma issues API keys per calendar, so the key you create while looking at one calendar sees that calendar and nothing else, even though you created it and you can see several. If you run separate calendars for different cities, brands or series, each one is its own key and its own connection in Rig. Check which calendar you are inside before you generate anything. - API access requires Luma Plus on that calendar. Without it the developer section is not there. - You need to be an admin of the calendar, not simply a host on one of its events. ## Create the API key 1. In Luma, open `Calendars` and click the calendar you want to sync. 2. Go to `Settings`, then `Developer`. 3. Create an API key and copy it. ## Connect it in Rig New to Rig? Watch how to find Connections 1. In Rig, open `Connections` and go to `Sources & actions`. 2. Search for **Luma** and open the card. 3. **Calendar API key**: paste the key. 4. Click `Test`, then `Sync`. 5. For a second calendar, add a second Luma connection with that calendar's own key. ## What Rig pulls in Luma lands in its own `luma` schema, in five tables. - **Events**: every event on the calendar, with its tags and who submitted it. - **Event guests**: one row per registration, carrying the three things that make event reporting worth doing. Approval status, so you can separate requested from accepted. Check-in time, so registered and attended stop being the same number. And the answers people gave on the registration form, which is often the only first-party data you get from a lead. - **People**: the calendar audience, meaning everyone who has ever interacted with it, with approved and checked-in counts and lifetime revenue. - **Person tags**: the tags you have applied to people on the calendar. - **Coupons**: the discount codes on the calendar. Two things to know before you write a query against this Guest rows do not carry the event they belong to. Luma does not include it, so Rig writes the parent event's ID onto each guest row as it syncs. Join guests back to events on that column rather than looking for an event field inside the guest. Lifetime revenue on the people table is in cents, and in US dollars regardless of what currency you sold tickets in. Divide before you report it, and do not assume the currency. ## Good to know - **Every sync re-reads everything**. None of Luma's list endpoints accept a changed-since filter, so there is no way to ask only for what moved. Rig re-walks the calendar each run and merges on IDs, which means no duplicates and no drift. - **Late check-ins and approvals are picked up**, precisely because of the above. A guest approved a week after registering updates in place on the next sync. - **Rig stays well under Luma's rate limit**, at roughly sixty per cent of it. The calendar's budget is shared with the Luma interface and any webhooks you run, so leaving headroom keeps a sync from slowing down the thing your team is actually using. - **Registration answers vary by event**, because each event defines its own form. Expect the shape of that data to differ between events rather than being a fixed set of columns. ## Troubleshooting - **There is no Developer section**: the calendar is not on Luma Plus, or you are looking at your personal profile settings rather than the calendar's. - **Events sync but they are the wrong ones**: the key came from a different calendar. Keys are per calendar and give no indication of which one they belong to, so regenerate from inside the right calendar. - **Guest counts look low**: check whether you are counting all registrations or only approved ones. Both are in the table, and the approval status column is what separates them. - **Attendance is zero for an event that was well attended**: nobody was checked in through Luma. The check-in timestamp records what Luma saw at the door, so an event where check-in was not used has registrations but no attendance. ## What people use this for - Find out whether events produce pipeline - Track the registration to attendance gap - Use registration answers as audience data [More ideas for using Luma](https://rig.so/integrations/luma) Was this guide helpful? Yes No --- - [This page as HTML](https://rig.so/guides/connect-luma) - [Site map for language models](https://rig.so/llms.txt) - [API and agent documentation](https://rig.so/developers)