When I set out to build Eventonomy, I made one decision before writing a line of feature code: this would be a platform, not a plugin bolted onto WordPress posts. Events would live in their own database, everything would run over a real API, and every capability the paid version uses would be a capability you can use too. This post is a tour of the technology underneath and, more importantly, what it lets you do with it.

If you have read why I built BuddyNext or the developer tour of Learnomy, you know the pattern: pour the data engine first, add features second, and keep the whole thing open. Eventonomy is the events layer of that same platform, and it is the most open thing I have shipped.

A real data engine, not custom post types

Most WordPress event plugins store an event as a post and everything about it as postmeta. That demos fine and falls over in production. Every filter becomes a join against a table that grows without bound, and once a community passes a few thousand events the calendar drags.

Eventonomy does not do that. Events, RSVPs, tickets, orders, occurrences, venues, and organizers live in eight dedicated tables, indexed on the columns you actually query, with JSON columns for the flexible parts. It is designed for communities with 100,000 or more members, and the queries stay flat as the catalog grows.

The practical result for you is a data model that is honest. An event is a row. An RSVP is a row that points at it. There is no meta-key guesswork to figure out what a record means. You can query it, cache it, and reason about it like a real schema, because it is one.

Everything is an API, and the API is the product

Eventonomy is 100% REST. There is no admin-ajax anywhere in it. The blocks, the admin screens, the command line, and your own code all talk to the same endpoints under the eventonomy/v1 namespace, so anything the built-in interface can do, an external client can do too. That is the single most important technical fact about the plugin: the UI has no private back door, so you are never locked out of a capability.

There are 56 endpoints in total, 44 in the free plugin and 12 more in Pro, covering events, occurrences, RSVPs, tickets, orders, venues, organizers, media, import, and the ICS calendar feeds. A useful set of reads needs no authentication at all, so a public calendar or a marketing site can pull events without credentials. For anything that writes, first-party clients use the standard cookie and nonce, and external or mobile clients authenticate with WordPress Application Passwords over HTTPS.

GET /wp-json/eventonomy/v1/events?space_id=42&city=Berlin&per_page=20

Every list comes back in the same envelope, with totals, paging, and a cursor, so a client writes its pagination once and reuses it on every resource. High-volume calendar reads use cursor paging so they stay fast at any depth.

What this unlocks is the interesting part. Because the whole feature set is reachable over one clean API, you can put any frontend you like in front of it: a decoupled Astro or Next site, a React Native mobile app, a kiosk at the door, a Slack bot that lists tonight’s events, a server job that syncs to your CRM. The events system is a service, and the WordPress admin is just one client of it.

What you can actually build

Capabilities are abstract, so here are concrete things the technology makes straightforward, each one a project I would take on knowing the seams exist:

A headless community events hub. Point an Astro or Next frontend at the public read endpoints for the calendar and single-event pages, use Application Passwords for the logged-in RSVP and submission flows, and you have a fast decoupled events site with WordPress quietly running the backend. No scraping, no shadow database, just the API.

A mobile events app. The same API that feeds the blocks feeds a React Native or native client. Members browse, RSVP, and get their tickets on their phone, and because RSVP capacity is claimed atomically on the server, two people tapping RSVP at the same instant can never oversell the last seat.

A paid-events marketplace with your own processor. If Stripe or PayPal is not your stack, you implement one gateway interface and wire it with two filters, and your processor appears in checkout next to the built-in ones. The order lifecycle, the receipts, and the stock reversal on refund are already handled.

A members-only program inside your community. Scope events to a group, expose them on the group and profile tabs, and route new events and RSVPs into the activity feed. Members discover events where they already spend time instead of on a separate calendar page nobody visits.

An ongoing sync, not just a one-time import. Bring history in from an existing plugin with the migrator, then keep a live pipe open with the after-action hooks so every new event and RSVP lands in your CRM, your analytics warehouse, or a Discord channel the moment it is created.

Block-native, with no jQuery in sight

The interface is built as Interactivity API blocks, eighteen of them across free and Pro: calendar, list, single event, upcoming, RSVP, search, event editor, my events, attendees, and more. They all share one client-side store, so state is consistent across a page and a block you place inherits the same data layer as the rest.

For a site builder that means you compose an events experience by dropping blocks onto pages instead of wrestling shortcodes. For a developer it means a new block you build can reuse that same store and the same API envelope rather than reinventing data fetching.

The member experience is frontend-first

A technical decision I care about as much as the data model: members never need wp-admin. They submit events, manage their RSVPs, manage their attendees, and track everything from a My Events dashboard, all on the front of the site. Site owners control who can create events, whether submissions are approved or published immediately, and how many events a member can run.

The RSVP flow is built for real attendance, not a toy. Capacity limits with automatic waitlists and automatic promotion when a seat frees up. Plus-guests so one RSVP brings a known headcount. And account-less RSVP through a magic link, so a first-time attendee responds straight from their inbox without creating an account. For you, that means the friction that usually kills community event turnout is already engineered out, and you get to build on top of it rather than rebuild it.

Community-native at the data layer

