Events API Issues

Watch this video first: https://a.cl.ly/5zu65npl

After extensive testing of the Events API, we've identified two backend issues that are preventing imported (member-submitted) events from functioning correctly. These are API limitations rather than problems with the importer—we've verified both issues using VAIR's own "New Event" form and by inspecting the API responses.

1. Registration fees are being discarded

When creating an event, the API accepts a registrationFee value without any validation errors. For example, submitting:

"registrationFee": 115

returns a successful 201 Created response.

However, that fee is never returned by any read endpoint.

We verified this by checking:

• GET /api/v1/events/{id}
• POST /api/v1/events/search
• GET /events/{uuid}
• GET /events/2944
• /signup-status
• /roster
• /divisions

We also searched every returned field and every scalar value—including the literal value 115—and confirmed that it does not exist anywhere in the stored event data. There are no fields named registrationFee, fee, price, cost, amount, payment, or anything similar. (/registration-options and /brackets both return 404.)

To confirm this wasn't an issue with our importer, we created an event using VAIR's own New Event form with a $100 registration fee. The result was identical:

• the event displayed "Registration: Free"
• the API response contained no registration fee

This strongly suggests the API accepts the value during creation but does not persist it.

Suggested fix

Store the registrationFee value and return it from:

• GET /api/v1/events/{id}
• POST /api/v1/events/search

so the frontend can display the correct registration fee.

2. Member-submitted events are not geocoded

The create endpoint currently accepts only a single free-text location string.

If we submit structured location data—including fields such as:

• city
• state
• zip code
• country
• latitude
• longitude

the request is rejected with validation errors stating that those properties are not allowed.

After the event is created, the API returns empty values for city, state, and zipCode, even though the full address was provided in the location string.

Because of this, imported events cannot be found using the site's location search or autocomplete filters. The address displays correctly, but the structured location fields remain empty, making the events undiscoverable through location-based search.

Again, this is not specific to our importer.

We created an event using VAIR's own New Event form and selected the address through the Google Places autocomplete. The form still submitted only a location string, and the resulting event also had empty city, state, and zipCode values.

To better understand the API, we also tested every structured address field we could think of. In a single request we submitted 37 possible field names, including:

• streetAddress
• addressLine1 / addressLine2
• address1 / address2
• street
• city
• state
• province
• region
• zipCode
• postalCode
• country
• latitude
• longitude
• placeId
• googlePlaceId
• venue
• venueName
• locationName

Every one of them was rejected by the whitelist validator ("property ... should not exist").

This confirms that the create endpoint currently accepts exactly one location input: the free-text location string.

Suggested fixes

Any one of the following would solve the issue:

1. Geocode the location string server-side and populate city, state, zip code, latitude, and longitude.
2. Allow the create endpoint to accept structured location fields (city, state, zipCode, latitude, longitude).
3. Accept a Google Place ID (or latitude/longitude) and resolve the location server-side.

Our importer already has accurate venue names, street addresses, city, state, ZIP code, and coordinates for most events, so either option 2 or 3 would require only a very small change on our side once those fields are accepted.

API endpoints involved

EndpointNotesPOST /api/v1/eventsCreates events. Strict schema; only accepts a free-text location field.POST /api/v1/events/{id}/logoUploads the event banner.GET /api/v1/events/{id}Returns event details but omits the registration fee and leaves city/state/zip empty for member-created events.POST /api/v1/events/searchReturns event listings but also omits the registration fee.DELETE /api/v1/events/{id}Successfully deletes events.

Everything else in the importer is working correctly, including banner uploads, duplicate detection, country/province handling, and importing complete street addresses.

At this point, these two API limitations are the only remaining blockers for fully functional imported events and will require backend changes on the VAIR side.