Connect Luma to Rig

    Sync events, registrations and your calendar audience into the warehouse. Event data shows who registered, who turned up and what happened to them afterwards. The last part needs the guest list next to the CRM.

    Requirements
    Luma Plus on the calendar you want to sync
    Time required
    3 mins

    Before you start

    Each key belongs to one calendar
    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. Being a host on one of its events is not enough.

    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

    Adding a source needs a workspace owner, or a role with the Manage connections permission, on a workspace where you manage your own connections. If the Connectors tab says “Data ingestion for this workspace is managed by Rig”, ask an owner or Rig support to add the source.

    1. In Rig, open Connections, choose the Connectors tab and go to Sources & actions.
    2. Search for Luma, open the card and click Connect.
    3. Calendar API key: paste the key.
    4. Click Continue. Rig checks the credentials and lists the streams it can reach, so choose the ones you want and click Connect.
    5. The source then syncs on its schedule, which is nightly unless you change it. To load data straight away, click Sync on its row; Test pulls a small sample first if you want to check the connection.
    6. For a second calendar, open the Luma card again and click Add another connection. Once a Luma connection exists, the form asks for an Account label and will not continue without one, so name the calendar there, then paste 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 keeps the data free of duplicates and picks up changes. Records deleted in Luma are not removed, so they stay in the warehouse.
    • 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

    Was this guide helpful?