Events carry a space_id, an indexed column that links an event to a community group. Because it is indexed rather than bolted on as meta, scoping a feed to a single group stays cheap no matter how large the site gets.

That one column is the foundation for group event listings, and in Eventonomy Pro it powers a full BuddyPress integration: a group Events tab with list and calendar views, a member profile Events tab bucketed into Organizing, Going, Interested, and Maybe, activity-stream posts, and organizer notifications. If you run your community on BuddyPress or BuddyNext, events stop being a separate silo and become part of the same social graph your members already live in.

Built to extend, not to fork

This is the promise I care about most, and it is a technical guarantee, not a marketing line: Pro is not privileged. It is built on the same public extension points your own add-on gets.

That is possible because the architecture is contract-based and self-registering. You drop a single provider file to add a service, a single controller file to add an endpoint, a block folder to add a block, and the plugin discovers it on boot. You never edit a shared file, so two people can build two features on two branches and never collide. On top of that sits a surface of more than a hundred hooks, where every write fires an abortable before-filter and a post-commit after-action.

Practically, that surface is what lets you build without touching the core:

What you want to doWhat the tech gives you
Sync events or RSVPs to a CRM, warehouse, or webhookAfter-action hooks on every create and update
Add your own payment processorA gateway interface plus the same money-path hooks Pro’s Stripe and PayPal use
Send SMS, push, or Slack alertsA notification-channel interface the notifier fans out to
Attach custom data to any event, RSVP, ticket, or orderA Meta API, with a filter to surface it on the REST response
Enforce your own rules (no past events, approval queues)Abortable before-filters that can reject a write
Import from a system nobody has heard ofAn extensible importer registry, same seam the built-in importers use
Ship your own block or your own endpointAuto-discovery, the shared store, and the canonical response envelope

The point of the table is not the individual rows. It is that the entire commercial layer, everything Pro does, was built through these exact seams, which means anything Pro does, you could do too. Pro is the largest worked example of building on Eventonomy.

Why it holds at scale

Scale is not a marketing word here, it is a set of specific engineering choices. The columns behind every list view, the event status, the space link, the start time, are real indexes, so a filtered feed is an index range scan, not a full-table crawl. Calendar reads page by cursor rather than offset, so page five hundred costs the same as page one.

Writes that contend are handled honestly: RSVP capacity is claimed atomically, so an event cannot oversell under a burst of simultaneous sign-ups, and attendee exports are batched so a ten-thousand-person event does not exhaust memory. There are no per-row queries hiding inside loops. These are the things that separate a plugin that demos on five events from one that runs a real program on tens of thousands, and they are baked in rather than promised for a future release.

You own the data, and so do your members

Because everything is in your own database, no third-party platform holds your attendee list. The latest release makes that ownership work for privacy in both directions: Eventonomy plugs into WordPress’s built-in Export and Erase Personal Data tools, so a member’s access or deletion request covers Eventonomy’s own tables, anonymizing RSVPs while paid orders keep their financial record under the standard tax-retention rule.

It is translation-ready with six bundled languages and RTL support, every list exports to injection-safe CSV, and there is a wp eventonomy command group so you can script setup, seed a realistic test dataset, and run the same operations from CI that the API exposes.

A stability promise that makes it safe to build on

None of this matters if it breaks every release, so a defined surface is stable across major versions without a deprecation cycle: the hooks, the contract interfaces, the eventonomy/v1 routes and their envelope, the Interactivity store, the template override paths, the Meta API, and the CLI group.

What you must not lean on is equally explicit: concrete internal classes and the raw column layout. Build against the documented contracts and your integration survives upgrades. That line between stable surface and private internals is what turns a plugin into something you can responsibly ship a business on.

What you get free, and where Pro fits

Everything above is in the free plugin. The free platform is the whole data engine, the full eventonomy/v1 API, frontend event submission and a member dashboard, RSVPs with waitlists and account-less magic links, recurring events, free and donation tickets with a server-generated PDF receipt, ICS feeds, the migrator, and every extension point on this page. You can build a serious events system on it without paying for anything.

Eventonomy Pro is the commercial layer, built entirely on those same seams. It adds paid ticketing through Stripe, PayPal, Square, Mollie, and WooCommerce, coupons and tiered pricing and tax handling, refunds, week and day hour-grid calendars, advanced recurrence, maps and geocoding, scheduled reminders and SMS, custom email templates, a discovery feed with follow and saved events, organizer analytics and reports and payouts, door check-in, conversion tracking, and the full BuddyPress integration. For a technical evaluator, the useful framing is this: Pro is not a set of locked features, it is a reference implementation of what the platform can carry.

Why I built it this way

A decade of shipping WordPress plugins taught me the same lesson every time: the ones people build businesses on are the ones that stayed open and stayed fast. Eventonomy is events done as a platform, and the extension surface is as much the product as the interface is.

If you want the whole picture of what I have been assembling, I wrote about the complete WordPress platform behind it. Eventonomy is built and maintained by the team at Wbcom Designs, and the full technical reference ships inside the plugin. Build something on it and tell me what you made.