CORE CONCEPT

Query & Filtering

Master server-side filtering with 11 powerful operators to query data precisely across all 7G API GET endpoints.

For HTTP/REST users: Use query strings with dot operator syntax like ?Name.contains=SMSF

For .NET SDK users: Use FilterField<T> objects with strongly-typed properties like filter.Name = new FilterField<string> { Contains = "SMSF" }

Both approaches support the same 11 operators - the concepts below apply universally regardless of integration path.

Quick Reference

3 Operator Categories, 11 Total Operators

🔄

Comparison Operators (4)

Equal, NotEqual, In, NotIn

Work with all types (int, string, DateTime, DateOnly)

HTTP: ?BizEntityTypeID.equal=4

SDK: filter.BizEntityTypeID = 4 (implicit)

📊

Range Operators (4)

GreaterThan, GreaterThanOrEqual, LessThan, LessThanOrEqual

Work with numeric and date types only

HTTP: ?CreatedDate.greaterThan=2024-01-01

SDK: filter.CreatedDate = new FilterField<DateTime> { GreaterThan = date }

🔤

Text Operators (3)

Contains, StartsWith, EndsWith

Work with string fields only (case-insensitive)

HTTP: ?Name.startsWith=Smith

SDK: filter.Name = new FilterField<string> { StartsWith = "Smith" }

All filtering happens server-side - only matching records are returned from the database.

Why This Matters

Server-side filtering returns only matching records from the database, reducing bandwidth and improving performance through optimized indexes. Never retrieve all records and filter client-side.

💡

The Filtering Principle

The 7G API performs filtering at the database layer before building responses. Specify filter criteria in your request (HTTP query string or SDK filter object), and only matching records are returned. Never retrieve everything and filter client-side.

How It Works:

Client sends request with filter criteria
API translates filters to SQL WHERE clauses
Database executes query with optimized indexes
API builds response containing ONLY matching records
Client receives filtered results ready for use

Comparison Operators (4)

These operators work with all data types: integers, strings, dates.

Operator	HTTP (camelCase)	SDK (PascalCase)	Description
`Equal`	`equal`	`Equal`	Exact match
`NotEqual`	`notEqual`	`NotEqual`	Exclude exact match
`In`	`in`	`In`	Match any value in list
`NotIn`	`notIn`	`NotIn`	Exclude all values in list

Examples:

json

# Equal
GET /BizEntity?BizEntityTypeID.equal=4

# In (multiple values - OR logic)
GET /BizEntity?BizEntityTypeID.in=1,2,4

# NotEqual (exclusion)
GET /BizTransaction?BizTransactionStatusID.notEqual=0

# NotIn (exclude multiple values)
GET /BizEntity?BizEntityTypeID.notIn=5,6,7

Multiple Ways to Use In and NotIn (SDK)

The SDK provides 4 syntax options for In/NotIn operators with multiple values. All methods are functionally equivalent - choose based on your preference:

json

// Implicit conversion: array → In operator
var filter = new BizEntityFilter
{
    BizEntityTypeID = new[] { 1, 2, 4 }  // Automatically becomes .In
};

var response = await client.BizEntity.GetAsync(filter);

// This is the recommended approach for most scenarios

Which Method to Use?

Implicit (Array): Simplest for most cases - recommended for readability
Explicit FilterField: Clear and explicit - good for complex filters
Extension Methods: Fluent API style with params syntax - convenient for value types
Direct Assignment: Useful when working with nullable arrays or LINQ queries

Range Operators (4)

These operators work with numeric and date types only.

Operator	HTTP (camelCase)	SDK (PascalCase)	Description
`GreaterThan`	`greaterThan`	`GreaterThan`	Value > threshold
`GreaterThanOrEqual`	`greaterThanOrEqual`	`GreaterThanOrEqual`	Value >= threshold
`LessThan`	`lessThan`	`LessThan`	Value < threshold
`LessThanOrEqual`	`lessThanOrEqual`	`LessThanOrEqual`	Value <= threshold

Examples:

json

# Greater than (after date)
GET /BizEntity?CreatedDate.greaterThan=2024-01-01T00:00:00Z

# Less than or equal (up to date, inclusive)
GET /BizEntity?CreatedDate.lessThanOrEqual=2024-12-31T23:59:59Z

# Date range (combine greaterThanOrEqual + lessThanOrEqual)
GET /BizEntity?CreatedDate.greaterThanOrEqual=2024-01-01T00:00:00Z&CreatedDate.lessThanOrEqual=2024-12-31T23:59:59Z

