Mobile App

Eventonomy 1.3.0 adds the backend that a companion mobile app talks to - a configuration endpoint the app reads on connect, a member profile route, an in-app notification feed, push device registration, and the data sources an app needs for a My Events screen.

Important - the app itself is a separate product and is not included in the plugin. Updating Eventonomy does not install an app on anyone's phone, and there is nothing to download from your WordPress dashboard. What this release gives you is the site-side half of the connection: the settings that brand the app, the API it reads, and (with Pro) the push delivery that reaches it. The app is provided separately.

What You Will Learn

What the plugin provides and what it does not
How to enable and brand the app experience from the Mobile App settings tab
Which parts need Eventonomy Pro and a valid license
The two legal links you must set before you launch, because both ship empty
How a member signs in, and why your site has to be on HTTPS
What members get once an app is connected - notifications, My Events, account deletion, and event reporting
What to check when the app will not connect

What the Plugin Provides

Capability	Free	Pro
Mobile App settings tab (enable, branding, minimum version)	Yes	Yes
App configuration endpoint the app reads on connect	Yes	Yes
Member profile data for the app's account screen	Yes	Yes
In-app notification feed (the bell) with unread count	Yes	Yes
Registering a member's device for push	Yes	Yes
Sending native push notifications to those devices	No	Yes
The app being allowed to connect at all (`Enable the mobile app`)	No	Yes, with a valid license
My Events data source for the app's "my registrations" screen	Yes	Yes
Viewer-relative RSVP state on a single event	Yes	Yes
Self-serve account deletion and event reporting	Yes	Yes

Enabling and Branding the App

Go to Eventonomy → Settings → Mobile App. Everything on this tab lives in one Mobile app card.

Setting	Default	Description
Enable the mobile app	On	Lets the app connect to this site. Members still need Eventonomy Pro with a valid license on the site.
App name	Site title	The name shown inside the app. Leave blank to use your site title.
Accent color	`#4d7c0f`	A hex color that white-labels the whole app palette. Leave blank for the default.
Logo URL	Site icon	Displayed on the connect / sign-in screen. Leave blank to use your site icon.
Sign-in background URL	Empty	An optional background image for the sign-in screen.
Terms URL	Empty	A link to your terms of service. The privacy policy link uses the privacy page configured in WordPress.
Minimum app version	`1.0.0`	App versions older than this are prompted to update before they can connect.
Enable push notifications	On	Tells the app that push is available, so it registers the member's device.

These settings are read once when the app connects, so a branding change reaches members the next time their app fetches its configuration.

Pro and Licensing

Pro - the mobile app is a licensed Pro benefit.

Enable the mobile app is only half the gate. The app is reported as available to connect when all three of these are true:

Eventonomy Pro is active on the site.
Enable the mobile app is switched on.
Your Pro license is valid.

The check is fail-closed: if the license lapses, the app is refused at connect time even though the setting is still switched on. Keep your license active in Eventonomy → Settings if you want members to keep using the app. See Licensing.

Set Your Legal Links Before You Launch

Do this before you tell anyone the app is live. Both legal links ship empty, and one of them stays empty even on a site that looks correctly configured.

The app asks your site for two legal links on connect, and shows whatever it is given. If a link is missing, members see no link at all.

Terms of service. Enter it yourself in Eventonomy → Settings → Mobile App → Terms URL. There is no default and no fallback, so if you leave it blank no terms link is sent.

Privacy policy. This one is never entered on the Mobile App tab. It always comes from the page you set under Settings → Privacy in WordPress - and this is where sites get caught out. WordPress creates a privacy policy page for you automatically, but it creates it as a draft. A draft page has no public address, so your site hands the app a blank privacy link even though the Privacy screen shows a page selected.

To make the privacy link real:

Go to Settings → Privacy in WordPress.
Open the selected policy page, write your policy, and publish it. Selecting it is not enough - it must be published.
Confirm the page opens for a logged-out visitor.

App stores generally expect both links to be present and working before they will approve a build, so treat this as part of launching rather than as a nicety.

How Members Connect

A member signs in from the app with their WordPress username and an application password - a per-device credential WordPress itself generates. It is not their normal login password, and revoking it stops that one device without changing anything else about their account.

For a member, the flow is:

Sign in to your site in a browser and open Users → Profile.
Scroll to Application Passwords, type a name for the device, for example "Phone", and create it.
Copy the generated password and enter it in the app together with the username.

There is nothing to configure in Eventonomy for this - it is standard WordPress, and any member who can log in can do it.

Your site must be served over HTTPS. WordPress hides the Application Passwords section entirely on a site it does not consider secure, so on a plain HTTP site there is no credential to create and the app cannot sign in at all. This is WordPress's own rule, not an Eventonomy setting, and no plugin option can relax it. If you do not see the Application Passwords section on a profile, check your certificate and your site address before looking anywhere else.

If a member loses a phone, revoke that device's application password from their profile. The rest of their devices are unaffected.

A note for anyone testing on a local site. The HTTPS rule has one exception, and it explains why a local install appears to work when a staging site does not: WordPress also allows application passwords when the site's environment type is local. So http://yoursite.local can sign in over plain HTTP, while http://staging.yoursite.com cannot. If the app connects on your machine but not on a real server, this is almost always why - the answer is a certificate, not an app setting.

Browser Builds and CORS

You only need this section if you run the app as a web build (Expo web, or a preview served from a tunnel). Native iOS and Android builds are not subject to CORS at all, so if that is all you ship, skip ahead.

There is nothing to allowlist, and nothing in Eventonomy to configure. The cross-origin headers come from WordPress itself, not from this plugin. A browser build calling your REST API gets back:

