An Overview of SData – The SalesLogix Web Enabled API

Chances are, if you work or use SalesLogix (or any Sage product) you’ve heard of SData by now. SData is a basically a web enabled API for SalesLogix allowing you to interact with SalesLogix data from an external application or website. The great thing about SData is that it is a specification that is implemented via RESTful web services. This means you’re not limited to using SData with a particular technology (such as exclusively via .NET). In a nutshell, SData works via sending and receiving XML payloads via a URL. Pretty simple. This article will take a high-level overview of SData as an introduction (which means there will be several more in-depth posts on the way).

View the SalesLogix SData Developer series index

SData Versions

We started to see parts of SData as early as SalesLogix 7.5 and even more in 7.5.1. While these versions did work, SData wasn’t exactly considered fully-baked until SalesLogix 7.5.2 (and even more functionality added in 7.5.3 such as picklist support). Needless to say, there were significant changes in 7.5.2 from it’s earlier beta versions in 7.5.1 and prior. These changes were breaking changes, so if you’re on 7.5 or 7.5.1 what I will be outlining here won’t fit completely. The URL structure will be different and the way the payload is deilivered is quite different (but you’ll still get the general ideas from this article, just bear in mind you’ll have these changes to deal with).

The SData Server

The SData server is deployed from the Application Architect as a web portal. However, I do want to point out that using SData does not mean you have to be using the SalesLogix Web client. You can be an all LAN implementation and still deploy an SData portal. You only need to be on a version that includes support for SData. The SData deployment will create an “sdata” application in the deployment location (so you will have this next to your typical “slxclient” folder if you have a SalesLogix Web deployment). If you have a SalesLogix Web deployment then also deploying SData can be simpler since SData also uses the same entity model.

The Anatomy of an SData URL

Using SData comes down to an XML payload exchange via a URL. Knowing how these URLs are formed is important, and luckily, they are pretty easy to understand. A sample SData URL to access a list of Accounts would look like this:


Let’s break down what all those values mean:

  1. server & port: These are the server address and port of your SalesLogix web deployment.
  2. sdata: This is the deployment folder for the SData portal. As I mentioned earlier, the SData portal will reside as a folder named sdata next to your slxclient portal deployment.
  3. slx: The application name. SData is a specification that is currently used by several Sage applications, not just SalesLogix.
  4. dynamic: This is the contract name. I won’t get too deep into this now and may address this in a future post, but an SData deployment can support several integration contracts. For now, just stick with dynamic.
  5. -: This part of the URL defines the dataset to use. Stick with the hyphen “-” which means the default dataset (or that the application only supports a single dataset).
  6. Accounts: This is a resource to access, more on this next.

SData Resources

A resource is the entity type or table that you wish to query (or add, modify, delete, etc). Not all entities or tables are exposed by default. You get to pick and choose which entities are exposed via SData in the Application Architect (open the entity and you’ll see an SData tab ewhere you can specify whether the entity is exposed or not.

Sample SData URLs

Here’s some useful sample SData URLs you can use to query SalesLogix data via your browser. This is a great way to test things. When you access one of these URLs in your browser you’ll be promoted for your SalesLogix login credentials. One thing to keep in mind as you use these, normal SalesLogix security applies, so you’ll only see records that the user you’re logged in with can see.

Get a list of all adapters or resources exposed by the dynamic contract

Get the schema for an entity (account entity)

Get a list of all products

Get first 10 products only

Get a specific product by ID

Get child entities for an entity (contacts for account)

Query accounts where AccountName starts with ‘Ab’
http://server:port/sdata/slx/dynamic/-/accounts?where=AccountName like ‘Ab%’

Query accounts where AccountName equals “Abbott Ltd.”
http://server:port/sdata/slx/dynamic/-/accounts?where=AccountName eq ‘Abbott Ltd.’

The SData Client Library

If you’re using .NET with SData, one of the more easy ways to work with it is using the SData Client Library developed by Sage. When using the SData Client Library you don’t necessarily need to know how to structure the SData URLs, but that certainly does help. The source for this lirbary is available on github as well. I will definitely have more posts on this in the future including how to use, best ways to get this library and more.

View the SalesLogix SData Developer series index


Ryan Farley

Ryan Farley is the Director of Development for Customer FX and creator of He's been blogging regularly about SalesLogix, now Infor CRM, since 2001 and believes in sharing with the community. His new passion for CRM is Creatio, formerly bpm'online. He loves C#, Javascript, web development, open source, and Linux. He also loves his hobby as an amateur filmmaker.

1 Comment

  1. Hi,
    Do you have any clues on how to create a custom SData feed? I would like an SData feed that returns a set of entities based on the result of a Business Rule (or any other method).
    I have posted something on SlxDeveloper, but nobody answered:



Submit a Comment

Your email address will not be published. Required fields are marked *

Subscribe To Our Newsletter

Join our mailing list to receive the latest Infor CRM (Saleslogix) and Creatio (bpm'online) news and product updates!

You have Successfully Subscribed!