# Numeric range
GET /BizTransaction?Amount.greaterThanOrEqual=1000&Amount.lessThan=5000

Text Operators (3)

These operators work with string fields only and are case-insensitive.

Operator	HTTP (camelCase)	SDK (PascalCase)	Description
`Contains`	`contains`	`Contains`	Substring match (case-insensitive)
`StartsWith`	`startsWith`	`StartsWith`	Prefix match (case-insensitive)
`EndsWith`	`endsWith`	`EndsWith`	Suffix match (case-insensitive)

Examples:

json

# Contains (case-insensitive substring)
GET /BizEntity?Name.contains=SMSF

# startsWith (prefix match)
GET /BizEntity?AccountNumber.startsWith=7G-

# endsWith (suffix match)
GET /BizEntity?AccountNumber.endsWith=-2024

# Combine text operators with other filters
GET /BizEntity?Name.contains=Super&BizEntityTypeID.equal=4&AccountNumber.startsWith=7G-

Performance Note

Text operators (especially Contains) scan string values and may be slower on very large datasets. Combine with other filters (like BizEntityTypeID) to narrow results before applying text searches.

🔀

HTTP vs SDK Syntax Comparison

Same operators, different expression syntax

HTTP: Query String Dot Notation

json

# Single filter
GET /BizEntity?BizEntityTypeID.equal=4

# Multiple filters (AND logic)
GET /BizEntity?BizEntityTypeID.equal=4&Name.contains=SMSF&CreatedDate.greaterThan=2024-01-01

# In operator (comma-separated values)
GET /BizEntity?BizEntityTypeID.in=1,2,4

SDK: FilterField<T> Objects

json

// Single filter
var filter = new BizEntityFilter
{
    BizEntityTypeID = 4  // Implicit conversion → Equal
};

// Multiple filters (AND logic)
var filter = new BizEntityFilter
{
    BizEntityTypeID = 4,  // Implicit conversion
    Name = new FilterField<string> { Contains = "SMSF" },
    CreatedDate = new FilterField<DateTime> { GreaterThan = new DateTime(2024, 1, 1) }
};

// In operator (explicit)
var filter = new BizEntityFilter
{
    BizEntityTypeID = new FilterField<int> { In = new[] { 1, 2, 4 } }
};

var response = await client.BizEntity.GetAsync(filter);

SDK Implicit Conversions

Single value: filter.BizEntityTypeID = 4 → Automatically becomes Equal

Array: filter.BizEntityTypeID = new[] { 1, 2, 4 } → Automatically becomes In

🔗

Combining Filters (AND Logic)

Build complex queries with multiple conditions

Multiple filters on different fields use AND logic - all conditions must match.

Examples:

json

# Multiple filters combined with AND logic
GET /BizEntity?BizEntityTypeID.equal=4&BizEntityStatusID.equal=1&CreatedDate.greaterThan=2024-01-01T00:00:00Z

# Result: Active SMSF entities (type, status) created after Jan 1, 2024
# All three filters must match for a record to be included

Multiple Operators on Same Field:

json

# Range query on same field
GET /BizEntity?AccountID.greaterThan=1000&AccountID.lessThan=5000

# Result: Accounts with ID between 1001 and 4999

OR Logic with In Operator:

json

# OR logic using 'in' operator
GET /BizEntity?BizEntityTypeID.in=1,2,4

# Result: Entities where type is (Individual, Company, SMSF)

Logic Rules

AND logic - All filters must match for a record to be included
OR logic - Use the in (HTTP) or In (SDK) operator for a single field
Complex OR - Make multiple API calls and merge results client-side (API doesn't support OR across different fields)

✅

Best Practices

Guidelines for effective server-side filtering

Use server-side filtering instead of retrieving all records and filtering client-side
Combine multiple filters for precise queries (AND logic automatically applied)
Use in operator for OR logic on a single field (e.g., BizEntityTypeID.in=1,2,4)
Leverage exact matches (equal) when possible for best performance
Filter by type/status FIRST, then add text searches to reduce dataset before substring matching
Combine filtering with pagination to handle large result sets efficiently

Avoid

Retrieving thousands of records then filtering client-side (bandwidth waste)
Using Contains on large datasets without other filters (performance cost)
Multiple sequential requests when filters can be combined
Case-sensitive comparisons (all text operators are case-insensitive)
Building complex OR logic across different fields (API doesn't support - make multiple calls)