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.
• Promo codes. extra.promo_codes (code, discount_percent, active, max_uses; used_count is derived from paid tickets) are organizer-only: they are never part of public responses. Buyers preview a code with POST /events/api/v1/promo/validate/{event_id} ({codes, quantity} → v2-shaped BasketTotals + currency); purchase enforces active and max_uses (each ticket of a multi-ticket purchase consumes one use) and rejects bad codes with a distinct detail. Updates that omit extra.promo_codes keep the stored list.
• 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 (site title). 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.