For organizers · Integration API v1 · additive only
Your schedule, on Gerany, in the time it takes to paste a link.
If you run a class, a club, a tour, a supper club or a venue, three paths lead here. Each one ends the same way: your dates in Explore for every neighbor nearby, seats sold at your price, and one scanner at the door.
Google Calendar, Apple Calendar, Outlook and most booking tools export a public ICS link. Connect it once under Settings → Connected calendars, or with one API call. Every upcoming date becomes an experience; changes sync every hour; cancelling in Gerany sticks.
No code. Five minutes.
Path 2
Ask your AI assistant
Copy a prompt below into ChatGPT, Claude, Cursor or Claude Code, fill in the brackets, and give it your key as an environment variable. The assistant reads the public reference and builds the sync, the website section, the door kiosk or the box office for you.
A key and a prompt. An afternoon at most.
Path 3
Use the API
Pricing and capacity, barcodes for seats you sold through your own system, validation and check-in at the door, a live attendee list with the numbers that matter. Your booking system stays in charge; Gerany is where neighbors find you and pay.
Full control, eleven endpoints.
Prompts that build the integration for you
Each prompt starts by pointing the assistant at the public reference, which is also what gerany.com/llms.txt hands to any assistant that looks. Your key lives in the GERANY_KEY environment variable; the prompts insist it never reaches a browser.
Prompt 1
Put my existing schedule on Gerany
Start here. Works for Google Calendar, Apple Calendar, Outlook, and most booking tools.
Read https://gerany.com/integration-api.md. My schedule lives in [SYSTEM — e.g. Google Calendar / Mindbody / Acuity / a spreadsheet]. First check whether that system can give me a public ICS URL; if it can, walk me through connecting it with one call to POST /v1/me/calendar-feeds using my venue's coordinates ([LAT], [LNG]) and show me how to read sync health from GET /v1/me/calendar-feeds. Only if there is no ICS export, write a small script that reads my schedule from [SOURCE] and creates each upcoming date with POST /v1/events (title, start/end in my timezone, ticket_price_cents, capacity), storing the returned event.id in [DB/file] so re-runs never duplicate, and updating price/capacity with PATCH when they change. The API key is in the GERANY_KEY environment variable.
Prompt 2
Show my upcoming dates on my own website
Neighbors pay on Gerany; your site never touches payments.
Read https://gerany.com/integration-api.md. Add an "Upcoming" section to my site [STACK — e.g. Next.js / WordPress / Squarespace code block] rendered by a server-side job (never client-side — the key must not reach the browser). It fetches GET /v1/events?organizer=me with the GERANY_KEY env var and shows title, date, price (ticket_price_cents/100 as USD) and seats left (capacity - tickets_sold). Each card links to https://gerany.com/events/{id} where neighbors pay; my site never handles payments.
Prompt 3
My booking system sells the seats; I want one door
Issue a Gerany barcode for every booking you already took, so one scanner admits everyone.
Read https://gerany.com/integration-api.md. My bookings come from [SYSTEM]. For every confirmed booking, call POST /v1/events/{id}/tickets/issue with holder_name (and note = my booking reference), keep the returned qr string with the booking, render it as a QR code on the confirmation email/page, and on cancellation call DELETE /v1/events/{id}/tickets/{code}. Map my classes to Gerany experiences by storing event.id per class date; create missing ones with POST /v1/events. Handle sold_out by telling the customer, ticket_exists by reusing the existing code. The key is in GERANY_KEY.
Prompt 4
Door check-in kiosk
A scanner page that shows the holder before admitting, with the live count at the top.
Read https://gerany.com/integration-api.md. Build a minimal check-in page for my experience [EVENT_ID]: a QR scanner (or text input) sends the scanned value verbatim to a small server proxy holding GERANY_KEY. The proxy first calls GET /v1/events/[EVENT_ID]/tickets/{code} and shows the holder's name and admissible; on a tap it calls POST /v1/events/[EVENT_ID]/checkin. Green + name on 200; distinct red screens for ticket_used vs ticket_unpaid/ticket_invalid; grey for ticket_not_found. Show the door list from GET /v1/events/[EVENT_ID]/attendees refreshed every 30 s, with summary.checked_in of summary.sold at the top.
Prompt 5
Box office: print codes for walk-ins
A command-line tool for the desk — issue, list, void.
Read https://gerany.com/integration-api.md. Write a command-line tool: issue <event_id> "<name>" [note] calls POST /v1/events/<event_id>/tickets/issue, prints the holder name and renders the returned qr string as a QR code in the terminal and as a PNG file; list <event_id> prints GET …/attendees as a table with the summary line; void <event_id> <code> calls DELETE …/tickets/<code> and explains ticket_paid if it comes back. Key from GERANY_KEY; exit non-zero on any error and print the error code.
Prompt 6
Verify the integration end to end
Run this once; it creates and deletes a test experience and exercises every ticketing call.
Using GERANY_KEY from the environment against https://gerany.com/v1: (1) create a $10 test experience starting tomorrow with capacity 2; (2) read it back with GET /v1/events?organizer=me and confirm ticket_price_cents is 1000; (3) PATCH capacity to 3 and confirm; (4) issue a ticket to "Test Holder", look it up and confirm admissible is true, check it in, look it up again and confirm admissible is false; (5) issue two more and confirm the fourth returns sold_out; (6) fetch the .ics and confirm the SUMMARY; (7) DELETE the experience. Print each request, status and a one-line result. If any step returns verify_required, photo_required or provider_not_payable, stop and tell me what to fix in the Gerany app — those are account states, not API errors.
What a key can do
A key acts as your account on the events surface only. Messages, calls, money and profile refuse it; buying tickets and RSVPing stay in the app. So a leaked key can list, price and admit — never spend.
Method
Path
What it does
POST
/v1/events
Create an experience; ticket_price_cents ($10–$2,500) sells seats, capacity caps them
GET
/v1/events?organizer=me
Your own experiences, wherever they are (add &canceled=1 to reconcile)
PATCH
/v1/events/{id}
Change price (until the first ticket) or grow capacity
DELETE
/v1/events/{id}
Cancel; live tickets are voided and holders notified
POST
/v1/events/{id}/tickets/issue
Mint a barcode for a seat sold elsewhere, a guest or a staff pass — returns qr
GET
/v1/events/{id}/tickets/{code}
Validate a scanned code without redeeming it (admissible true/false)
POST
/v1/events/{id}/checkin
Redeem a code at the door, exactly once
DELETE
/v1/events/{id}/tickets/{code}
Void an issued ticket (bought tickets are refunded in the app instead)
GET
/v1/events/{id}/attendees
Door list + summary: sold, checked in, pending, issued, revenue
GET
/v1/events/{id}/ics
The experience as a calendar file
POST
/v1/me/calendar-feeds
Connect a public ICS URL; imports now and every hour after
The barcode
A ticket is the string gerany:ticket:<code> (32 hex characters). Render it as a QR code; a Code-128 barcode works too. The Gerany app, a kiosk built on the check-in endpoint, and the lookup endpoint all accept the payload or the bare code. A bought ticket and an issued one are indistinguishable at the door.
The money
You name the price; the buyer pays it plus Gerany's flat 8% + $0.30, and the full price reaches your payout account the moment they pay. Selling tickets needs a Gerany+ plan and a payout account; free experiences and issued tickets never do. Tickets you issue for seats sold elsewhere carry no Gerany fee at all.