Retrieving a complete CMDB record from ServiceNow should be straightforward. In practice, when you use the Table API to get a laptop record with all its related entities, that single logical request becomes eleven separate API calls, each depending on the result of the previous one.
Squid eliminates all of that. One request. Complete data. No orchestration code.
This post explains exactly why the Table API works this way, what it costs your team, and why switching to Squid is the better architectural choice.
Key Takeaways
- The Table API returns data as ServiceNow stores it, meaning related entities come back as system IDs, not resolved values. One complete record can require 11 chained requests.
- Each chained call multiplies your complexity. Dependency management, error handling, and data assembly all land in your integration code.
- Peripheral systems should not need to understand ServiceNow internals. They need complete, structured data they can consume immediately.
- Squid moves everything to the server side. Relationship traversal, data assembly, and response formatting happen before the response leaves ServiceNow.
- Proven at scale. Swiss Post handles 100,000+ daily requests across 30 peripheral systems using Squid, with over two years of production stability.
Why the Table API Requires Multiple Calls
ServiceNow's data model is deeply relational. Configuration items reference users. Users reference locations. Locations reference companies. Assets reference models. Models reference manufacturers. Services reference configuration items.
Within ServiceNow itself, this is a strength. Users navigate naturally from a server to its assigned user, to that user's location, and so on. The relationships make the data meaningful and connected.
The challenge appears when a peripheral system needs that same data.
The Table API returns data exactly as it exists in each individual table. A hardware query returns hardware attributes plus system IDs pointing to related tables. Those system IDs are not the data your system needs. To get actual values, you follow each ID with another API call, which may return further IDs, requiring yet another call. The chain grows with every relationship you need to resolve.
This is not a flaw in ServiceNow. It is simply how a relational database exposes its structure. The Table API is designed for direct table access, not for delivering fully assembled records to external systems.
A Concrete Example: One Laptop, Eleven Calls
Consider a monitoring system that needs comprehensive information about a laptop. From its perspective, this is one request: give me everything about this device.
With the Table API, that one request becomes eleven:
- Initial hardware record — cmdb_ci_pc_hardware
- Asset details — alm_hardware
- Assigned user — sys_user
- User location — cmn_location
- CI location — cmn_location
- Manufacturer — core_company
- Model — cmdb_model
- CI relationships — cmdb_rel_ci
- Parent CI — cmdb_ci
- Associated service — cmdb_ci_service_auto
- Network ports — cmdb_ci_network_adapter
Each call is required because each table only holds a pointer to the next. The hardware table does not contain the asset data; it holds a reference to it. The asset record does not contain user details; it holds a reference to them. And so on down the chain.
The exact number of calls depends on which relationships you need and how deeply nested they are. The pattern, however, is always the same: the more complete the data you need, the more calls you have to make.
What That Costs Your Team
The API call count is only the surface of the problem.
Dependency chains. Most of these eleven calls cannot run in parallel. You cannot fetch the user's location until you have the user's system ID, and you cannot get that until you have queried the asset record. Your code has to manage this sequencing explicitly, every time.
Error handling at every step. If call five fails, your integration must decide whether to retry, skip, return partial data, or restart the whole sequence. That decision logic has to be written, tested, and maintained for every call in the chain.
Client-side assembly. After all eleven calls complete, your integration assembles the final response: flattening nested structures, renaming fields, handling missing values. None of this solves a business problem. It exists purely to compensate for how the data was returned.
Ongoing maintenance. When ServiceNow updates a table structure or your data model evolves, the orchestration code has to be reviewed and potentially rewritten. The complexity does not stay constant. It compounds.
The result is integration code that is harder to write, harder to test, and harder to maintain than the actual business requirement would demand.
What Squid Does Instead
Squid approaches the problem from a different direction.
Instead of asking peripheral systems to understand ServiceNow's internal table structure, Squid lets you define what a complete response should look like through configuration. Relationship traversal, data assembly, and response formatting all happen on the server side. The peripheral system receives one structured JSON response and uses it.
For the laptop example, that single Squid request returns: hardware data, resolved asset details, assigned user, both locations, manufacturer, model, CI relationships, parent CI, service, and network ports, including nested references like assigned_to.location and model_id.manufacturer. One call. All data.
The peripheral system does not need to know which tables those values came from. It does not manage call dependencies. It does not handle partial failures across a chain. It receives complete data and gets on with its job.
Squid includes over 200 pre-built configuration patterns for common CMDB scenarios. Teams do not need to build these from scratch.
The Switch Is Simpler Than You Might Expect
Squid installs from the ServiceNow Store in 90 minutes. Most integrations can be configured using existing patterns without writing any code. Straightforward data requirements are covered in minutes. More complex queries spanning multiple tables take around half a day of configuration.
The Table API has its place. For simple, single-table queries or exploratory work, it is the right tool. But when your peripheral systems need complete, assembled records built from ServiceNow's relational data model, chaining eleven API calls per request is not the right architectural choice.
Squid is.
See the full comparison for yourself. Review the Table API versus Squid technical documentation with the complete 11-call breakdown and a working example of the equivalent single Squid request.