This update relates to advanced, technical users; integrations to Elevent via the Elevent API.
We've made 2 helpful changes to the Elevent API used when integrating other systems to Elevent.
Reserved Seating Tickets are Grouped Together
Before, each individual reserved seat--its row and section--were broken out into individual items purchased in the responses from the Elevent API. This provided fine-tuned detail, but it meant the way ticket sales data on a customer was returned for reserved seats was structured differently from general admission shows.
For instance, before this change, when calling Get Customer by ID
api.goelevent.com/Customer
You'd get something like this, where each reserved seat ticket in an order stood alone.
"Tickets": [ { "TicketId": "vGaFF6JLfu", "TicketName": "Reserved Seat - Adult", "Row": "Z", "Seat": "107", ... }, { "TicketId": "vGaFF6JLfu", "TicketName": "Reserved Seat - Adult", "Row": "Z", "Seat": "104", ... },
Now, in a single chunk, all tickets of the same type in an order with reserved seats will display like this:
"Tickets": [ { "TicketId": "vGaFF6JLfu", "TicketName": "Reserved Seat - Adult", "Row": "Z", "Seat": "Z107,Z104,Z111,Z106,Z105,Z109,Z108,Z110,Z102,Z101,Z103", ... },
Making it consistent with general admission tickets makes it easier to integrate and accurately show ticket sales numbers for organizers who sell both general admission and reserved seating tickets. If you saw odd numbers in Salesforce while using the Elevent for Salesforce app, this change resolves that issue.
You might notice the row reappears with each seat. That's by design--since it's possible to sell tickets across multiple rows, this clarifies exactly where each seat truly is.
LastModifiedDateTime Now Reflects a More Useful Time Stamp
The LastModifiedDateTime on API responses is a useful timestamp for integrations to identify the most recent time period from previous requests--so changes could only be applied since the last request.
Before this change, the LastModifiedDateTime would show the most recent date and time the customer made any purchase or had customer activity--like updating their account, a refund, etc. In most cases, this is perfect.
However, there are times when we might force an update to a customer to trigger an update in a third-party system, like a CRM. The LastUpdatedDateTime stamps will now update when that activity occurs. In this way, any integrated systems will see they should examine and update any returned data since it might be newer.
Looking for API documentation? Check it out here.