TDS XML API

This document outlines the XML-API to communicate with TDS. The XML-API allows you to write custom programs that work with the template or inspection data stored by TDS.

warning

TDS XML parsing does not support XML comments in the form of

<myTag>
  <!-- a comment to my value below -->
  <myValue>25</myValue> <!-- or an inline comment -->
</myTag>

note

Example code snippets on this page will often use https://tds.example.com as the domain of the TDS host. Those need to be replaced accordingly.

Authenticating against TDS

TDS uses an authentication token combined with the HTTP basic-auth protocol. After you have successfully authenticated against TDS, the server will send you an auth token as part of the HTTP response. That auth token must be present in each HTTP request sent to the API.

Obtaining an auth token

Send an HTTP POST request to /users/get_token with the following fields and a Content-type of application/x-www-form-urlencoded:

User[login]=${LOGIN}
User[password]=${PASSWORD}

where ${LOGIN} and ${PASSWORD} represent username and password, respectively.

If the login is successful, TDS will respond with 200 OK, and the auth token will be included in the XML response. e.g.

<token>OTJkNTBiNDUtZDA3MC00M2NlLTljY2YtMjM2NTJlNWU5YmE2</token>

If the login was unsuccessful, TDS will reply with 401 Unauthorized.

note

By default, TDS runs with TLS and only accepts HTTPS connections. This can be disabled in the settings to allow for plain-text connections. This is highly discouraged.

Using the auth token

The auth token must be included with each HTTP request sent to TDS. Each request must have the following header:

Authorization: Token: ${AUTH-TOKEN}

where ${AUTH-TOKEN} is your auth token.

Ending your session

Send a POST request to /users/end_session

Make sure to include your auth token as outlined in the previous section.

Reading inspections

The most common use-case for programmatic TDS interaction is the regular query for new inspection. They can be read by accessing the /inspections HTTP endpoint.

This will return an XML of the following form:

<inspections>
    <Inspection>
      <!-- inspection 1 -->
    </Inspection>
    <Inspection>
      <!-- inspection 2 -->
    </Inspection>
    <Inspection>
      <!-- inspection 3 -->
    </Inspection>

    <!-- ..... -->
</inspections>

By default this endpoint returns an overview over the last 10 inspections. Each <Inspection> tag contains meta-data about the inspection but the individual checks are omitted.

The /inspection endpoint supports the following query parameters:

Parameter	Options	default	Behavior
`limit`	pos. int / `-1`	`10`	will only include this many inspections in the response, `-1` for unlimited
`offset`	pos. int	`0`	will omit this many inspections for the query - can be used for pagination
`user-id`	pos. int, comma separated list	-	filters for inspections created by any of the listed users
`part-id`	pos. int, comma separated list	-	filters for inspections that belong to any of the listed parts
`route-id`	pos. int, comma separated list	-	filters for inspections that belong to any of the listed routes
`group-id`	pos. int, comma separated list	-	filters for inspections that belong to a part within any of the listed groups
`insp-name`	string	-	filters for inspections with this name
`joint`	`weld`/`bond`	-	filters for inspections of this type
`has-failure`	`0`	`1`/`0`	when enabled only filters for inspections that contain failed checks
`date-start`	date-time in ISO8601	-	filters for inspections created after this point in time
`date-end`	date-time in ISO8601	-	filters for inspections created before this point in time
`uploaded-date-start`	date-time in ISO8601	-	filters for inspections uploaded after this point in time
`uploaded-date-end`	date-time in ISO8601	-	filters for inspections uploaded before this point in time

note

The date-time strings should be of the form YYYY-MM-DDThh:mm:ss.

Example: Query all new inspections

A common use-case is to have a scheduled task query TDS for new inspections. This can be done by providing the timestamp of the most recent, knwon inspection and querying all inspections since after that.

E.g., given the most recent inspection that has been returned by my last query was on 2024-10-10 15:22:14, the respecitve next query would look like this:

https://tds.example.com/inspections?limit=-1&uploaded-date-start=2024-10-10 15:22:14

