ServiceNow.Api 1.3.23

There is a newer version of this package available.
See the version list below for details.
dotnet add package ServiceNow.Api --version 1.3.23
                    
NuGet\Install-Package ServiceNow.Api -Version 1.3.23
                    
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="ServiceNow.Api" Version="1.3.23" />
                    
For projects that support PackageReference, copy this XML node into the project file to reference the package.
<PackageVersion Include="ServiceNow.Api" Version="1.3.23" />
                    
Directory.Packages.props
<PackageReference Include="ServiceNow.Api" />
                    
Project file
For projects that support Central Package Management (CPM), copy this XML node into the solution Directory.Packages.props file to version the package.
paket add ServiceNow.Api --version 1.3.23
                    
#r "nuget: ServiceNow.Api, 1.3.23"
                    
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
#:package ServiceNow.Api@1.3.23
                    
#:package directive can be used in C# file-based apps starting in .NET 10 preview 4. Copy this into a .cs file before any lines of code to reference the package.
#addin nuget:?package=ServiceNow.Api&version=1.3.23
                    
Install as a Cake Addin
#tool nuget:?package=ServiceNow.Api&version=1.3.23
                    
Install as a Cake Tool

ServiceNow.Api

Nuget Nuget License: MIT Codacy Badge

Usage

To create a simple command line app that uses the ServiceNow REST API:

  1. Create a .NET Core 10.0 Console project in Visual Studio
  2. Ensure that you have specified <LangVersion>latest</LangVersion> in the csproj file, e.g.:
<Project Sdk="Microsoft.NET.Sdk">

	<PropertyGroup>
		<OutputType>Exe</OutputType>
		<TargetFramework>net10.0</TargetFramework>
		<LangVersion>latest</LangVersion>
		<Nullable>enable</Nullable>
		<AnalysisMode>Recommended</AnalysisMode>
		<AnalysisLevel>latest-recommended</AnalysisLevel>
	</PropertyGroup>

	<ItemGroup>
		<Folder Include="Properties\" />
	</ItemGroup>

	<ItemGroup>
		<PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
		<PackageReference Include="ServiceNow.Api" Version="1.2.*" />
	</ItemGroup>

</Project>

  1. Edit Program.cs to be similar to the following:
using System;
using System.Collections.Generic;
using System.Threading.Tasks;
using System.Runtime.Serialization;

namespace ServiceNow.Api.Example;

public static class Program
{
	public async static Task Main(string[] args)
	{
		var account = args[0];
		var username = args[1];
		var password = args[2];

		Console.WriteLine("Lists Windows Servers");

		using var serviceNowClient = new ServiceNowClient(account, username, password, new Options());

		// MANDATORY: The table name can be obtained from this list:
		// https://docs.servicenow.com/bundle/london-platform-administration/page/administer/reference-pages/reference/r_TablesAndClasses.html
		const string tableName = "cmdb_ci_win_server";

		// OPTIONAL: The main sysparm_query goes here.  See documentation here:
		// https://docs.servicenow.com/bundle/geneva-servicenow-platform/page/integrate/inbound_rest/reference/r_TableAPI-GET.html
		// If you omit this, an unfiltered result will be returned
		const string query = "name";

		// OPTIONAL: The fields to bring back.
		// This should be set to constrain the response to ONLY the fields that you are going to process.
		// Doing so will hugely speed up your query.
		var fields = new List<string> { "sys_id", "name" };

		var jObjectResults = await serviceNowClient.GetAllByQueryAsync(
			tableName,
			query,
			fields
			).ConfigureAwait(false);

		var modelResults = jObjectResults.ConvertAll(o => o.ToObject<WinServerModel>());

		Console.WriteLine("Windows Servers:");
		foreach (var modelResult in modelResults)
		{
			Console.WriteLine($"  - {modelResult.Id}: {modelResult.Name}");
		}
	}
}

[DataContract]
public class WinServerModel
{
	[DataMember(Name = "sys_id")]
	public string Id { get; set; }

	[DataMember(Name = "name")]
	public string Name { get; set; }
}
Product Compatible and additional computed target framework versions.
.NET net10.0 is compatible.  net10.0-android was computed.  net10.0-browser was computed.  net10.0-ios was computed.  net10.0-maccatalyst was computed.  net10.0-macos was computed.  net10.0-tvos was computed.  net10.0-windows was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last Updated
1.3.26 568 8/4/2026
1.3.23 166 8/4/2026
1.3.8 15,267 12/18/2025
1.3.7 14,478 7/3/2025
1.3.1 29,732 8/13/2024
1.2.60 31,598 2/23/2023
1.2.36 23,013 5/10/2022
1.2.34 19,161 4/9/2021
1.2.32 733 3/30/2021
1.2.28 649 3/29/2021
1.2.27 2,891 12/22/2020
1.2.20 3,736 5/21/2020
1.2.17 860 5/7/2020
1.2.9 15,162 12/11/2019
1.2.8 1,315 10/3/2019
1.2.7 821 10/3/2019
1.2.6 773 10/3/2019
1.2.5 859 9/4/2019
1.2.2 1,219 8/19/2019
1.1.21 1,121 7/19/2019
Loading failed

Fixes silent truncation of paged queries.

ServiceNow applies read ACLs after sysparm_limit is applied, so a request for 1,000 rows can legitimately return fewer while a great deal of data still follows. GetAllByQueryAsync treated any short page as the end of the result set and stopped there. Measured against a live instance, a query covering roughly 86,550 rows returned only 48,724: a 44% loss, silent, with no error raised.

Paging now continues until a genuinely empty page is returned. The "paging window has not increased" error is retained, but now fires only when a full page cannot advance the window, which is the real case for increasing the page size. A trailing page containing only the boundary record re-read by the '>=' window now ends paging cleanly.

Count validation now enforces only a shortfall. The expected total is a snapshot taken on the first page, and a long walk over a live table legitimately gains records while it runs, so retrieving more rows than expected is no longer treated as an error. Retrieving fewer still is, since that is the data-loss signal.

Note for upgraders: queries that previously terminated early will now return substantially more rows, which may increase runtime and memory use for large result sets.

Also improves the count mismatch error message, which previously printed a raw .NET type name.