Uptick API

Article author
Jarek Glowacki
  • Updated

Welcome to the Uptick API!

 

Versioning

Our versioning is implemented across the board, rather than on a per-endpoint basis. Access is via <customer>.onuptick.com/api/v<version>/<endpoint>/.

Scheme

The versioning scheme is as follows (note that this is NOT semver):

  • MAJOR: Corresponds to spec being implemented.
  • MINOR: Corresponds to a backwards-incompatible change that's been made.
  • PATCH: Corresponds to minor, backwards-compatible, tweaks.

We currently offer one MAJOR version, v2, which implements REST, extended with the JsonAPI spec.

When the MINOR version is not specified (eg. /api/v2/<endpoint>/), the latest MINOR version will be defaulted to for the given MAJOR version. Similarly, when the PATCH version is not specificed, the latest PATCH for the given MINOR.MAJOR combination is used.

Deprecation Cycle

There is no explicit lifetime for each MINOR version, but roughly ~3 minor versions should be expected to coexist simultaneously, so when you see a new one introduced, expect the oldest one to be on its way out.

You can review version info at /api/version/ You'll see the keys `latest`, `deprecated`, `imminent_removal` and `removed` there, which should let you know well ahead of time whether you need to start updating.

 

Endpoints

Our endpoints are self-descriptive; they are their own documentation. If you view our API from your browser, you'll see it render in a human-readable way.

Navigate to /api/v2.6/ to see a list of endpoints. Follow any of these to see available fields. Every endpoint also offers an OPTIONS method, which lists additional metadata for each field.

 

Recommendations

Here are a few tips to ensure you get the best out of our API:

  • Always specify the MINOR version in your calls, to avoid surprises when things change. eg. /api/v2.x/<endpoint>/. We also send out email updates when adding/removing MINOR versions. Please get in contact with us if you would like to be included on this mailing list.
  • Prefetch data. You can use ?include=<fieldname of relationship> to pull through related table data. Can even dig through multiple levels, eg. /api/v2.x/tasks/?include=property.tags
  • Take advantage of sparsefields. By default, endpoints return all available fields. You can use the ?fields[<ResourceType>] query to request only the specific fields you need. eg. /api/v2.x/properties/?fields[Property]=name,ref,created. These work on included data as well. eg. /api/v2.x/properties/?include=client&fields[Property]=ref&fields[Client]=name
  • Paginate. Use page[limit] and page[offset] to chunk the data you pull out. eg. /api/v2.x/clients/?page[limit]=50&page[offset]=100.
  • Filter results. Most fields can be filtered on. There's also a special updatedsince filter, which you should be using when you're fetching lists of data for syncing purposes. eg. /api/v2.x/tasksessions/?updatedsince=2019-10-28T19:53:25.906000Z.
  • Minimise the number of API calls you make. With the above points, you should be able to efficiently collect exactly the data you need with minimal calls to the API. Everybody wins.

 

Patch notes

v2

v2.6 (Added Feb 18, 2021)
  • Added a `building_classes` choice field to the `Property` resource. This replaces the `building_class` and `building_type` fields, which will be remain accessible until v2.5 is dropped.
  • Added `bsecure_resolved_guid` (actual guid) and `bsecure_latest_sticker_guid` (guid of most recently attached sticker; gets mapped to actual guid) fields to the `Property` and `Asset` resources, to be used in place of `bsecure_guid` and `bsecure_real_guid` fields. If you've been using these old fields, you'll want to apply the following mapping. For the `Property` resource `bsecure_guid` is the same as `bsecure_resolved_guid`; for the `Asset` resource, `bsecure_guid` is the same as `bsecure_latest_sticker_guid` and `bsecure_real_guid` is the same as `bsecure_resolved_guid`. The old fields will remain accessible via both old and new API versions until support for v2.5 is dropped.
  • Removed `property` relationship from `ServiceTask` resource. No longer accessible via previous API versions either, as it was never used.
  • `/api/v2.x/pushnotificationtokens/register/` now requires `platform` to be provided. Must be one of `APNS|GCM`.
  • A `quantity` of 0 passed to the `/api/v2.x/servicetasks/` endpoint will now remain as 0, rather than getting automatically converted to 1.
  • Renamed `/api/v2.x/form-responses/` to `/api/v2.x/dynamicformresponses/`. Both endpoints will remain accessible via both old and new API versions until support for v2.5 is dropped.
  • Renamed `/api/v2.x/dynamicform_templates/` to `/api/v2.x/dynamicformtemplates/`. Both endpoints will remain accessible via both old and new API versions until support for v2.5 is dropped.
