Working with MX Deposit data
MX Deposit is a cloud-based database for collecting, managing, and sharing drillhole and point-sample data within comprehensive drilling and mining workflows. This guide explains how MX Deposit data is organised and how to put the API to work, for example to read your drillhole data or to export it.
The API reference describes every endpoint in detail. It also covers the data hierarchy of projects, activities and drillholes/point samples, and how to authenticate.
Find the data you need
Work down the hierarchy, taking the ids from each response.
| Step | You have | Read | You get |
|---|---|---|---|
| 1 | Your credentials | Projects | The ids of your projects and their activities. |
| 2 | A project and an activity | Activities | The definition of the activity, with its table views. |
| 3 | A project and an activity | Collars | The collars of the activity. |
| 4 | A collar and a table view | Row references | The rows of the table view for the collar. |
Keep rows up to date
To avoid reading every row again, send the optional after parameter, an epoch timestamp in milliseconds, when you read
the rows of a table view. Only the rows created or updated after that time are returned.
Export your data
Collar exports run as jobs, so the request returns before the file exists:
- Start the export. The response describes the export job.
- Check the status of the export until its
stateisdone. - Download the file from the
urlin the status response.
For example, to export the collars of an activity. The examples use an API key, see authenticate for the other methods.
The operation_uid is in parameters.body of the job in the response. Use it to check the status:
The state is started, Exporting followed by the progress, or done. When it is done, the response contains the
url of the exported file.
Collars can be selected by project and activity, by collar ids, or by an export template. Only one way is used, the first
that applies: collarIds, an export template, filters, then project with activity.
Filter the collars to export
Add filters to export only the collars that match conditions on any header field of the activity, for example holes of a
given type. Every filter has a type, the field it applies to, an operator and, for most operators, values. A
collar must match all the filters to be exported.
- The
fieldis the_idof a header field. Find it atheader.sections[].fields[].field._idin the response of the activity. - For a
listfield, thevaluesare the ids of rows of the list, found inlist.rowsof the same field. - Dates are formatted as
MM/DD/YYYY. The relative date operators, such asthis_year, also needtimezoneoffset.
For example, to export the collars of an activity whose hole type is one of the given list rows and whose dip is between -90 and -45:
See Export in the API reference for the filter types and the operators of each type.
Filter examples
Each example is one item of the filters list. The ids are examples, use the ids of your own header fields.
Holes of given hole types. A list filter takes the ids of the list rows:
Dip between -90 and -45, a numeric filter:
Collars where a checkbox is checked. A checkbox filter takes no values:
Hole names that start with A1_, a text filter. The one_of operator takes a comma separated list in the first value:
Dates in 2026, a date filter with dates formatted as MM/DD/YYYY:
Dates in the current year. The relative date operators, such as this_year, need timezoneoffset in the request:
Send several filters in the filters list to export only the collars that match all of them:
Lab certificate result information is exported with a single request. It returns when the file is ready, with the url
of the exported file. Send an export_uid of your choice if you want to check its progress meanwhile, and use it in
place of the operation_uid to check the status. See Export in the API reference.
Good to know
- The activity and collar endpoints accept an
API-Versionheader. It changes the shape of some responses, for example how the assigned user and the file summaries are returned. - Requests that are not valid are answered with status 400 and a JSON body with an
errormessage.