Querying QuickBooks Desktop Customers by Modified Date Through the IPP .NET Dev Kit

QuickBooks Desktop integrators working with the IPP .NET Dev Kit have run into a gap between what Intuit Data Services exposes and what the desktop SDK supports when filtering customers by date range — and the workaround is not obvious from the toolkit’s surface-level API.

The Problem

Developers building integrations against QuickBooks Desktop through the IPP .NET Dev Kit frequently need to pull only the customer records created or modified within a specific date window. Intuit Data Services natively supports this kind of filtering through StartCreatedTMS and EndCreatedTMS parameters, which let a query restrict results to objects falling inside a bounded time range.

The confusion arises because the .NET Dev Kit prominently surfaces a property called CDCAsOf — tied to Intuit’s Change Data Capture mechanism — while the StartCreatedTMS and EndCreatedTMS filters appear to be hidden or inaccessible at first glance. Integrators are left wondering whether the toolkit simply does not support date-range queries for desktop, or whether those properties exist somewhere deeper in the object model.

What’s Actually Happening

The properties are not missing. They are available through the query object’s Items and ItemsElementName arrays rather than as standalone, named properties on the query class. This design pattern — where multiple optional filter criteria are packed into parallel arrays — is easy to overlook if a developer is browsing the object model expecting conventional property accessors.

The CDCAsOf property serves a different purpose: it retrieves all records that have changed since a single point in time, which is useful for incremental syncs but does not give you a bounded range. For scenarios where you need records from a specific window — say, all customers created during a particular fiscal year — StartCreatedTMS and EndCreatedTMS are the correct tools.

The Accepted Solution

The community-verified answer involves constructing a customer query object and explicitly populating two parallel arrays: one that names which filter elements to apply, and one that supplies the corresponding values. Here is the implementation pattern that was confirmed working against QuickBooks Desktop:

The key details:

• ItemsElementName is an array of enum values (of type ItemsChoiceType4 in this context) that tells the serializer which filter fields you are populating. You list StartCreatedTMS and EndCreatedTMS here to activate both bounds of the date range.
• Items is a parallel object[] array carrying the actual values, positionally matched to the element names. The first DateTime corresponds to StartCreatedTMS; the second corresponds to EndCreatedTMS.
• **** on the query object sends the request through the active service context and returns the typed result set, which you can materialize into a list with the standard LINQ call.

Why This Trips Developers Up

The parallel-array pattern is a consequence of how the Dev Kit’s generated classes map to the underlying query schema. Rather than exposing each filter as a discrete property — which would be more intuitive — the toolkit funnels them through the shared Items/ItemsElementName mechanism. This is consistent across several query types in the Dev Kit, so once a developer recognizes the pattern, the same approach applies to filtering other QuickBooks entities (vendors, employees, invoices, and so on) by date or by other supported criteria.

One thing to keep in mind: StartCreatedTMS and EndCreatedTMS filter by the record’s creation date, not its last-modified date. If the goal is to find customers whose records were edited within a window — not just newly created ones — the equivalent modified-date filters would need to be used instead, following the same array-population pattern with the appropriate enum values from ItemsChoiceType4.

For developers maintaining QuickBooks Desktop integrations that depend on date-bounded queries, this approach provides a reliable path without falling back to pulling the full customer list and filtering client-side.