Is there any way to set the Response Status e.g. 400 for Import Set API?

[Tom Sienkiewicz]

Hi Folks,

I am trying to figure out a way how to return specific HTTP status codes from Import Set API.

Let's say a critical validation fails in an onBefore transform script - then I don'want the sending system to receive status 201, I want them to receive e.g. 400.

I know I can set the "error = true" and "error_message" as part of my script but this is not good enough, as that is only visible as part of the response body (<result> object), this is still very confusing to source system and makes error handling much more dificult.

It would be great to hear from anyone who has managed to solve this. Or perhaps ServiceNow can consider an enhancement to this API, seems like something that would be much required...

[Tony Chatfield1]

Hi, have you looked at Scripted REST API, I believe that setting status is one of its benefits- see the best practices page.

Scripted REST APIs (servicenow.com)
Scripted REST APIs good practices (servicenow.com)

[Tom Sienkiewicz]

Hi Tony, yes of course I know the scripted REST API,

I thought that it would be nice to use the transform-map based Import Set API instead. I also dislike the idea of combining both - in my opinion, Import Set API is a very good tool, it just lacks a few useful options. Why would ServiceNow give us an API that's "almost good to use, you just need to use this other API as well". That's tongue in cheek ofc, I have used this API many times successfully, depends on the complexity and specific requirements around error handling, I guess.

Scripted REST API would have to be the alternative if our vendors cannot handle the Import Set APIs response schema...

[Tony Chatfield1]

One think to consider if there is high volume (or it will grow), is that your limited platform resource may get tied up waiting for processing of data records end-to-end, and I don't think it best practice to use payload delivery status mechanism to validate data integrity (event in scripted rest api) as it may produce unexpected issues.
I would normally consider scripted rest api into a staging table with critical validation only if very necessary, then mapping and creation\update from the staging table via a standard transform to do all the heavy lifting and shifting.

[Tom Sienkiewicz]

Thanks, and I agree with potential performance impact.

In our case the Import Set API receives individual payloads (if there were multiple payloads sent in one message, of course the overall status would have no meaning). So I still think that if you expect the source system to do the error handling, it needs to be notified correctly what the status is. I believe the standard for that is using the 400 status family (I will admit I'm not sure if this is a global standard though). And we are talking about critical validation there. I should probably add that this is synchronous messaging (again, an async solution would probably be better but since this is a complex interface involving a middleware, that was the overall decision...).

So we could of course use Scripted REST AP first as a gateway and return any errors from there first, before passing the data to Import Sets, and that is what we have done numerous times in the past. But we wanted to avoid the extra step in the setup, to make it more lean.

I would still appreciate being able to set the desired response status from Import Set API but looks like we will just need to ask the source system to do a bit of extra response processing to check if there were any errors.