Outbound HTTP Logging

Dave Slusher

5 minute read

It is quite common when developing and troubleshooting integrations that a ServiceNow developer may need some logging around API access. This logging can be required in both directions - in outbound API access of some external service or when providing an API for an external service to integrate inward to your instance. In this blog post, we will examine strategies for outbound logging. Log Levels There are three levels of Outbound Web Service Logging: Basic, Elevated and All.

Dave Slusher

2 minute read

YouTube video: https://youtu.be/R1Qgz51T4wI The Live Coding Team: dave.slusher, ctomasi, josh.nerius In this episode, we work with the Sift API in order to parse emails. Specifically, the involved generation of the signature in order to validate the request is the main thrust of this session. We begin with two requests that outwardly seem the same and work through why they signatures first are different and then generate different results between using NodeJS and the integration from a ServiceNow instance.

Josh Nerius

4 minute read

As highlighted in What’s New for Developers in Istanbul - Integrations, APIs, Authentication, the Istanbul release introduced Outbound Web Services Logging. This feature is a major quality-of-life enhancement for anyone working with integrations, and some potential benefits include: Write fewer gs.debug/log/info/etc. statements in your code and simplify the debugging process Quickly pinpoint the source of an outbound HTTP request Look at the history of requests made by a particular integration Analyze the volume of requests made by a particular integration What gets logged?

Josh Nerius

4 minute read

The Istanbul release introduces some very exciting features for APIs and Authentication. This post will bring you up to speed on what’s new, and we’ll follow up with more detailed posts about individual features in the coming days/weeks. New Inbound OAuth 2.0 Features Have you ever tried to build an app that integrates with ServiceNow, only to find that you couldn’t issue API calls on behalf of a specific user unless that user had credentials stored locally in the instance?