Reading a single inspection

To view a single inspection, use the endpoint /inspections/${N}, where ${N} is the Id of the inspection you want to view. The results contain not only the inspection XML, as described in the following section, but also all weld (bond) checks, and measurements associated with the inspection.

XML description

The root XML object is <inspections>. Each <Inspection> sub-object has the following fields:

Field	Description
id	primary key
uid	Unique ID from the RSWA. May not be unique in the server db
created_time	Time the inspection was inserted into TDS
modified_time	time inspection was last modified on the RSWA
modified_count	number of times inspection was modified on the RSWA
user_id	ID of user who took the inspection
user_name	name of user who took the inspection
part_id	ID of part inspected
part_uid	UID of the part inspected
part_name	name of part inspected
route_name	name of route on part inspected
device_uid	unique ID of the RSWA from which the inspection originated
device_serial	serial number of the device
created	Time the inspection was created on the RSWA
route_id	ID of the route
route_uid	UID of the route
tz_bias	timezone bias
template_revision	which template revision was active on the RSWA during time of inspection
bond_check_count	number of adhesive bonds checked
bond_check_failed	number of adhesive bonds failed
weld_check_count	number of welds checked
weld_check_failed	number of welds failed
joint	joint type. Either Weld or Bond
material	material type. Either Steel or Aluminum

Checks

If you are viewing a single inspection, then additionally each <Inspection> object contains zero or more <WeldCheck> (or <BondCheck>) objects.

Weld checks contain the following XML fields:

Field	Description
id	internal database id
position	The position of the check within the inspection
decision	Pass/fail decision
decision_text	Optional text for the pass/fail decision
caption	descriptive text
inspection_id	Id of the parent inspection
reason_id	Id of the pass/fail reason selected
weld_id	Id of the weld measured

Bond checks contain the following XML fields:

Field	Description
id	internal database id
position	The position of the check within the inspection
decision	Pass/fail decision
decision_text	Optional text for the pass/fail decision
caption	descriptive text
inspection_id	Id of the parent inspection
reason_id	Id of the pass/fail reason selected
bond_id	Id of the bond measured

Measurements

If you are viewing a single inspection, then additionally each <WeldCheck> (or <BondCheck>) object contains zero or more <WeldMeasurement> or (<BondMeasurement>) objects.

Weld measurements contain the following XML fields:

Field	Description
id	Internal database id
slot	Slot of the measurement (for 3T welds, either 1 or 2)
weld_check_id	Id of the associated weld check
cscan	Encoded cscan image data
setup_front_thickness	Front plate thickness measured by setup
setup_middle_thickness	Middle plate thickness measured by setup
alg_version	Version of the algorithm used
setup_proc_attr
out_front_thick	Front plate thickness measured
out_stack_thick	Stack thickness measured
out_indentation	Indentation measured
circle_auto_x	Automatic circle x coordinate
circle_auto_y	Automatic circle y coordinate
circle_auto_diameter	Automatic circle diameter
circle_man_x	Manual circle x coordinate
circle_man_y	Manual circle y coordinate
circle_man_diameter	Manual circle diameter
warning_flags	Warning flags from the RSWA
timestamp	Time measurement was taken

Bond measurements contain the following fields:

Field	Description
id	Internal database id
slot	Slot of the measurement (where it appears along the bead)
bond_check_id	Id of the associated bond check
cscan	Encoded cscan image data
setup_front_energy	Front plate thickness measured by setup
alg_version	Version of the algorithm used
setup_proc_attr
out_front_thick	Front plate thickness measured
bead_auto_rho
bead_auto_theta
bead_auto_width	Automatically detected width of the bead
bead_man_rho
bead_man_theta
bead_man_width	Manually adjusted width of the bead
warning_flags	Warning flags from the RSWA
timestamp	Time measurement was taken

Accessing the product catalog

Filtering the inspection list based on group, part, route, etc. requires you to use the id's of the various items. To obtain these values, use the following HTTP endpoints:

