Norce Commerce Query is an API based on the OData V4 standard. It enables integrated solutions to fetch data directly from Norce's data layer. This page provides a technical overview, including authentication, usage patterns, and best practices for working with the API.
The full API reference documentation is available at:
API Reference: Norce Commerce Query
Norce Commerce Query uses OData v4 over RESTful HTTP. All API calls must use HTTPS to ensure secure communication.
Norce Commerce Query requires OAuth2 authentication. Credentials are managed in the Norce Admin UI.
For details, see: Accessing APIs with OAuth2 accounts.
Important:
- All API calls must use HTTPS.
- You must include an
applicationId(orapplication-id) header.
applicationId(orapplication-id): Integer. Specifies the application context for the API call. For most queries, the specific application does not affect the data returned.
The API uses standard HTTP status codes to indicate the result of requests.
Norce Commerce Query is a read-only API. All OData operations for writing or modifying data are disabled.
The OData standard is widely supported. You can access Norce Commerce Query from browsers, code, or third-party tools.
For .NET environments, Norce recommends Simple.OData.Client.
To find a client for your language, search for “OData client <language/environment>”.
Norce Commerce Query organizes its methods into namespaces. Each namespace groups related data and has its own caching recommendations.
| Namespace | Description | Cache Recommendation |
|---|---|---|
| Core | Master lists shared by all clients (e.g., Countries, Currencies, VatCodes, SalesAreas). | Cache for a long time. |
| Application | Application-specific master data (e.g., suppliers, parametrics, categories). | Cache for a long time. |
| Customers | Customer, company, and account management data. | Cache for a while. |
| Products | Product data, supplier products, prices, inventory. | Cache for a while. |
| Orders | Orders, baskets (quotations), invoices, delivery notes. | Cache for a while. |
| Reporting | Data for reports, including sales and legacy reports. | Cache for a while. |
| Shopping | Recurring orders and delivery methods. | Short cache time. |
When fetching related data (lookups), avoid querying for each row individually. Instead, fetch lookup data as a single list and perform in-memory lookups.
Avoid complex joins. Instead, split complex queries into multiple simpler queries. For example, to get a price list name for an order item:
- Fetch the order row to get the price list ID.
- Fetch the price list details separately.
- Cache lookup data in memory for performance.
Cache data from the Application and Core namespaces for longer periods, as this data changes infrequently. Adjust cache duration based on the namespace and data volatility.
Try out example queries using our Postman Collection.
See How to Use Postman Examples for guidance.