When working with Wix APIs, you'll notice that some APIs provide a mix of search, query, or list methods. Understanding the differences between these methods will help you choose the most appropriate one for your use case.
All three methods retrieve collections of items, but they're optimized for different scenarios:
Feature | Search | Query | List |
---|---|---|---|
Purpose | Discovery and exploration | Efficient filtered data access | Basic collection access |
Complexity | Complex | Moderate | Simple |
Consistency | Eventually consistent, higher latency for availability of created and updated records than list | Eventually consistent, higher latency for availability of created and updated records than list | Eventually consistent, lower latency |
Result Count | Includes total count automatically in the first page | Not included; separate count endpoint may be available | Not included; separate count endpoint may be available |
Filtering | Advanced text and field-based filtering | Extensive field-based filtering | Limited field-based filtering |
Sorting | Flexible field-based sorting | Flexible field-based sorting | Limited, often predefined options |
Aggregations | Supported | Not supported | Not supported |
Free-text Search | Supported across multiple fields | Not supported | Not supported |
Performance | Optimized for search capabilities | Optimized for sorting and filtering | Good performance for simple queries |
Pagination | Cursor-based for efficiency, offset/limit may be available | Cursor-based for efficiency, offset/limit may be available | Cursor-based for efficiency, offset/limit may be available |
Search methods typically have these features:
Advanced text search capabilities across multiple fields.
Support for both structured filtering and free-text search.
Fuzzy matching for spelling tolerance and typo forgiveness.
Phrase matching for exact sequence detection.
Field boosting to prioritize matches in specific fields.
Automatic total result counting with the first page of results.
Complex aggregation capabilities:
Facet generation for filtered navigation interfaces.
Higher latency compared to List methods.
Designed for discovery-oriented user experiences.
Suitable for building search boxes, filters, and exploratory interfaces.
Often supports highlighting of matched text in results.
REST: POST endpoints with comprehensive JSON configuration bodies.
Support for complex filtering expressions with logical operators. Common operators include:
Expression type | SDK | REST |
---|---|---|
Equal to | eq() | $eq |
Not equal to | ne() | $ne |
Greater than | gt() | $gt |
Greater than or equal to | ge() | $gte |
Less than | lt() | $lt |
Less than or equal to | le() | $lte |
In a specified list | in() | $in |
Field exists check | exists() | $exists |
String starts with | startsWith() | $startsWith |
Query methods typically have these features:
Field-specific sorting with direction control.
Efficient cursor-based pagination for handling large datasets.
Often allows multiple filter conditions to be combined.
Optimized for low-latency data access patterns.
No support for text search or aggregations.
REST: HTTP POST endpoints with a JSON request body.
Support for complex filtering expressions with logical operators. Common operators include:
Expression type | SDK | REST |
---|---|---|
Equal to | eq() | $eq |
Not equal to | ne() | $ne |
Greater than | gt() | $gt |
Greater than or equal to | ge() | $gte |
Less than | lt() | $lt |
Less than or equal to | le() | $lte |
In a specified list | in() | $in |
Field exists check | exists() | $exists |
String starts with | startsWith() | $startsWith |
List methods typically have these features:
When choosing between search, query, and list methods for your data retrieval needs, use decision tree below to guide you to the most appropriate method based on your data retrieval needs, and your requirements for data freshness, filtering complexity, and caching.
These examples illustrate common applications for both methods in the Payment Links API.
A business may want to identify all test payment links and check what types of tests were run.
A business may want to review all payment links for premium offerings to ensure the most recent links reflect current marketing strategies.
You can retrieve a list of payment links filtered by a specific price range and sorted chronologically by creation date with the following call:
A business needs to display a list of all their payment links in a dashboard with page navigation.