/groups
/parts
/routes

Additional endpoints that can be queried for product data are:

/images
/welds
/bonds
/presets
/hot_spots
/devices
/categories
/reasons
/revisions
/users
/version
/reports
/measurements
/search

TDS tries to provide a RESTful API which means that the following commmands are generally accepted:

Command	Invocation
index	HTTP GET to `/<endpoint>`
view	HTTP GET to `/<endpoint>/{id}`
add	HTTP POST to `/<endpoint>`
edit	HTTP PATCH/POST to `/<endpoint>/{id}`
delete	HTTP DELETE to `/<endpoint>/{id}`
actions	HTTP POST to `/<endpoint>/<action-keyword>` or `/<endpoint>/<action-keyword>/{id}`

Not all endpoints provide all commands and some may provide additional commands through certain action keywords. Both will be listed below for the each endpoint individually.

All requests with an XML body must contain <request> as the root tag. The requests index, view, and delete do not require an HTML body.

Note, that any data manipulation through the XML api should be run on a test system before going into production. TDS checks for data validity in many places but data corruption might occur on invalid input.

Groups

The /groups endpoint provides the commands

index
view
add
edit
delete

Due to legacy reasons, rather than just listing the groups the index and view methods provide a part tree. Sending GET to the /group endpoint returns the full part tree with all nested groups and parts.

Starting with v4.0.2: To just get the list of groups, send an HTTP GET request to the /groups/light endpoint which will just list the nested group structure.

The resulting XML contains the following fields:

Field	Description
id	Internal database id
uid	Universal id
parent_id	Id of parent group, if it exists
name	Name of the group
created	Date of creation
modified	Date last modified
deleted	1 if the group is deleted, 0 otherwise
delete_date	if the `deleted` field is 1, the date of deletion
comment	User-provided comment

To add or edit a new group use the add command via an HTTP POST request to the /groups endpoint with a content XML of the same layout as the above. Note, that the root tag must be <request>.

Parts

The /parts endpoint provides the commands

index
view
add
edit
delete

Due to legacy reasons, rather than listing all parts, the index command just displays the top level parts - parts that do not have an associated group.

Starting with v4.0.2: Sending a GET request to the /parts/all endpoint returns a list of all parts - including those in groups and sub-groups.

Either way, the resulting XML contains the following fields:

Field	Description
id	Internal database id
uid	Universal id
group_id	Id of parent group, if it exists
name	Name of the group
created	Date of creation
modified	Date last modified
deleted	1 if the part is deleted, 0 otherwise
delete_date	if the `deleted` field is 1, the date of deletion
comment	User-provided comment
weld_count	Number of welds in the part
bond_count	Number of bonds in the part
measurement_type	rswa steel, rswa aluminum, abis steel, or abis aluminum
meta	User-provided metadata

When using the view command to get a single part, the following additional fields will be present:

Field	Description
Weld	full weld object, repeated for every weld
Bond	full bond object, repeated for every bond
Image	full image object, repeated for every image
Route	full route object, repeated for every route

To add a new part use the add command via an HTTP POST request to the /parts endpoint with a content XML of the same layout as the above. Note, that the root tag must be <request>.

The fields which can be set manually for add and update are:

id
uid
group_id
name
created
modified
deleted_date
measurement_type
meta
comment

Please note, deleting a part deletes all associated welds, routes and images recursively. Adding a new part however, does not work recursively. In order to populate a full part with welds/bonds, images and routes, each have to be added successively.

The proper way would be to add a part, then add the welds/bonds referencing the part - via the id returned by TDS for the part -, then add the images referencing the part, and finally add the routes where each route item references image and weld respectively.

Routes

The /routes endpoint provides the commands

view
add
edit
delete

To get the list of parts, use the index command via an HTTP GET request to the /routes endpoint. The resulting XML contains the following fields:

