Oats Africa Event Data Migrator

Oats Africa Event Data Migrator connects your WordPress site to another self-hosted WordPress site — a source site you already control — and pulls its event data across so it can be handed off, in a consistent shape, to an external API of your choosing.

It’s built for the common case where the events “live” on one WordPress install (running The Events Calendar, or plain WooCommerce as a fallback), but a separate system needs a normalized feed of that data: another app, an internal dashboard, a data warehouse, anything that can accept a JSON POST.

How it works

1. Connect. From this plugin’s settings screen, point it at your source site’s URL and a WordPress Application Password for a user on that site. The plugin never sees or stores your real account password — Application Passwords are separate, revocable credentials WordPress core generates for exactly this purpose.
2. Detect. The plugin checks whether the source site is running The Events Calendar and has events in it. If so, it uses TEC’s own event, ticket, and attendee data. If not — or if TEC isn’t installed — it falls back to treating WooCommerce products as events. You can also force either source manually if auto-detection picks the wrong one for your setup.
3. Import. On demand (there is no automatic background schedule), the plugin fetches everything the detected source has, normalizes it into one consistent format regardless of which source it came from, and hands the whole batch to your configured external API in a single request.
4. Send. Until you’ve entered a destination endpoint URL and API key in this plugin’s settings, imports run in “dry run” mode: nothing is sent anywhere, and the payload that would have been sent is saved locally for 24 hours so you can inspect it. Once you configure a real endpoint, imports POST there automatically — no other setup required.

What gets imported

From a The Events Calendar source: event details (title, description, dates, venue, organizer, cost, categories) in every status visible on your wp-admin Events screen — Published, Draft, Pending Review, Private, and Scheduled (everything except Trash) — along with each event’s own status, so an import can be reconciled directly against wp-admin instead of only ever importing what’s already public; ticket types and prices; and attendee records (name, email, and any custom fields the site’s ticket form collects, such as phone number).

Every attendee is also matched up with the order behind their ticket, in the same spirit as the events-status handling above — a complete picture, not just the paid half of it. A ticket bought through WooCommerce is matched to its real WooCommerce order (status, total, currency, billing name/email/phone), covering every order status visible on the source site’s WooCommerce → Orders screen (Pending, Processing, On hold, Completed, Cancelled, Refunded, Failed — everything except Trash), not only completed ones. A free RSVP — which has no checkout step and so no real WooCommerce order to find — instead gets an order built automatically by this plugin: cost 0, an order id this plugin generates (so it can never collide with a real WooCommerce order number), and a source field of rsvp (versus woo for a real order) so the two are easy to tell apart downstream. Because a free RSVP has no separate “billing” step the way a WooCommerce checkout does, its generated order’s first_name field carries the attendee’s whole display name rather than a properly split first name, with last_name left empty.

From a WooCommerce fallback source: product details treated as events (best-effort field guessing, since WooCommerce has no built-in “event” concept), and the orders placed against each product, in the same tickets/attendees shape a The Events Calendar import uses. On a site where The Events Calendar and Event Tickets Plus are also active, some “products” are really just ticket SKUs for a TEC event rather than real products — these are still included rather than silently dropped, but with their event-shaped fields (title, dates, venue) left empty since a ticket product genuinely doesn’t carry that information; the ticket’s own name and price appear correctly in its tickets entry instead, and its buyers still populate attendees.

An optional “skip details” mode is available for faster imports that fetch just the top-level event/product list, without the extra ticket, attendee, or order data.

The admin screen’s per-event breakdown and Last Import summary are built to make an import checkable at a glance rather than something you have to take on faith: a Status column on every event, a running total of orders fetched from WooCommerce versus how many are actually linked to an event (split further into paid vs. RSVP-generated), and explicit warnings whenever a fetch fails partway through or a paid order can’t be matched — instead of a partial result that silently looks the same as a complete one.

Requirements

• A source WordPress site you have admin access to, reachable over HTTPS, with either The Events Calendar or WooCommerce active.
• An external API endpoint that accepts a JSON POST and a bearer token — this plugin does not include or host that API itself.

Privacy

This plugin moves data between two systems you control the configuration of: a source WordPress site, and an external API. Please read this section before activating it on a live site.

What is retrieved from the source site: event details, and — unless you enable “skip details” — ticket, attendee, or order records. Attendee and order records can contain real personal data: names, email addresses, and any custom fields a ticket form asks for (for example, a phone number). Not every order record is retrieved from the source site as-is — a free RSVP attendee has no real WooCommerce order behind it, so this plugin generates a zero-cost stand-in order for them (see the FAQ above) using the attendee’s own name/email; it is otherwise treated the same as any other order record for privacy purposes. This data is retrieved using the WordPress Application Password you provide, which is scoped to whatever that WordPress user account is permitted to see on the source site.

What is sent to the external API: the same normalized data, in a single batch, whenever you click “Import Now” and a destination endpoint is configured. There is no background or scheduled sending — every send is a result of an explicit admin action.

What is stored locally, on the site this plugin is installed on:
* The source site connection details (site URL, username, and an encrypted Application Password).
* The external API destination (endpoint URL and an encrypted API key).
* A record of the most recent import (timestamp, counts, success/failure) for the admin screen’s status display.
* If no API destination is configured yet, the most recent import’s full normalized payload — including any personal data it contains — saved as a temporary WordPress transient that expires automatically after 24 hours. This exists purely so you can inspect what an import produces before wiring up a real destination.

What this plugin does not do: it does not send data to Oats Africa, to any Oats Africa service, or to any third party other than the exact API endpoint you configure yourself. It does not phone home, collect telemetry, or make any outbound request other than to the source site you connect and the API endpoint you set.

Because personal data can pass through this plugin, treat both the source site’s Application Password and the destination API key with the same care as any other credential, and make sure the destination API itself handles the data you send it appropriately (encryption at rest, access controls, and a retention policy) — this plugin’s job ends once the data leaves your server.

Uninstalling the plugin deletes all of the above from your database, including the encrypted credentials and any pending dry-run payload.