It is recommended you read the documentation on the Sync Endpoint first.
If, after using the Sync endpoint, you utilize the History of Sent Data endpoint and determine that the Sync was not fully successful (some or all of the Packets were not successfully sent), you have the option of using the Resync endpoint to try the same Sync process again.
Take a SyncRecord returned from the History of Sent Data endpoint and send a POST request to the Resync endpoint. It will kick off a Sync process much the same way as the original Sync endpoint, with the exception that it will look up the data to send using the provided SyncRecord.
Note that, when the process looks up the SyncRecord and retrieves the associated SyncPackets, it is able to skip the transformation step and simply map the retrieved packets to the integrator model.
The Resync endpoint does NOT create a new SyncRecord to log its progress; instead, it adds new states to the existing SyncRecord. Thus, it has the potential to take a failed SyncRecord and update it to successful. Also note that if the SyncRecord had successfully completed to begin with, the Resync endpoint will merely confirm it and no further action will be taken.
Currently, only users with the role of MINDBODY Owner have permission to access the Resync 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}/Resync,
where {subscriberId} is the supplied subscriber id and {integrationType} is a value
from
EAccountingIntegrationType.