Field	Description
id	Internal database id
uid	Universal id
part_id	Id of parent part
name	Name of the group
deleted	1 if the route is deleted, 0 otherwise
delete_date	if the `deleted` field is 1, the date of deletion
route_item_count	Number of route items in the route
measurement_type	rswa steel, rswa aluminum, abis steel, or abis aluminum
comment	User-provided comment

To add a new route use the add command via an HTTP POST request to the /routes endpoint with a content XML of the same layout as the above. Note, that the root tag must be <request>.

Route Items

The /route_items endpoint provides the commands

Due to legacy reasons, additionally, a /route_items/delete endpoint is provided to remove route_items

To add a new route item, post an XML request like the following to /route_items:

<request>
	<route_id>2</route_id>
	<before_position>0</before_position>
	<RouteItem>
		<weld_id>207</weld_id>
	</RouteItem>
</request>

With the fields representing the following data:

Field	Description
route_id	Database ID of the route this item belongs to
before_position	The position before which this route_item will be inserted
RouteItem	May be repeated to add multiple
weld_id	The ID of the weld this item is associated with (or `bond_id` in case of a bond)

To delete a route item, post an XML like the following to the /route_items/delete endpoint:

<request>
	<route_id>2</route_id>
	<RouteItem>
		<position>0</position>
	</RouteItem>
</request>

Here, position represents the index of the route item that is to be removed - starting with index 0.

Images

The /images endpoint provides the commands

view
add
delete

To receive a single image with its respective meta data, send an HTTP GET request to the /images/{id} endpoint, where {id} is the id of the desired image. The resulting XML contains the following fields:

Field	Description
id	Internal database id
uid	Universal id
part_id	Id of parent part
width	Width of the image in pixels
height	Height of the image in pixels
position	Position in relation to other images. Smaller positions are located before higher ones.
crc32	CRC32 checksum of the image's data
thumbnail	Base64 encoded thumbnail - quality reduced preview of the full image
data	Base64 encoded image data
meta	Arbitrary meta data that may be passed along with the image. Is shown on export.

To add a new image use the add command via an HTTP POST request to the /images endpoint with a content XML of the same layout as the above. Note, that the root tag must be <request>.

Welds

The /welds endpoint provides the commands

add
edit
action - "delete"

To add a new weld use the add command via an HTTP POST request to the /welds endpoint with a content XML of the same layout as the above. Note, that the root tag must be <request>.

The containing <Weld> XML may contain the following tags:

Field	Description
id	Internal database id
uid	Universal id
part_id	Id of parent part
name	Name of the weld
slots	Number of slots for this weld (1 or 2)
stack_front	stack width of front plate
stack_middle	stack width of center plate
stack_back	stack width of back plate
diameter_min	minimum acceptable diameter
diameter_target	minimum targeted diameter
indentation_min	minimum indentation of weld
indentation_max	maximum indentation of weld
category_id	optional category the weld belongs to
thickness_min	minimum plate thickness after weld
thickness_max	maximum plate thickness after weld
schedule	weld schedule
hot_spot_count	Amount of hot spots associated with this weld
route_item_count	Amount of route items associated with this weld
robot	Optional name of the assigned robot
meta	Arbitrary meta data that may be passed along with the image. Is shown on export.
comment	Optional comment regarding the weld

To delete a weld, send a post request to /welds/delete with an XML like the following:

<request>
    <Weld>
        <id>{id}</id>
    </Weld>
    <Weld><!-- possibly repeated for other welds --></Weld>
</request>

where {id} is the id of the weld that is to be deleted.

Bonds

The /bonds endpoint provides the commands

add
edit
action - "delete"

To add a new bond use the add command via an HTTP POST request to the /bonds endpoint with a content XML of the same layout as below. Note, that the root tag must be <request>. The containing <Bond> XML may contain the following tags:

Field	Description
id	Internal database id
uid	Universal id
part_id	Id of parent part
name	Name of the bond
slots	Number of slots for this bond (1 or 2)
stack_front	stack width of front plate
stack_back	stack width of back plate
category_id	optional category the bond belongs to
bead_min	minum diameter of adhesive bead
hot_spot_count	Amount of hot spots associated with this bond
route_item_count	Amount of route items associated with this bond
robot	Optional name of the assigned robot
meta	Arbitrary meta data that may be passed along with the image. Is shown on export.
comment	Optional comment regarding the bond

