events/README.md

Events - LNbits extension

For more about LNBits extension check this tutorial

Sell tickets for events and use the built-in scanner for registering attendees

Events allows you to create tickets for an event. Each ticket is in the form of a unique QR code. After registering and paying, the user gets a QR code to present at registration/entrance.

Events includes a shareable ticket scanner, which can be used to register attendees.

Usage

1. Create an event
   

2. Fill out the event information:

   • event name
   • wallet (normally there's only one)
   • event information
   • closing date for event registration
   • begin and end date of the event

   

3. Share the event registration link
   

   • ticket example
     

   • QR code ticket, presented after invoice paid, to present at registration
     

4. Use the built-in ticket scanner to validate registered, and paid, attendees
   

Guest checkout, card payments and email delivery (aio fork)

• Identity. POST /events/api/v1/tickets/{event_id} accepts either an LNbits user_id or a guest name + email; a user_id ticket may also carry an email so logged-in buyers get their ticket mailed.
• Payment methods. extra.payment_methods (lightning, fiat) lists the rails an event accepts; an empty list keeps the legacy rule (Lightning always, fiat when allow_fiat). The effective list is published on the NIP-52 event as tickets_payment_methods and enforced at purchase.
• Return to the calling app. A client may send frontend_url (its app root, e.g. https://app.example/events). Its origin must be one of LNBITS_CORS_ALLOWED_ORIGINS, the LNbits base URL or LNBITS_CUSTOM_FRONTEND_URL, otherwise the request is refused. Under that root the extension builds the Stripe success_url (/events/{event_id}?checkout=success&tickets=<id,id>), cancel_url (/events/{event_id}?checkout=cancelled) and the emailed ticket link (/events/ticket/{ticket_id}). Absent, the LNbits host is used as before.
• Stripe session. The buyer's email is passed as customer_email (prefilled and locked on the hosted page); the line item is named after the event; event_id, quantity and ticket_ids ride along as metadata.
• Email. Multipart text + HTML (links, no images) with the ticket card attached — a self-describing PNG (site, event, when, where, QR with the instance logo, name on ticket, ticket id) also served at GET /events/api/v1/ticket-card/{ticket_id}; the bare QR stays at GET /events/api/v1/qr/{ticket_id}. Headers carry Date, Message-ID and a From display name — extra.organizer_name gives "Organizer via ", otherwise the site title. Replies go to extra.reply_to_email, falling back to the event owner's account email (no Reply-To when neither exists). The From address is always the instance mailbox, which is what DKIM signs. extra.copy_to_organizer BCCs every ticket email to that reply-to address (envelope only, no header) so the organizer keeps a copy; the admin ticket table shows an "Email sent" column from extra.email_notification_sent. POST /events/api/v1/tickets/{ticket_id}/resend-email returns a TicketResendResult with per-channel outcome.

Powered by LNbits

LNbits is a free and open-source lightning accounts system.