Header	Value WordPress sends
`Access-Control-Allow-Origin`	your request's own origin, reflected back
`Access-Control-Allow-Credentials`	`true`
`Access-Control-Allow-Headers`	includes `Authorization`, which is what the app signs in with
`Access-Control-Allow-Methods`	`OPTIONS, GET, POST, PUT, PATCH, DELETE`

The browser's preflight (OPTIONS) is answered directly by WordPress and succeeds. Because the origin is reflected rather than fixed to a list, a dev server on any port works without being registered anywhere.

So when CORS does break, it is nearly always something in front of WordPress, not WordPress. In order of likelihood:

A CDN, proxy or firewall stripping or rewriting the headers. Compare the headers your app receives against the table above; if Access-Control-Allow-Origin is missing or set to a fixed domain, that layer is rewriting it.
A security plugin that "hardens" the REST API and removes CORS headers or blocks OPTIONS.
A tunnel that terminates TLS and forwards a different host, so WordPress builds URLs for the wrong origin. Set WP_HOME/WP_SITEURL to the tunnel address while testing.
A hosting rule answering OPTIONS before PHP runs, which returns a preflight without any CORS headers.

If you need to change the behaviour deliberately - to restrict origins rather than reflect them - that is WordPress's rest_allowed_cors_headers and the rest_pre_serve_request hook, and it applies to your whole site, not to Eventonomy alone.

Push Notifications

Push has two halves, and they sit on different sides of the Free/Pro line.

Registering a device is Free. When a member signs in on the app, the app hands their device token to the site and Eventonomy stores it against their account. Signing out or uninstalling removes it again. This works on the Free plugin.

Sending the push is Pro. Pro adds a push delivery channel that hooks into the same notification pipeline that already sends your emails. That means every notification Eventonomy already produces - RSVP confirmations, reminders, waitlist promotions, order confirmations - also arrives as a native push on the member's registered devices, with no per-notification setup on your side.

Without Pro, devices are still registered but nothing is ever pushed to them. A member only receives push on the devices they have actually signed in on, so a member with no registered device simply falls back to email as before.

Turning Enable push notifications off stops the app from registering devices at all.

The In-App Notification Feed

Eventonomy now keeps a per-member notification feed - the bell inside the app - in its own database table. The table is created automatically when you update; there is nothing to configure.

Every notification the plugin sends to a logged-in member is also written to that member's feed, using the same wording as the matching email, so the two never drift apart. The app can read the feed, show an unread count, mark a single item read, or mark everything read.

Guests who RSVP without an account are not in the feed. They continue to receive email and their magic management link as before.

What Members Can Do From the App

See their own RSVP state on an event. A single event now reports back whether the signed-in member has RSVP'd, which RSVP it was, and whether they have already been checked in - so the app can show "You are going" without asking a second time. It also reports how many places are left when the event has a capacity.

Browse their registrations. A My Events data source returns the signed-in member's own RSVPs, split into upcoming and past, so the app can build a "my events" screen. It is always scoped to the member making the request - one member can never read another member's registrations through it.

Report an event. A member can flag an event for moderation with a reason (spam, inappropriate, scam, misinformation, or other) and an optional note. The report is recorded against the event and an email alert goes to your site admin address, so you can act on it. Reporting is limited to five reports per member per hour to prevent abuse. This exists because app stores require a way to report objectionable content.

Delete their own account. A member can delete their account from the app without contacting you. Their Eventonomy data is anonymized through the same privacy eraser WordPress uses for a personal-data erase request, and then the WordPress account is removed. Three guards apply: a member can only ever delete their own account, they must type their exact username to confirm, and an administrator cannot self-delete from the app - an admin has to use the site dashboard instead. This exists because app stores require in-app account deletion.

Check-in for Free Registrations

Previously only paid orders produced a scannable ticket. From 1.3.0 every RSVP - including free ones, and including waitlist entries so a promoted attendee is already covered - mints its own check-in token when it is created.

In practice this means a free community event can now be checked in at the door exactly like a paid one. The check-in token is never shown in any API response or export; only the door scanner resolves it. Door check-in itself remains a Pro feature - see Check-in Scanner.

Troubleshooting

What you see	What to check
The app says it cannot connect to this site	Work through the three-part gate in order: Eventonomy Pro is active, Enable the mobile app is on, and your Pro license is valid. All three must hold, and a lapsed license is the most common cause because nothing on the settings screen changes when it expires.
A member cannot sign in and sees no Application Passwords section on their profile	Your site is not being served over HTTPS. WordPress hides application passwords on an insecure site. Fix the certificate and site address; there is no plugin setting for this.
The app is missing the privacy or terms link	Neither is set. Publish the WordPress privacy page (a draft does not count) and fill in Terms URL on the Mobile App tab.
The app still shows your old logo, name or colour	Branding is read when the app fetches its configuration, not pushed to devices. It updates the next time that app asks the site for its configuration.
Members are not receiving push notifications	Push has two halves. Registering a device works in Free, but sending needs Eventonomy Pro. Also confirm Enable push notifications is on, and that the member has actually signed in on the device - a member with no registered device falls back to email.
The bell is empty for a guest who registered without an account	Expected. The feed is per member. Guests keep receiving email and their magic management link.
An older app build is refused	Minimum app version is set above that build. Lower it, or have the member update.
Someone is misusing the app	Block them from the WordPress user profile screen. A blocked member can still sign in and browse, but every action that writes data - creating events, registering, ordering - is refused.

What's Next?

Activate your Pro license so the app can connect and push notifications can be delivered.

Licensing →