To delete a bond, send a post request to /bonds/delete with an XML like the following:

<request>
    <Bond>
        <id>{id}</id>
    </Bond>
    <Bond><!-- possibly repeated for other bonds --></Bond>
</request>

where {id} is the id of the bond that is to be deleted.

Presets

The /presets endpoint provides the commands

index
add
edit
delete

To get the list of presets, use the index command via an HTTP GET request to the /presets endpoint. The resulting <Preset> XML contains the following fields:

Field	Description
id	Internal database id
name	Name of the preset
data	a JSON string containing the preset parameters as key-value pairs

The data JSON is of the form

{
    "type": "v3weld",                   // Fix value
    "absolute-adjustment": 0,           // Valid values: decimal value between [-0.002 - 0.002]
    "min-size-adjustment": "off",       // Valid values: off / on
    "peak-detector": "standard",        // Valid values: standard / aggressive / smart
    "echo-shape-processing": "off",     // Valid values: off / on
    "secondary-echo-processing": "off", // Valid values: off / subtle / moderate / full
    "surface-follower": 0               // Valid values: 
}

The values might differ depending on the configuration at hand.

To add a new preset use the add command via an HTTP POST request to the /presets endpoint with a content XML of the same layout as the above. Note, that the root tag must be <request> tag.

Hotspots

The /hot_spots endpoint provides the commands

Due to legacy reasons, additionally, a /hot_spots/delete endpoint is provided to remove hotspots

To add a new hotspot, post an XML request like the following to /hot_spots:

<request>
  <image_id>3</image_id>
  <HotSpot>
    <weld_id>1</weld_id>
    <data>...</data>
  </HotSpot>
</request>

With the fields representing the following data:

Field	Description
image_id	Database ID of the image this hotspot belongs to
Hotspot	May be repeated to add multiple
weld_id	The ID of the weld this item is associated with (or `bond_id` in case of a bond)
data	a JSON string the location of the hotspot on the image as well as the location label location

The data field containing the hotspot location as json encoded string has the following format:

{
    "lx":836,
    "ly":132,
    "ts": [{
            "x":690,
            "y":127
        }]
}

lx and ly represent the center coordinates of the hotspot label and x/y represent the coordinates of the hotspot itself. Both coordinates are given in pixels.

To delete a hotspot, post an XML like the following to the /hot_spots/delete endpoint:

<request>
	<image_id>2</image_id>
	<HotSpot>
		<weld_id>1</weld_id>
	</HotSpot>
</request>

Devices

The /devices endpoint provides the commands

index
delete

To list the RSWA devices paired with a TDS server, send an HTTP GET request to the /devices endpoint. The resulting <Device> XML contains the following fields:

Field	Description
id	Internal database id
uid	Universal id
serial	the device's 4 digit serial number
software	array explorer software version installed on the device
name	human readable name as displayed in the device manager
ip	device's ip address
affiliation	deprecated
created	time stamp of the device registration
modified	time stamp of the last device modification

Reasons

The /reasons endpoint provides the commands

index
add
edit
delete

To list the reasons, send an HTTP GET request to the /reasons endpoint. The resulting <Reason> XML contains the following fields:

Field	Description
id	Internal database id
uid	Universal id
caption	title of the reason
type	`1` for weld reason, `0` for bond reason
created	date of reason creation
deleted	1 if the group is deleted, 0 otherwise
delete_date	if the `deleted` field is 1, the date of deletion
position	relative display position with respect to the other reasons

To add a new reason use the add command via an HTTP POST request to the /reasons endpoint with a content XML of the same layout as the above. Note, that the root tag must be <request> tag.

Revisions

The /revisions endpoint provides the commands

index
add
delete
action - send_revision_to_device