v2.5 (Added Jul 16, 2020)
  • Asset.floorplan_locations has now become Asset.floorplan_location, as the relationship is now one-to-one. Both usages will remain accessible until support for v2.4 is dropped.
v2.4 (Added May 21, 2020)
  • The following resources have been renamed:
    • InspectionItem -> Asset
    • InspectionItemType -> AssetType 
    • InspectionItemTag -> AssetTag 
    • InspectionItemTypeTag -> AssetTypeTag 
    • InspectionItemTypeVariant -> AssetTypeVariant
  • Renamed all occurences of fields named inspectionitem and inspection_item with asset. This change spans multiple endpoints, and affects the following resources: Asset, AssetType, AssetTag, AssetTypeTag, AssetTypeVariant, PlanLocation, Remark, SuggestedProduct, DefectQuoteLineItem, SignoffItem, ServiceTask, AssetPreset, RemarkType, RoutineServiceType, ServiceRecord, Rectification.
  • Changed Task.status from a CharField to a ForeignKey relationship on resource TaskStatus. What was previously stored in Task.status can now be found under Task.status.id. Affects all endpoints that reference the Task resource.
  • Added endpoint /api/v2.x/taskstatuses/, for viewing TaskStatus resources.
  • All datetimes are now returned in the timezone of the user performing the request. For example, 2020-01-20T00:32:06.912780Z, for a user with a Melbourne timezone, will now return as 2020-01-20T11:32:06.912780+11:00. Clients must ensure they understand the +XX:XX timezone offset suffix, rather than just the Z UTC suffix, or always assuming UTC.
v2.3 (Added Jan 16, 2020)
  • Renamed a number of endpoints. Both endpoint names will remain accessible via both old and new API versions until support for v2.2 is dropped.
    • /api/v2.x/property-tags/ -> /api/v2.x/propertytags/.
    • /api/v2.x/timeline-events/ -> /api/v2.x/timelineevents/.
    • /api/v2.x/extra-fields/ -> /api/v2.x/extrafields/.
    • /api/v2.x/display-conditions/ -> /api/v2.x/displayconditions/.
    • /api/v2.x/dispatch/ -> /api/v2.x/dispatches/.
  • Added endpoint /api/v2.x/assettags/, for parity with the same endpoint in the v1 api.
  • Filter content_type_id on /api/v2.x/timelineevents/ has been renamed to content_type. Both filter names will remain usable until support for v2.2 is dropped.
  • Removed is_performed bool field from ServiceTask resource. Use performed_date datetime field instead.
  • Removed is_quotable bool field from ServiceTask resource. Concept of "Quotable" ServiceTasks has been replaced with a new "SuggestedProducts" resource.
  • Added /api/v2.x/suggestedproducts/ endpoint, for interfacing with SuggestedProducts.
  • Tasks with new status type CANCELLED are now visible through the /api/v2.x/tasks/ endpoint.
v2.2 (Pending removal Mar 18, 2021)
  • Renamed /api/v2.x/task-sessions/ to /api/v2.x/tasksessions/. Both endpoints will remain accessible via both old and new API versions until support for v2.1 is dropped.
  • Changed TaskSession.type from a CharField to a ForeignKey on model TaskSessionType. What was previously stored in TaskSession.type can now be found under TaskSessionType.key. This affects both the TaskSession endpoints /api/v2.x/task-sessions/ and /api/v2.x/tasksessions/, as well as the /api/v2.x/payroll/endpoint.
  • Added new endpoint /api/v2.x/tasksessiontypes/, for accessing and manipulating TaskSessionTypes.
v2.1 (Removed Jun 18, 2020)
  • Renamed Remark.failure to Remark.type. Notes:
    • This is only a field name change. The resource behind the ForeignKey was already called RemarkType and remains this way.
    • This change affects not only the remarks endpoint, but all other endpoints that were pulling remarks through via the include query param.
  • Renamed /api/v2/remark-types/ endpoint to /api/v2/remarktypes/. Both endpoints will remain accessible via both old and new API versions until support for v2.0 is dropped.
v2.0 (Removed Feb 6, 2020)
  • Initial release

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.