Skip to main content
A
AB_92321417-Bedrock
7-Bedrock
July 16, 2025
Solved

Importing XML via /Thingworx/Importer with AppKey returns 200 OK but creates no entities (TWX 9.6)

  • July 16, 2025
  • 1 reply
  • 505 views

I’m trying to import an XML file of an entity (exported from a ThingWorx 9.6 system) into another TWX 9.6 instance via a backend service that issues:

 

POST /Thingworx/Importer
?purpose=import
&IgnoreBadValueStreamData=false
&WithSubsystems=false
&overwriteConfigurationTableValues=true
&overwritePropertyValues=true
&usedefaultdataprovider=true

Headers:

 

appKey: <valid key for Administrator>
X-ThingWorx-Session: true
X-XSRF-TOKEN: TWX-XSRF-TOKEN-VALUE
Content-Type: multipart/form-data (handled by FormData boundary)

The call uploads the file (file field) and returns 200 OK.
In the response body (octet-stream) and in ApplicationLog I only see:

 

Start post migrating from version [9.3.0] to version [9.3.0]
Finished post migrating from version [9.3.0] to version [9.3.0]

No errors are logged, yet the Thing inside the XML (THING_NAME_IMPORTED) never appears in Composer.
– ThingTemplate, ValueStream and Project referenced in the XML already exist.
– The same XML imported manually through Composer shows the identical log and creates it correctly.
– The AppKey user has full Design-Time Create permissions.

What additional conditions could cause the Importer to silently skip entities despite a 200 OK?
Any pointers or diagnostic steps would be appreciated.

Thanks in advance!

Best answer by AB_9232141

Thanks for the hints, really appreciated!

 

-Yes, I'm using the admin appKey just for testing.

I tried both of these queries:

'https://HOSTNAME/Thingworx/Importer' 
 + '?IgnoreBadValueStreamData=false' 
 + '&WithSubsystems=false' 
 + '&overwriteConfigurationTableValues=true' 
 + '&overwritePropertyValues=true' 
 + '&purpose=import' 
 + '&usedefaultdataprovider=false';

and also just:

https://HOSTNAME/Thingworx/Importer

In both cases, the import worked.

 

-The Things I imported had subscriptions and didn’t cause any issues.

 

-Yes, I was checking the correct Thing.

 

-That version mismatch is weird for me too—ThingWorx is 9.6, but the import logs (from both Composer and API) shows version 9.3. As long as it works, I’m not  digging too much into that for now.

 

-Yes, I have the privileges to view the Things in Composer.

 

-I had already checked the logs but nothing helpful showed up.

 

Eventually, comparing the Composer and Postman calls 1:1 helped me solve it. I was missing two key headers in the request:

  • 'Content-Length': the actual byte length of the XML body

  • Host: the target host

Here’s the complete working header:

headers: {
 'Content-Length': String(contentLength),
 Host: 'HOSTNAME.com', 'X-XSRF-TOKEN': 'TWX-XSRF-TOKEN-VALUE', appKey: appkey, contentType: 'text/xml' }

And for the body: I used formData of type file named "file".

With that, I was able to upload a new exported Thing directly from NEST.js code into the target environment.

1 reply

Rocko
Rocko19-Tanzanite
19-Tanzanite
July 16, 2025

Try with an admin app key (just for testing).

Maybe the thing couldn't be started and is removed then. 

Also try usedefaultdataprovider=false

I've seen imports failing when there were subscriptions in the thing, another thing to check.
Are you checking for the right entity? (sorry, I had to ask)
In the screenshot it says 9.3 but you have 9.6 that's a bit strange.
Check also if you have the privileges to see the thing in Composer.
If all else fails, enable & check stack traces.

    A
    AB_92321417-BedrockAuthorAnswer
    7-Bedrock
    July 17, 2025

    Thanks for the hints, really appreciated!

     

    -Yes, I'm using the admin appKey just for testing.

    I tried both of these queries:

    'https://HOSTNAME/Thingworx/Importer' 
 + '?IgnoreBadValueStreamData=false' 
 + '&WithSubsystems=false' 
 + '&overwriteConfigurationTableValues=true' 
 + '&overwritePropertyValues=true' 
 + '&purpose=import' 
 + '&usedefaultdataprovider=false';

    and also just:

    https://HOSTNAME/Thingworx/Importer

    In both cases, the import worked.

     

    -The Things I imported had subscriptions and didn’t cause any issues.

     

    -Yes, I was checking the correct Thing.

     

    -That version mismatch is weird for me too—ThingWorx is 9.6, but the import logs (from both Composer and API) shows version 9.3. As long as it works, I’m not  digging too much into that for now.

     

    -Yes, I have the privileges to view the Things in Composer.

     

    -I had already checked the logs but nothing helpful showed up.

     

    Eventually, comparing the Composer and Postman calls 1:1 helped me solve it. I was missing two key headers in the request:

    • 'Content-Length': the actual byte length of the XML body

    • Host: the target host

    Here’s the complete working header:

    headers: {
 'Content-Length': String(contentLength),
 Host: 'HOSTNAME.com', 'X-XSRF-TOKEN': 'TWX-XSRF-TOKEN-VALUE', appKey: appkey, contentType: 'text/xml' }

    And for the body: I used formData of type file named "file".

    With that, I was able to upload a new exported Thing directly from NEST.js code into the target environment.

      Terms & ConditionsCookie settingsAccessibility statement