To list the revisions, send an HTTP GET request to the /revisions endpoint. The resulting <Revision> XML contains the following fields:

Field	Description
id	Internal database id
name	title of the revision
md5	MD5 hash over the revision payload
created	date of reason creation
deleted	1 if the group is deleted, 0 otherwise
delete_date	if the `deleted` field is 1, the date of deletion

To add a new reason use the add command via an HTTP POST request to the /revisions endpoint with a content XML of the same layout as the above. Note, that the root tag must be <request> tag. When creating new revisions, there is no need to provide a md5 checksum, as it will be generated by TDS.

`send_revision_to_device`

Available since TDS + RSWA v4.3.0

This action allows to trigger the revision download to the device. The request body must look like this and be posted to revisions/send_revision_to_device/<rev-id>:

<request>
    <device_uid>22a3ff3f-ba12-4acf-867e-d4a5057d992e</device_uid>
    <force_activate>true</force_activate>
</request>

Field	Description
rev-id	the ID of the revision which should be downloaded to the device
device_uid	the UID of the device the revision should be downloaded to
force_activate	set to `true` in order have the RSWA activate the revision immediately

Note, that the request handling is synchronous. The success/error response will be sent back once the full revision download actually succeeds or fails.

Depending on the revision size and the network bandwidth, this can take longer than other operations. Make sure, to extend the request timeout correspondingly.

Users

The /users endpoint provides the commands

index
view
add
edit
delete
action "get_token", "end_session"

To list the users, send an HTTP GET request to the /users endpoint. The resulting <User> XML contains the following fields:

Field	Description
id	Internal database id
uid	Universal id
name	primary user name
alt_id	additional user name info
image_index	Index of the image associated with user (0-10)
created	date of user creation
modified	date of user modification
deleted	1 if the group is deleted, 0 otherwise
delete_date	if the `deleted` field is 1, the date of deletion
login	login name
pwd_hash	password hash used for authentication
pwd_hash_public	password hash used for authentication
purged_on	date of user purge
Ugroup	possibly repeated index of the user group the user belongs to (1-7)

The user groups are

standard
advanced
admin
editor
reporter
transfer
supervisor

To add a new reason use the add command via an HTTP POST request to the /users endpoint with a content XML of the same layout as the above. Note, that the root tag must be <request>.

When creating new users, pwd_hash and pwd_hash_public cannot be provided as they are generated by TDS. To create a user with a password the <password> may be provided instead of <pwd_hash> and pwd_hash_public. TDS will generate the appropriate hashes automatically. Note, that an SSL encrypted connection is strongly encouraged. Otherwise, the passwords will be transmitted across the network in clear readable form.

To add user groups, the syntax is slightly different from the table above. An XML for inserting a user may look like this:

<request>
    <User>
        <name>Readable user name</name>
        <alt_id>alternative name</alt_id>
        <image_index>1</image_index>
        <login>loginname</login>
        <password>password1234</password>

        <!-- starting with TDS V4.0.1 passwords can and should be base64 encoded -->
        <pw64>cGFzc3dvcmQxMjM0</pw64>

        <!-- starting with TDS V4.0.1 it can be written as -->
        <Ugroup>
            <id>3</id> <!-- one id for every group -->
            <id>1</id> <!-- one id for every group -->
        </Ugroup>
    </User>

    <!-- TDS V4.0.0 and below require -->
    <Ugroup>
        <Ugroup>3</Ugroup>
        <Ugroup>1</Ugroup>
    </Ugroup>
</request>

The get_token and end_session actions are explained in the authentication section.

Version

To get the TDS version, send an HTTP GET request to the /version endpoint. The response <version> XML will look contain the TDS version. For TDS 2 this would be

<version>2</version>

Reports

The /reports endpoint only provides the summary action. This can be accessed by sending an HTTP GET request to /reports/summary.

Field	Description
num_welds	number of registered welds
num_bonds	number of registered bonds
num_images	number of registered images
num_routes	number of registered routes
num_groups	number of registered groups

