REST API and event meta

Events are exposed over the WordPress REST API, together with a defined set of meta.

Endpoints

They live under the standard WordPress REST namespace and behave like any other registered post type and taxonomy: the usual collection parameters, ordering and pagination apply.

Meta exposed on an event

Registered for REST:

The pom object exposes the event panel's own values, including the start and end datetimes, the date format, the place, the introductory text, the organizer, the button labels, the hashtag, the contact number, the additional links, the optional form fields and the available space. Its optional_form_fields property is an array of string field identifiers.

Reading events

GET /wp-json/wp/v2/event?per_page=20&orderby=date

To reproduce the site's own ordering and upcoming filter, query on the derived date values rather than the post date — see Event query recipes. The REST collection does not apply the plugin's upcoming filter for you.

Two date representations

event_start_date and event_end_date are normalized Y-m-d values, suitable for comparison and sorting. event_start_datetime and event_end_datetime are the editable values, suitable for display.

Consumers should read the datetimes for presentation and the dates for logic.

Attendee data over REST

attending_users is exposed. event_assistants — the map containing email addresses, telephones, comments and countries — is not registered for REST.

That is deliberate. Do not add it to a public REST response: it is personal data, including free-text comments that frequently contain health and accessibility information.

If an internal integration genuinely needs attendee data, build an authenticated endpoint of your own with an explicit capability check, and treat the payload as confidential. See Escaping, sanitization and capabilities.

The theme gate applies

The post type is only registered on the POM theme. On another theme the REST endpoints for events do not exist, and requests return a not-found response.

A consumer should handle that case rather than assuming the endpoint is permanent.

Writing over REST

Standard permission rules apply: writing requires an authenticated user with the capability to edit that content.

Two cautions specific to events:

• Writing the datetimes over REST does not recompute the derived event_start_date and event_end_date. Write both, or the event will display one thing and be queried as another.
• Writing pom replaces the object. Read it, modify the key you need, and write the whole object back.

Guarding a consumer

$response = wp_remote_get( $site . '/wp-json/wp/v2/event?per_page=10' );

if ( is_wp_error( $response ) || 200 !== wp_remote_retrieve_response_code( $response ) ) {
    return; // Events may not be registered on this site.
}