Accounting » History of Sent Data

History of Sent Data

Introduction

The SyncRecords exposed by the SyncHistory resource provide information about the times when Accounting data has been attempted to be sent to a third-party integration partner, and the success or failure of those attempts.

The SyncHistory endpoint uses the OData standard with HATEOAS-style navigation links to expose SyncRecord data and allow querying of the specific information that is needed.

While it is possible to pull all of the information contained within a SyncRecord at once, we recommend that you only retrieve the specific information that you need in order to ensure efficiency and scalability for your application.

Note that the server will always order SyncRecords from most recent to least, and this is not overridable.

How It Works

Check out the resource specification here.

Currently, only users with the role of MINDBODY Owner, MINDBODY Admin, or MINDBODY Automated System have permission to access this resource.

How To Use It

  • Scoping

    Every request to the SyncHistory endpoint must be scoped; a URL convention is used to specify the request scope. Currently the only supported scope type is subscriber, so every request must include the subscriber id. Requests should look like:
    https://subscriber.mindbodyonline.com/odata/v4/Subscriber_{subscriberId}/SyncHistory, where {subscriberId} is the supplied subscriber id.

  • odata.metadata=full

    You can use the $format parameter to specify the verbosity of the output; supplying "odata.metadata=full" will ensure all possible OData links are returned in the payload.

    For example, the following request:
    https://subscriber.mindbodyonline.com/odata/v4/Subscriber_{subscriberId}/SyncHistory?$format=application/json;odata.metadata=full
    will return a payload that looks like the following: 

    {
    "@odata.context":"https://subscriber.mindbodyonline.com/odata/v4/Subscriber_{subscriberId}/$metadata#SyncHistory",
    "@odata.count":300,
    "value":[
        {
            "@odata.type":"#subscriber.mindbodyonline.com.SyncRecord",
            "@odata.id":"https://subscriber.mindbodyonline.com/odata/v4/Subscriber_{subscriberId}/SyncHistory('{recordId}')",
            "@odata.editLink":"https://subscriber.mindbodyonline.com/odata/v4/Subscriber_{subscriberId}/SyncHistory('{recordId}')",
            "Id":"{recordId}",
            "[email protected]":"#Collection(subscriber.mindbodyonline.com.SyncState)",
            "States":[
                {
                    "@odata.type":"#subscriber.mindbodyonline.com.SyncState",
                    "[email protected]":"#Mindbody.Api.Subscriber.Areas.Accounting.Models.ESyncStatus",
                    "Status":"{status}",
                    "StatusReason":"{reason}",
                    "[email protected]":"#DateTimeOffset",
                    "SyncTime":"{syncTime}"
                },
                ...
            ],
            "UserId":"{userId}",
            "[email protected]":"#Mindbody.Api.Subscriber.Areas.Accounting.Models.EAccountingIntegrationType",
            "IntegrationType":"{integrationType}",
            "IntegrationId":"{integrationId}",
            "[email protected]":"https://subscriber.mindbodyonline.com/odata/v4/Subscriber_{subscriberId}/SyncHistory('{recordId}')/Packets/$ref",
            "[email protected]":"https://subscriber.mindbodyonline.com/odata/v4/Subscriber_{subscriberId}/SyncHistory('{recordId}')/Packets",
        },
        ...
    ],
    "@odata.nextLink":"https://subscriber.mindbodyonline.com/odata/v4/Subscriber_{subscriberId}/SyncHistory?$format=application/json;odata.metadata=full&$skip=50&$top=50"
}

  • Paging

    Paging is crucial when using the SyncHistory endpoint, because there is potentially a lot of retrievable data. The server enforces a max page size of 100, and we recommend a page size of 50.

    Note, in the example above (under odata.metadata=full), the $skip and $top parameters specified in the nextLink. In the event that there are more SyncRecords than the $top specified in the original request (or 50, if no $top was specified) - which is the case in the example, since the total count of SyncRecords is 300 - a nextLink is provided with $skip and $top parameters that will provide you with the next page of results. Upon submitting a request to the nextLink URL, you would receive a payload that looks like the following: 

    {
    "@odata.context":"https://subscriber.mindbodyonline.com/odata/v4/Subscriber_{subscriberId}/$metadata#SyncHistory",
    "@odata.count":300,
    "value":[
        ...
    ],
    "@odata.nextLink":"https://subscriber.mindbodyonline.com/odata/v4/Subscriber_{subscriberId}/SyncHistory?&$skip=100&$top=50"
}
    And you could continue navigating the provided nextLinks until you have retrieved all 300 SyncRecords.

  • Fetching Contained Resources

    SyncRecords on their own (without expanding their contained Packets) give a high-level view of when data has been attempted to be sent and whether or not it did in fact send successfully. When you need more granular information, such as which specific Packets of data failed in an overall failed sync attempt, you'll need to expand out that information. It is recommended you do so using the $expand parameter, as there are several layers of information on a SyncRecord and multi-level navigation using URL navigation is not supported. Thus, expanding Packets would look like:
    https://subscriber.mindbodyonline.com/odata/v4/Subscriber_{subscriberId}/SyncHistory?$expand=Packets

    If you need to take it even further than the Packets, you can begin nesting the expand values. So, for example, a request to retrieve the raw OrderReferences contained in each Packet would look like:
    https://subscriber.mindbodyonline.com/odata/v4/Subscriber_{subscriberId}/SyncHistory?$expand=Packets($expand=MindbodyInfo($expand=OrderReferences))

Helpful Links