The Sync endpoint allows your app to kick off a data push of MINDBODY Orders to a third-party integrator.
Given the provided scope, a lookup is performed for a stored integration. If one is found and it passes validation, an asynchronous job to process the Sync event is queued up. When the Sync job is picked up, it looks into the scope's history of sent data for the timestamp of the last sync, and uses that timestamp to pull all Orders created or modified since the last sync.
Currently, only users with the role of MINDBODY Owner have permission to access the Sync endpoint.
URL conventions are used to specify the request scope. Every request must provide 2 scope parameters: the subscriber domain scope (Subscriber/Region/Custom) and the accounting integration type scope. Currently the only supported domain scope type is subscriber, so every request must include the subscriber id. All currently supported integration types are specified in EAccountingIntegrationType.
All requests should look like:
https://subscriber.mindbodyonline.com/Subscriber_{subscriberId}/AccountingIntegration/Type_{integrationType}/Sync,
where {subscriberId} is the supplied subscriber id and {integrationType} is a value
from
EAccountingIntegrationType.
Once the set of MINDBODY Orders that this Sync request will process has been determined based on the time of the last Sync, they undergo a transformation and mapping process before they can be sent to a third-party integrator.
First, the Orders are transformed into "Packets", which is an intermediate stage between Orders and whatever form the integrator data takes, and simply makes it easier to apply the mapping rules later. This transformation process takes the AccountingIntegration's SynchronizationPreferences into account, particularly whether or not to summarize the data in the transformation. If SummarizeData is false, a SyncPacket is created for every Order. Otherwise, the Orders are grouped by their date and the PaymentMethod(s) used, with the result that a packet is created for every active PaymentMethod every day (assuming a once-a-day Sync schedule). The RequestItems contained in each packet are then created by summarizing across the RevenueCategory and TaxRate of the OrderItems. Note that, when summarizing this way, it is possible for Orders to become split across multiple packets, if more than one PaymentMethod was used to pay for the Order.
Once we have the packets created, the mapping rules defined in the AccountingIntegration's Maps are then applied to the packets to achieve the resultant objects that the integrator expects.
Because the Sync request is evented out, you do not know its progress or final result in the context of the initial request. The asynchronous Sync job records its progress in SyncRecords, exposed through the History of Sent Data endpoint. If need be, your app can poll the most recent SyncRecord entry after the time of your Sync request to check its progress. If you poll, we recommend the interval be no less than 5 seconds, with an exponential backoff.
Note that the overall job will get a final ESyncStatus of "Success" simply if all of the sales data contained within the job was processed successfully, and not necessarily if it was all sent to the integrator successfully. To determine individual success/fail of each packet of data that was attempted to be sent, you need to examine the States on each SyncPacket.