Search

The /search endpoint only provides the index command. By sending an HTTP GET request to /search a list of all part groups, parts, welds, bonds, and users is returned with their respective id, name and optionally a parent id in case of hierarchical parts.

The <Result> response is returned once for every result and contains the following fields

Field	Description
type	`Group`, `Part`, `Weld`, `Bond`, or `User`
id	id of the result object
text	name/identifier of result object
parent_id	in case of hierarchical object, optionally the parent object id

Examples

The following snippets show how the TDS api can be accessed with CURL or Python. Note, that all of these snippets ignore SSL certificate errors since TDS ships with self-signed certificates which would be rejected by proper certificate checks.

CURL

To authenticate against TDS and obtain a user token, the following CURL command can be executed.

curl -X POST --insecure -H "Content-Type: application/x-www-form-urlencoded" -d 'User[login]=<your-username>' -d 'User[password]=<your-password>' https://<your-tds-address>/users/get_token

Just replace <your-username>, <your-password> and <your-tds-address> respectively.

To request any of the endpoints - the parts catalogue in this example - provide the obtained user token and execute the following command.

curl -X GET --insecure -H "Authorization: Token: <your-token>" https://<your-tds-address>/parts/all

Just replace <your-token> with the obtained user token.

To post to any of the endpoints - and add a new part in this example - create the appropriate XML-document and send it to the respective endpoint.

curl -X POST --insecure -H "Authorization: Token: <your-token>" -T <your-xml-file> https://<your-tds-address>/parts

Just replace <your-token> with the user token, <your-xml-file> with the path to the prepared xml body and <your-tds-address> with the address to your TDS server.

Python

The following Python code snippet authenticates against a TDS instance (<your-tds-address>) with <your-username> and <your-password>, downloads a specific inspection report (inspection with id 1 in this case) and print all the contents of that inspection.

This snippet relies on the 3rd party requests library which can be installed with pip install requests.

import requests
import xml.etree.ElementTree as ET

TdsAddress = "https://<your-tds-address>"
InspectionID = "1" ## Or any other inspection you want to download

User = "<your-username>"
Pass = "<your-password>"

## Get the authentication token
tokenXml = requests.post(
    f"{TdsAddress}/users/get_token",
    verify=False,
    headers={"Content-type": "application/x-www-form-urlencoded"},
    data=f"User[login]={User}&User[password]={Pass}",
)
token = ET.fromstring(tokenXml.text).text

## Get all inspections
## inspectionsXml = requests.get(f"{TdsAddress}/inspections")

## Get a single inspection
inspectionXml = requests.get(
    f"{TdsAddress}/inspections/{InspectionID}",
    verify=False,
    headers={"Authorization": f"Token: {token}"},
)
inspectionTree = ET.XML(inspectionXml.text)

for child in inspectionTree:
    print("Inspection:")
    for item in child:
        print(f"{item.tag}: {item.text}")

A full example to upload a part with a couple of welds, images and a route is provided here: [Full Part Import Example](Part Import Example/main.md)

Authenticating against TDS​

Obtaining an auth token​

Using the auth token​

Ending your session​

Reading inspections​

Example: Query all new inspections​

Reading a single inspection​

XML description​

Checks​

Measurements​

Accessing the product catalog​

Groups​

Parts​

Routes​

Route Items​

Images​

Welds​

Bonds​

Presets​

Hotspots​

Devices​

Categories​

Reasons​

Revisions​

send_revision_to_device​

Users​

Version​

Reports​

Search​

Examples​

CURL​

Python​

Authenticating against TDS

Obtaining an auth token

Using the auth token

Ending your session

Reading inspections

Example: Query all new inspections

Reading a single inspection

XML description

Checks

Measurements

Accessing the product catalog

Groups

Parts

Routes

Route Items

Images

Welds

Bonds

Presets

Hotspots

Devices

Categories

Reasons

Revisions

`send_revision_to_device`

Users

Version

Reports

Search

Examples

CURL

Python