• Introduction
• Procedure
• Example
• Restrictions

Introduction

Via the changes endpoints you are able to receive information on all changes that have been made to resources you received earlier. It is thus possible to keep a local copy of resources in sync with data in mite, without having to transfer the whole – and possibly very large – list again and again.

Changes can be gathered for time entries, customers, projects, and services.

Please note: Changes cannot be read by time trackers.

Procedure

When sending a GET-Request against /time_entries.jsonxml, /customers.jsonxml, /projects.jsonxml, or /services.jsonxml the mite.api returns a response header named »X-Changes-Link«. The contained URL returns all changes made to the resources since the first response to a GET-Request.

It will also include a new URL in the response header »X-Changes-Link«. It is thus possible to receive changes consecutively.

Example

The following example contains a project that has been updated in the meantime (»updated«), a newly created one (»created«), and a recently deleted one (»deleted«). In the first two cases the whole resource is returned within the attribute »record«:

GET /projects/changes/{token}.xml

GET /projects/changes/{token}.json

[
  {
    "change": {
      "record_type": "project",
      "action": "updated",
      "record_id": 1322027,
      "record": {
        "project": {...}
      }
    }
  },
  {
    "change": {
      "record_type": "project",
      "action": "created",
      "record_id": 1322030,
      "record": {
        "project": {...}
      }
    }
  },
  {
    "change": {
      "record_type": "project",
      "action": "deleted",
      "record_id": 1317020,
      "record": null
    }
  }
]

<?xml version="1.0"?>
<changes type="array">
   <change>
      <record-type>project</record-type>
      <record-id>1322027</record-id>
      <action>updated</action>
      <record>
         <project>...</project>
      </record>
   </change>
   <change>
      <record-type>project</record-type>
      <record-id>1322030</record-id>
      <action>created</action>
      <record>
         <project>...</project>
      </record>
   </change>
   <change>
      <record-type>project</record-type>
      <record-id>1317020</record-id>
      <action>deleted</action>
      <record/>
   </change>
</changes>

Restrictions

1. It is not possible to only retrieve changes that match a filter or other search criteria. The changes endpoints always return all changes. Hence it might be required to filter them locally.
2. Changes don't include resources whose subresources have changed. This applies to the customer_name of projects, and to the customer_name, project_name, and service_name of time entries. To keep these attributes in sync as well, you'll have to additionally receive the changes of the subresources.
3. Changes can only be received for seven days. Afterwards the mite.api will return an error.
4. The endpoints are designed to overdeliver in case of doubt. Cases where the client has already removed a deleted resource, or already knows about one that is marked as created, should be taken into account.