Datapel API

## Sections
• [Datapel API Reference](https://app.theneo.io/datapel/datapel-api/datapel-api-reference.md): Welcome to the API Reference for the Datapel Cloud.WMS Inventory Management System (IMS), a powerful and versatile tool designed to streamline the management of order and inventory data for businesses of all sizes. This documentation serves as your comprehensive guide to understanding and use of our API, providing you with the information and resources needed to integrate our system seamlessly into your applications and processes. Why an Inventory Management System Matters Efficient order and inventory management is the cornerstone of successful business operations. Whether you are a small wholesaler, a manufacturing powerhouse, or an e-commerce giant, the ability to track, monitor, and control your inventory is essential for reducing costs, improving customer satisfaction, and driving profitability. Our Inventory Management System is designed to simplify this complex task, offering real-time insights, process automation, and scalability. What Can You Achieve with Our API The Datapel API opens up many possibilities for developers, businesses, and entrepreneurs seeking to optimise their inventory and order management processes. Here are some potential applications and use cases that can and have been developed using our API: E-commerce Integration Seamlessly sync your e-commerce platform with our WMS to ensure accurate product availability and pricing on your online store. This leads to fewer out-of-stock situations and enhances the overall shopping experience for your customers. Warehouse Automation Implement robotic or IoT solutions to automate inventory movement within your warehouses. Our API provides real-time inventory data, enabling robots or devices to make informed decisions about restocking and retrieval. Multi-Location Management Manage inventory across multiple physical locations, whether they are warehouses, retail stores, or distribution centres. Our API allows you to centralise inventory control and maintain consistency across your network. Customer and Supplier Collaboration Facilitate better communication with your customers and suppliers by sharing real-time inventory data. Suppliers can use this information to optimise production schedules and ensure timely deliveries, reducing the risk of stockouts. Customers can check availability and account status reducing overall customer servicing costs. Inventory Forecasting Utilise historical data and predictive analytics to forecast demand and optimise inventory levels. With our API, you can build custom forecasting algorithms and strategies to minimize overstock and understock situations. Order Fulfillment Automation Create systems that automate order fulfillment processes, ensuring orders are picked, packed, and shipped efficiently, with real-time inventory updates for customers. Inventory Reporting and Analytics Develop custom dashboards and reporting tools to gain valuable insights into your inventory performance. Track key metrics such as turnover rate, holding costs, and sales velocity. Inventory Auditing and Compliance Implement auditing solutions that use the IMS API to verify inventory accuracy and compliance with industry regulations. This is especially crucial in sectors with strict quality control requirements. Inventory Optimization Algorithms Design algorithms that automatically optimise inventory reorder points, safety stock levels, and economic order quantities based on real-time market conditions. Retail Shelf Management Optimise the placement of products on store shelves by utilising our API to ensure high-demand items are always readily available, leading to increased sales. The Cloud.WMS API empowers you to take control of your inventory and order management processes and drive operational excellence across your business. Whether you are looking to enhance the efficiency of your supply chain, boost customer satisfaction, or make data-driven decisions, our API is your gateway to achieving these objectives with precision and ease. In this API Reference, you will find detailed documentation, code examples, and best practices to help you harness the full potential of our Inventory Management System API.
  • [How it Works](https://app.theneo.io/datapel/datapel-api/datapel-api-reference/how-it-works.md): Retrieving Data Use the HTTP GET method to retrieve data from your workspace via endpoint resources. This includes both lists and individual records. For example, you would use the GET method to retrieve a list of sales orders made in a particular month, or the contact details of a customer. Successful responses return with a HTTP 200 status code By default all successful responses on the Datapel API are returned as JSON. The API requires a security domain or scope to be provided with TOKEN requests and REFRESH, for public api resources use pub . Forms and Reports can also be returned in PDF format ensure you apply the correct content type header when required. Example GET request for a particular product would look like this → https://api2.datapel.net/api.datapel/v2.0/pub/product?34 JSON responses and date formats By default JSON formatted responses are returned, be sure to use the http header “application/json” when making a request. Any Date returned in JSON datasets is UTC format represented as YYYY-MM-DDTHH:mm:SS , for example ‘ 2009-04-29T10:12:20’. In order to reduce overall data transfer requirements a record level TIMESTAMP is typically available with format ‘2 021-10-01 16:35:03’ indicating the time this record was last modified . Filtering Data The Datapel API uses the OData standard as the syntax allowing queries of specific data records. By using OData filter queries, you can obtain specific subsets of data, reducing the amount of unnecessary information and enhancing the performance of your workflows. When using filters, you can use comparison operators like eq for equals , ne for not equals , and so on. You can also use logical operators such as and , or , and not to combine multiple conditions. Additionally, there are functions to refine string-based searches. For example, startswith(fieldName,’string’) checks if a field starts with a specified string, endswith(fieldName,’string’) checks if it ends with one, and substringof(‘string’,fieldName) verifies if a field contains a particular substring. To explore the syntax and example queries review the OData Standards Support section of this reference guide. Pagination A single HTTP GET request can return at most 500 records. This is reasonable because most HTTP clients have a timeout limit of 2 - 5 minutes. They do not allow transactions to wait more than that. A request running longer than the limit gets an HTTP timeout error. Therefore, it is often required to tune complex queries and lower the data size for them to complete within the timeout restriction. Long running queries can also degrade server response times to other users and tenants so its best practice to do smaller queries more often than large one off data requests The OData API provides several pagination options for query results. Client-side pagination uses query options on the client side to create an offset that restricts the amount of data returned from the server. A client-side pagination query can be made using the following URI parameters: The $top parameter indicates the number of records to return in the batch. The default and maximum number is 500 records. The $skip parameter indicates the number of records in the full data set to skip before fetching data. For example, a query with $skip=2000&$top=500 returns the fifth page of data where the page size is 500. Advantages Faster initial page load It works well with OData compliant list and table web controls to fetch records on demand. DevExtreme UI controls from DevExpress automatically change the $skip value in order to scroll through the data set. It allows reverse scrolling by decreasing $skip values. This allows UI controls to avoid buffering all data as the user scrolls up and down. Considerations when using OData pagination For each page, the query is re-executed and then moves forward through the data set to reach the specified $skip value. Not only is this inefficient but also it can lead to unstable results. The data set could be changing due to simultaneous creating, updating, or deleting of the data. Conversely, most modern databases implement caching and will generally store prior query data so this does not present as a major limitation or issue. If a record is inserted on a prior page after it has been read, it shifts the data set to the right, resulting the last record from the previous page to be pushed into the current page. This causes the page to be read again because the $skip value of the current page is one record too small, resulting in duplicates in the total data set. You can avoid this issue using $orderBy=TimeStamp to push newly created records to the end of the data set. If a record is deleted from a prior page after it has been read, it shifts the data set to the left. The first record of the current page is lost because the $skip value of the current page is one record too large. There’s no good workaround when dealing with concurrent hard deletes from the data set. Note these potential data loss issues make "last modified since" queries especially unreliable. If a record is lost in a query, it can only be picked up by a later attempt after it's modified. Most queries will return a total record count which allows your request to select a exact page number, and identify the total number of pages to retrieve. Alternatively continue to iterate over the query using the $skip keyword until no records or less than 500 (page maximum) are returned.
  • [OData Standards Support](https://app.theneo.io/datapel/datapel-api/datapel-api-reference/odata-standards-support.md): What is OData? OData is a way to query data sources over the web using a standard syntax. It allows requesting of specific data columns with filter expressions to return required data sets typically in JSON format. Because the OData specification is standardised and ISO/IEC approved, you can theoretically use any OData compliant data source and it will respond in the same way to an OData formatted query. Parameters are made up of the various OData functions for selecting and filtering entities. The main OData functions are: $select $expand $filter $orderBy $top $skip $apply These parameters are chained together after the entity using '&' : Get the country and company name of all customers where country is 'UK' - http://services.odata.org/Northwind/Northwind.svc/Customers/?$select=CompanyName,Country&$filter=Country eq 'UK' $filter Filters allow you to reduce the data set by specifying a field and a requirement. There are 2 formats for filter: $filter=[Field Name] [Operator] [Value] $filter=([Field Name] [Operator] [Value]) The correct format to use depends on the operator you are using. Operators for first format: eq - Exactly equal to ne - Inverse of eq lt - Less than but not including gt - Greater than but not including le - Less than or exactly equal to ge - Greater than or exactly equal to Operators for second format: contains - Value is contained somewhere in the field not contains - Inverse of contains startswith - Field starts with value not startswith - Inverse of startswith endswith - Field ends with value not endswith - Inverse of endswith There are other more specific expressions which you can find at the Microsoft Documentation on filters. Filters can be chained together internally with 'and' or 'or' to create more complex expressions: $filter= ([Field] [Operator] [Value]) or/and ([Field] [Operator] [Value]) The in (v1,v2,v3…vN) keyword is not supported, you need to create an expanded filter as (Field eq v1) or (Field eq v2) or … (Field eq vN) where N should be less than 500 . Field Name references and Array $filter The convention for field name referencing is based on the JSON response property name. There are some limitations on the scope of filtering by field name and on how the response is returned. Field name paths are only support for first level child nodes where the property name is not unique, in all other cases child node path is not required. Matching scope $filter restrictions for APIv2: primary node field names are always valid as field names child node field names are valid only if they are unique within the entire response any non-unique child nodes must be qualified using OData field name paths for example $filter=SellingTaxCode/Code eq ‘GST’ $filter on field names within an Item Array are never valid, for example the JSON response form as below ArrayElementFieldName cannot be referenced directly using a comparison operator and if attempted will not return a valid result. Select... { “FieldName1” : “value1”, “Items” : [ { “ArrayElementFieldName” : “arrayValue1” }, … ], "FieldName2" : “value2”, … } $filter on fields contained within an Item array need to be handled using string search techniques, for example to return all Items that contain arrayValue1 the filter expression would be defined as $filter=contains(Items, ‘arrayValue1’) Note also that while the parent elements are returned only the matching item array lines will be returned, if you require all i tem Array elements it is recommended that a two pass query approach be applied. Use the $select=Uid&$filter=contains(Items,'…') , then query on the array of Uid response elements as $filter=Uid eq value1 or Uid eq value2 … When filtering on child nodes path elements are only valid to one level, for example $filter=parentnode/childproperty eq ‘value1’ is valid, where the following is not valid as $filter=parentnode/childnode/childproperty eq ‘value1’ $orderBy The orderBy function allows you to specify a sort for your data. The syntax for this is: $orderby=[Field Name] [Direction] Direction is either ascending or descending as shown in these examples: Every Product ordered by release date - http://services.odata.org/V4/OData/OData.svc/Products/?$orderby=ReleaseDate asc Summary of sales by year, largest subtotal first - http://services.odata.org/Northwind/Northwind.svc/Summary_of_Sales_by_Years/?$orderby=Subtotal desc $top and $skip Top and Skip tend to go hand in hand. Top can be used to limit the number of records returned, while skip allows you to start from further down your list of results. In order to create PAGED results use the top keyword to specify the number of records and skip * page * number of records per page to get the a particular page in the result set. The syntax for these is: $top=[number] $skip=[number] Some examples: Get the first 50 Contacts, skipping the first Contact - http://services.odata.org/V4/OData/OData.svc//Contacts?$top=50&$skip=1 First 5 Products ordered by release date - http://services.odata.org/V4/OData/OData.svc/Products/?$orderby=ReleaseDate asc&$top=5 The 10 biggest sales - http://services.odata.org/Northwind/Northwind.svc/Summary_of_Sales_by_Years/?$orderby=Subtotal desc&$top=10 OData Limitations Datapel API Supports basic OData syntax for keywords select, filter, skip, top, order by and apply. Currently it does NOT support expand and lambda operators. $filter limited support All logical operators except has and in are supported. Spec: http://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part2-url-conventions.html#sec_LogicalOperators Examples: http://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part2-url-conventions.html#sec_LogicalOperatorExamples Grouping filters using () is supported. Spec: http://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part2-url-conventions.html#sec_Grouping String functions startswith, endswith and contains are supported. Spec: http://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part2-url-conventions.html#sec_StringandCollectionFunctions . DateTime functions date, time, year, month, day, hour and minute are supported. Spec: http://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part2-url-conventions.html#_Toc31360996 $apply limited support (aggregations) Aggregations using Odata apply query option is supported. Spec: http://docs.oasis-open.org/odata/odata-data-aggregation-ext/v4.0/odata-data-aggregation-ext-v4.0.html Transformations: filter, groupby and aggregate are supported. expand, concat, search, top, bottom are NOT supported. sum, min, max, avg, countdistinct and count are supported. $filter field names MUST BE included in the groupby column name selection list, calculated fields can be used in the filter expression, using the example below $filter= Total gt 0 Example Select... \orders?$apply=groupby((Country),aggregate(Amount with sum as Total,Amount with average as AvgAmt)) is the equivalent of the below in SQL for clarity and reference Select... SELECT [Country], Sum(Amount) AS Total, Avg(Amount) AS AvgAmt FROM [Orders] GROUP BY [Country]
  • [OData Web Components](https://app.theneo.io/datapel/datapel-api/datapel-api-reference/odata-web-components.md): To simplify web application development OData compliant web components can bind directly to the API endpoint services. For example the DevExpress DevExtreme javascript visual components have OData 2.0 and 4.0 compatible controls. DevExtreme supports a multitude of frameworks including KnockOut, Angular, React and others. The primary adapter for the API was selected as OData to align with the Microsoft Web Services Stack and the ability to standardise the filtering and selection syntax that simplifies SQL translation. For general information on OData compliance https://www.odata.org/ For more information on DevExtreme Web Components please refer to the following https://js.devexpress.com/ On OData refer to https://js.devexpress.com/Documentation/Guide/Data_Binding/Specify_a_Data_Source/OData/ For specific connector declaration visit https://js.devexpress.com/Documentation/ApiReference/Data_Layer/ODataStore/
  • [OData Best Practices](https://app.theneo.io/datapel/datapel-api/datapel-api-reference/odata-best-practices.md): Read and follow the best practices in this topic for optimal OData API performance and a better user experience. Query Only Modified Records Instead of querying all records, query only the records that have been modified since your last execution for integration use cases. Avoid Frequent Query Runs to Get Real-Time Results Repeating queries in much less than one hour will consume too much API resource, which may be throttled in the future. In extreme cases, you may even be denied of service because of frequent queries, especially ones that require heavy backend processing. Avoid Excessive Queries for Single Records Querying records one at a time doesn’t take advantage of database optimisation capabilities. Singleton queries are often used to perform in-memory joins and should be avoided whenever possible. For example: Select... &$filter= <key> eq <keyvalue> Use $select to Get Only the Properties You Need Without the $select query option, a query returns all available properties of an entity. For better performance, we recommend that you add the $select system query option to specify only the properties you need. Keep Transactions Simple to Avoid Poor Performance Poor performance is often a sign of misuse of APIs. As a rule of thumb, always keep your transactions simple. Sync Frequently and Sync Only Delta Changes Full data sync can lead to high resource consumption and poor performance. Instead of doing a full data sync intermittently, schedule more frequent data sync but limit the scope to only delta changes. Keep in mind the current limits for the public api are 10,000 requests per day with not more than 2 requests per second. Implement Retry Logic Properly Retry logic can help recover failed transactions due to Internet connectivity or backend server issues, but retry must be attempted with caution based on the type of HTTP error. In all cases, wait at least between 1 to 5 minutes before attempting a retry. Excessive immediate retry can cause denial of service giving little time for the server to recover. Retry no more than 5 times before abandoning your task. Error types eligible for retry: Note 503 Service Not Available can occur when a server is overloaded. It can also occur during maintenance periods. Avoid running queries during these published maintenance periods. HTTP timeout errors can be retried only if your client timeout matches the infrastructure timeout of 5 minutes. If you retry a timeout before this period, you're stacking transactions on top of each other and performing a possible denial-of-service attack. HTTP connection reset error and no response are given from server side. 429 Too Many Requests can occur if you have reached your quota or making too many concurrent requests. In this case you should check for response to see if your Total Request count exceeds the daily limit, or if this is a throttling response. Typically wait a few seconds and try the request again. Select... { "status" : "error", "message" : "Too many requests", "data" : "Total Requests 12000", "error" : { "code":"429", "message": { "lang":"en-us", "value": "Request rate must not exceed 1 per second or 10,000 per 24 hours." } } } Errors for which retry shouldn’t be attempted: 401 Authentication Failed error. You have provided incorrect credentials and retrying doesn't help. 404 Not Found error. You can't recover something that doesn’t exist. 400 Bad Request error. This error can occur for edit operations that are missing required data or have incorrect formats. Do not retry POST operations without doing a GET request to check if the payload was accepted with a failed response. Otherwise rePOSTing can result in duplicate data. Avoid Excessive Client Multithreading To prevent server overloads and ensure high availability, we recommend a limiting the use of concurrent API requests for any company instance. If you require a real time, high duty integration you may need to discuss and Enterprise API option which removes daily quota and rate limits String Encoding on POST As APIv2 has some backward compatibility with XML payload formats it is a requirement to Escape Special XML characters Select... "tREMOTETransSaleLines": [ { "LineNumber": "1", "Code": "Widget", "HostCode": "", "LineDescription": "Time & Time Again Tool", "LineNote": "Blue >> large", … Special character escaped form replaced by Ampersand & & Less-than < < Greater-than > > Quotes \" " Return, Linefeed, Tab \r \n \t Ascii( 13,10,9 ) Single Quote (no escaping required) ' '
• [Authentication](https://app.theneo.io/datapel/datapel-api/authentication.md): Bearer Token Authentication Datapel API version 2.0 uses Bearer Token Authentication, a crucial security mechanism that safeguards our API endpoints and ensures secure communication between clients apps and our API servers. This section describes what Bearer Token Authentication is, how it works, and how to manage secure API access. Bearer Token Authentication is a widely adopted method for securing APIs, relied upon by countless applications and services across the internet. It offers a robust, standardized approach to verifying the identity of clients attempting to access an API resource. With Bearer Token Authentication, you can establish trust between the API server and its clients, ensuring that only authorized parties gain access while keeping unauthorized users at out. In this documentation reference, we will cover the following key topics: Understanding Bearer Tokens: Get acquainted with the concept of bearer tokens, their structure, and how they function as credentials for authenticating your API requests. Token Generation and Management: Learn how we generate, issue, and manage bearer tokens securely, with best practice token lifetimes and refresh mechanisms. Authentication Flow: Understand step-by-step the process of how client apps present bearer tokens in API requests, and how our API server validates these tokens to grant or deny access. The following sections describes our implementation of the Bearer Token Authentication process. Understanding Bearer Tokens Bearer Tokens are at the heart of Bearer Token Authentication, serving as the digital keys that grant access to API resources. What is a Bearer Token? A Bearer Token is a type of access token used in authentication protocols, such as OAuth 2.0 and OpenID Connect. It is a string of characters, typically represented as a long, random alphanumeric sequence. Bearer Tokens act as credentials that a client (usually a user or application) presents to an API server when making a request for a protected resource. How Do Bearer Tokens Work? Bearer Tokens operate on a straightforward principle: possession of the token equals access. When a client wishes to access a protected resource via an API, it includes the Bearer Token in the request, typically within the HTTP Authorization header. The server receives the token, validates it, and if the token is valid and not expired, it grants access to the requested resource. Stateless Authentication One of the advantages of Bearer Tokens is their statelessness. Unlike session-based authentication, where server-side state is maintained for each user, Bearer Tokens require no server-side storage of session data. This makes them highly scalable and suitable for stateless API architectures, such as RESTful APIs. Security Considerations While Bearer Tokens offer an efficient way to authenticate API requests, they come with security responsibilities. Since anyone in possession of a Bearer Token can access the protected resources, it is crucial to protect these tokens from theft and misuse. Security measures include token encryption, short token lifetimes, and token revocation mechanisms. Token Payload Bearer Tokens often contain a payload that carries information about the client or user, such as user roles or permissions. This payload can help your API server make access control decisions based on the token's content. In summary, Bearer Tokens represent the authorization credentials clients use to access an APIs protected resources. Understanding their structure, how they are transmitted, and their security implications is fundamental to implementing secure and efficient API based Application. Token Generation and Management Token generation and management are critical aspects of Bearer Token Authentication. To ensure the security of the Datapel API our tokens are 256 bit encrypted and have a limited life span of 30 minutes. A refresh token is provided to allow trust renewal by following the Refresh Authentication flow. The Bearer Token Authorization flow involves a series of steps that allow a client (such as a user or application) to authenticate itself and gain access to protected resources on our API. This flow is based on the OAuth 2.0 framework and is widely used for securing APIs. Here's a step-by-step breakdown of the typical Bearer Token Authorization flow: Client Registration (Optional): In most cases, our clients need to be registered with API access to our server. During registration, you will receive an API key and secret, which are used to identify and authenticate your application. This step is commonly seen in OAuth 2.0. Authentication Request: Your app initiates the authentication process by sending a request to our API TOKEN endpoint. Token Issuance: The API server processes the token request, verifies identity, and, if everything checks out, issues an access token. This access token is a bearer token, and its purpose is to prove the client's authorization to access protected resources. Included in the token is a refresh token which allows renewed trust access tokens without needing the initial API key or User credentials. Token Usage: The client includes the access token in the Authorization header of its API requests, using the "Bearer" prefix (e.g., "Bearer [access token]"). This token is what grants the client access to the API resources. Token Validation: When the API server receives a request with an access token, it validates the token to ensure it's genuine, unexpired, and has the necessary permissions to access the requested resource. This step often involves checking the token's digital signature, expiration time, and scope. Access Control: If the token is valid, the API server grants the client access to the requested resource. Access control decisions may also be based on the user's identity and the permissions associated with the token. Token Revocation (Optional): To maintain security, tokens can be revoked by either the client or the authorization server when they are no longer needed or if they are compromised. Token Expiration and Refresh (Optional): Access tokens have a limited lifetime. Your application can request a new access token using a refresh token if the original token expires. This helps maintain the session's longevity while minimizing security risks. Logging and Monitoring: Our API has backend monitoring and logging and if required we can assist with troubleshooting any access issues you may experience by reviewing request history.
  • [Token](https://app.theneo.io/datapel/datapel-api/authentication/token.md): Submit User or Developer App credentials for Authentication, if successful returns a Bearer Token. Also used to refresh tokens to allow continued API access without requiring user credentials to be re-validated. Tokens use the JWT form and more information on token structure can be found at https://jwt.io/introduction . To access an endpoint service a valid token must be passed in the Authorization Header parameter. Parameters Parameters required will depend on the grant_type . When getting an initial token you must pass grant_type = password , or to renew the access token you must pass grant_type = refresh_token . Using grant_type=password In the authentication life-cycle this is the first action your application should take in order to establish a trusted connection with our API. The token endpoint requires a username (api-key), password (api-secret), grant_type =password, and a scope parameter. As a general rule you should never store any user provided credentials once granted a valid token and refresh_token, by doing so you can avoid credential theft and maintain a secure trust environment. Exceptions to this include server-side applications where access is direct to the application API over secure HTTPS connection. In any case credentials should never be stored as plain text and should be encrypted using industry standard protocols. You must provide at all the following values in your request to this endpoint: username password grant_type scope authorization Sample Code Here is a sample token request using jQuery. Select... $.ajax({ url: 'https://api2.datapel.net/api.datapel/v2.0/token', type: 'POST', headers: { 'Authorization': 'Bearer', 'Content-Type': 'application/json', 'grant_type': 'password', ‘username’: 'api-username', 'password': 'api-secret', 'scope': 'pub' }), success: function (response) { // Handle the response here console.log(response); }, error: function (error) { // Handle errors here console.error(error); } });
  • [Token Refresh](https://app.theneo.io/datapel/datapel-api/authentication/token-refresh.md): Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope. Access Tokens have a limited lifespan and need to be re-issued on a regular basis. The refresh_token is the mandatory credential used to obtain new access tokens. Parameters To renew the access token you must pass grant_type = refresh_token. This option requires at minimum a valid or expired access_token, refresh_token, grant_type , and scope parameter. The refresh_token option allows you to update an access token without a username and password. If you are connecting to a specific tenant then you MUST INCLUDE the tenantKey within the parameters. You must provide at all the following values in your request to this endpoint: Authorization refresh_token grant_type scope tenantKey (optional)
• [Endpoint Reference](https://app.theneo.io/datapel/datapel-api/endpoint-reference.md): Welcome to the Endpoint Resources Listing section of our API reference. This comprehensive guide provides a detailed overview of all available endpoints and resources within our API. Whether you're a developer looking to integrate our services into your application or an experienced user seeking to explore the capabilities of our API, you'll find everything you need to get started and make the most of our platform. In this section, you will find a structured and organized list of API endpoints, each accompanied by a description of its purpose and usage. We have designed our API with simplicity and flexibility in mind, ensuring that you can efficiently interact with our platform to meet your specific needs. To streamline your development process, we have categorized the endpoints into logical groups and provided clear explanations of the parameters and data formats associated with each resource. Additionally, you'll find information on authentication methods, response formats, and any specific requirements for using particular endpoints. Whether you're retrieving data, creating records, or performing complex operations, this Endpoint Resources Listing is your go-to reference for understanding and utilizing our API effectively. Feel free to explore the endpoints that align with your project's goals and requirements, and use this documentation as your trusted companion on your API integration journey. Please refer to the table of contents or use the search functionality to quickly locate the endpoints and resources that interest you. If you have any questions, encounter issues, or need further assistance, our support team is here to help. When reviewing the Post or Response Body it is recommended to click the expand all option as shown below to display all nodes and properties. Let's dive in and explore the wealth of possibilities our API offers. Happy coding!
  • [Time Stamp](https://app.theneo.io/datapel/datapel-api/endpoint-reference/time-stamp.md): Get the current server date time stamp. This endpoint is used to align server last modified time stamps with local application or client side time zones.
  • [List Items](https://app.theneo.io/datapel/datapel-api/endpoint-reference/list-items.md): Retrieves List Items for Product Categories and Contact Groups
    • [Listitem](https://app.theneo.io/datapel/datapel-api/endpoint-reference/list-items/listitem.md): Retrieves a single Listitem by Uid using singleton format /public/listitem?{ListItemUid}
  • [Ship Methods](https://app.theneo.io/datapel/datapel-api/endpoint-reference/ship-methods.md): Retrieves Shipping Method List Items for Inventory Movement Transactions and Contact Defaults
    • [ShipMethod](https://app.theneo.io/datapel/datapel-api/endpoint-reference/ship-methods/shipmethod.md): Retrieves a single ShipMethod by Uid using singleton format /public/shipmethod?{ShipMethodUid}
  • [Sources](https://app.theneo.io/datapel/datapel-api/endpoint-reference/sources.md): Retrieves Source List Items for Inventory Transactions and Contact Defaults. Sources can be used as a searchable or sortable transaction tag.
    • [Source](https://app.theneo.io/datapel/datapel-api/endpoint-reference/sources/source.md): Retrieves a single Source by Uid using singleton format /public/source?{SourceUid}
  • [Tax Codes](https://app.theneo.io/datapel/datapel-api/endpoint-reference/tax-codes.md): Retrieves Tax Codes for Inventory Transactions, Products and Contact Defaults. Tax Codes are mandatory fields for sale order line items with the default being N-T (no tax).
    • [TaxCode](https://app.theneo.io/datapel/datapel-api/endpoint-reference/tax-codes/taxcode.md): Retrieves a single TaxCode by Uid using singleton format /public/taxcode?{TaxCodeUid}
  • [Job Codes](https://app.theneo.io/datapel/datapel-api/endpoint-reference/job-codes.md): Retrieves Job Codes used for tagging Inventory Transaction Lines. Job Codes are optional fields for order line items with the default being NULL (no code).
    • [JobCode](https://app.theneo.io/datapel/datapel-api/endpoint-reference/job-codes/jobcode.md): Retrieves a single JobCode by Uid using singleton format /public/jobcode?{JobCodeUid}
  • [Audit Events](https://app.theneo.io/datapel/datapel-api/endpoint-reference/audit-events.md): Retrieves system Audit Events used to track workspace activity by system and user actions with timestamp. You may also use the singleton by Uid format /public/auditevent?{AuditEventUid}
    • [Audit Event](https://app.theneo.io/datapel/datapel-api/endpoint-reference/audit-events/audit-event.md): This endpoint is used to post an Audit Event entry into the workspace event list. This endpoint is used to assist external developers to raise issues regarding integration or data validation within the audit list so it can become visible to administrators. POST Body Structure EventType: Fixed field which maybe either {"security","status","warning","error", default is "status" }. EventDetail : Human readable message to assist with audit management or trouble shooting. Limit this field to 200 characters. Never include personal identification information, passwords in this field. Sample Use Cases for Audit Event posts Integrations with Other Applications Data Synchronisation An external data integration tool can log status events related to the synchronisation of data between your system and other external systems. This helps administrators track the success and failure of data sync operations. Select... { "EventType": "status", "EventDetail": "Data sync completed successfully for user ID 98765" } { "EventType": "warning", "EventDetail": "Data validation failed for incoming data from external CRM system" } Low Code Tools Workflow Automation Issues A low code platform can use this endpoint to log issues that occur within automated workflows, such as failed actions or conditional checks that did not pass. This visibility helps in troubleshooting and optimising workflows. Select... { "EventType": "error", "EventDetail": "Workflow -Invoice Approval- failed at step -Send Notification- due to missing email address" } { "EventType": "status", "EventDetail": "Custom application -Inventory Tracker- successfully updated stock levels" } These use cases highlight how the Audit Event POST endpoint can enhance the monitoring and management of integrations, improve security visibility, and support troubleshooting across various platforms and tools.
  • [Product List](https://app.theneo.io/datapel/datapel-api/endpoint-reference/product-list.md): Retrieves a list of Product master items using a filter criteria. Make sure to limit results using the $top directive set to less than the maximum page size of 500 .
    • [Product](https://app.theneo.io/datapel/datapel-api/endpoint-reference/product-list/product.md): Retrieves a single Product by Uid using singleton format /public/product?{ProductUid}
    • [Productudfs](https://app.theneo.io/datapel/datapel-api/endpoint-reference/product-list/productudfs.md): Retrieves Product User Defined Fields (UDFs) and Field Labels
    • [Billofmaterials](https://app.theneo.io/datapel/datapel-api/endpoint-reference/product-list/billofmaterials.md): Retrieves Product Bill of Materials. Property Descriptions ProductUid : A unique identifier for the product. This UID is used to reference the product within the system. Code : The product code. This is typically a human-readable identifier used to reference the product in catalogs and sales documents. IsBought : A boolean indicating if the product is purchased from suppliers. false indicates it is not a bought item. IsSold : A boolean indicating if the product is sold to customers. true indicates it is a salable item. IsInventoried : A boolean indicating if the product is tracked in inventory. true suggests it has inventory records. BuildQuantity : The quantity of the product produced in a single build operation. It reflects how many units of the product are made at a time. IsKitProduct : A boolean indicating if the product is a kit. Kits are typically assembled at the time of sale from individual components. IsAssembly : A boolean indicating if the product requires assembly. true means it is an assembled product, consisting of multiple components. ProductLineUid : A unique identifier for the product line. This is used to categorize products within broader groups. LineNumber : The line number in the Bill of Materials. This represents the order or sequence of components within the BOM. LineQuantity : The quantity of this component required per assembly or kit. UseDescription : A boolean indicating if a custom description is used for this BOM line. true means a custom description is specified. LineDescription : A description of the component or material on this line of the BOM. LineItemCode : The code identifying the component or material on this line of the BOM. SellingUnitMeasure : The unit of measure for selling the product (e.g., "Each"). QuantityPerSellUnit : The quantity of the component or material included per selling unit of the product. BuyingUnitMeasure : The unit of measure for buying the component or material (e.g., "Pack"). QuantityPerBuyUnit : The quantity of the component or material included per buying unit.
    • [Productimages](https://app.theneo.io/datapel/datapel-api/endpoint-reference/product-list/productimages.md): Retrieves Product image URLs
    • [ProductPriceLevels](https://app.theneo.io/datapel/datapel-api/endpoint-reference/product-list/productpricelevels.md): Retrieves a list of products with all available price levels as price levels array.
    • [PriceLevels](https://app.theneo.io/datapel/datapel-api/endpoint-reference/product-list/pricelevels.md): Retrieves a flat array list of available pricing levels by ProductUid.
    • [SpecialPriceContracts](https://app.theneo.io/datapel/datapel-api/endpoint-reference/product-list/specialpricecontracts.md): The Special Pricing Contracts API provides details on the specific pricing contracts established and currently valid for active products and customers. This data includes various pricing and discount terms applicable to different items and the quantity price breaks for the contract period. Special Pricing Contract Schedules (SPS) Cloud.WMS allows setting up special, contract or promotional pricing by item, customer, or groups. It requires specific configuration within the WMS to activate and apply these special pricing rules. Prices are evaluated based on the best available price, prioritising specific customer pricing over group pricing if both are available. Price Contracts : Specify fixed prices for items based on the contract. Unit prices (exc. and inc. tax) are set and are applicable regardless of the general pricing strategy.Typically used when the price of an item needs to be consistent over a period. Discount Contracts : These specify a percentage discount to be applied to the base price of items. The discount percentage can vary based on the quantity purchased. More flexible than fixed price contracts as they adjust based on purchasing volume and can be set to provide bulk purchasing incentives. Calculating Contract Prices Best Price Rule: The WMS attempts to return the best price based on the lowest price available from the configured special pricing strategies. Discount vs. Price: If both discount and fixed price are set, the discount will override the fixed price, applying the discount to the base price of the item. Price Levels: if no special price contracts exist check the Contacts Price Level and select the required item price according to the line quantity.
  • [Inventory List](https://app.theneo.io/datapel/datapel-api/endpoint-reference/inventory-list.md): Retrieves a list of records detailing current available Inventory by item, location, quantity, and unique batch serial number properties. Use $top and $filter directives to limit results to less than the maximum page size of 500 records. Inventory Synchronisation A common use case for IMS integration is reflecting available inventory to external systems, like eCommerce WebStores. To keep inventory quantity levels synchronised between an external system and the Inventory List Endpoint, two strategies can be used based on required synchronisation frequency: either as end-of-day batch or periodically throughout the day or “real-time”. Both strategies leverage the TimeStamp property, which indicates the last modified date-time of inventory records, using this only relevant changes are collected and updated. WebHooks are not supported for this endpoint as typically inventory movement occurs frequently and in some cases across thousands of articles per minute, or in some cases seconds, causing message overflows. Batch Synchronisation For end-of-day or batch synchronisation, the process involves querying the entire inventory list once per day usually after business hours to update the external inventory system with the day's final inventory states ready for the next business day. This strategy is simpler and may be suitable for systems with lower transaction volumes or where real-time inventory accuracy is not critical. Technique: Retrieve All Records: Use the $top directive to fetch records in batches of up to 500 (the maximum page size). Repeat requests as necessary to retrieve all inventory records. Filter by Modification Date: If supported by the endpoint, use the $filter directive to request records modified since the last synchronisation timestamp. If direct filtering by timestamp is not supported, all records must be fetched and then filtered client-side. Update External System: For each retrieved record, update the corresponding item in the external inventory system, focusing on quantity levels and any other relevant information. Periodic Synchronisation For periodic synchronisation, updates are performed at shorter intervals throughout the day, ensuring more up-to-date inventory levels. This approach is more complex but is necessary for systems requiring higher accuracy and timeliness in inventory data. Technique: Initial Full Sync: Perform a full synchronisation at the start of the period to ensure both systems start from a consistent state. Periodic Incremental Sync: At set intervals (e.g., every hour), use the $filter directive to fetch records modified since the last successful synchronisation. This approach reduces the data transfer volume and focuses updates on only changed records. Usually taking the maximum TimeStamp from the last result set and using a filter where $filter=TimeStamp ge LastTimeStamp Handling Pagination: Utilise the $top directive to manage pagination, ensuring complete retrieval of all relevant updates within the constraint of the maximum page size. Concurrency Handling: Implement logic to handle concurrency issues, especially in scenarios where an inventory record might be updated during the synchronisation process. Techniques include retry mechanisms or leveraging versioning fields if available. General Considerations Error Handling: Implement robust error handling to address network issues, API rate limits, and data inconsistencies. Data Summaries: Note that the Inventory List provides article detail, in the case where summary inventory levels are required the first result set may need to be used to indicate the Product items, Location, and Bins to filter in order to recalculate total available inventory levels. Timestamp Management: Store the timestamp of the last successful synchronisation to use as a reference for subsequent $filter queries as per the example above. Optimisation: Consider caching mechanisms or delta updates (if supported by the API) to optimize performance and reduce unnecessary data transfer. By carefully implementing these techniques, tailored to the synchronisation frequency requirements, you can ensure that the external inventory system remains closely aligned with the data provided by the Inventory List Endpoint.
    • [Inventory](https://app.theneo.io/datapel/datapel-api/endpoint-reference/inventory-list/inventory.md): Retrieves a single Inventory record by Uid using singleton format /public/inventory?{InventoryUid}
    • [Estimates](https://app.theneo.io/datapel/datapel-api/endpoint-reference/inventory-list/inventory-copy-1.md): Returns a list of the Estimated production or assembly selling Units for workspace Kits and Assembly (manufactured) Products by Location. As this is a real-time estimate there is no timestamp available, it should also be noted that assembly and kitting components maybe used in many finished inventory items, so a change in the availablity of one component may impact the estimated available units of many Kit or Assembly Product Codes.
  • [Inventory Events](https://app.theneo.io/datapel/datapel-api/endpoint-reference/inventory-events.md): Retrieves a list of records detailing Inventory movements by item, location, quantity, and unique batch serial number properties. Use $top and $filter directives to limit results to less than the maximum page size of 500 records. Summary Overview InventoryEventUid : A unique identifier for the inventory event. EventDate : The date the event occurred. ProductUid : A unique identifier for the product involved in the event. LocationUid , LocationCode : Unique identifiers and code for the location of the inventory event. LocationBinUid , BinNumber , BinType : Details about the specific bin within the location where the product is stored. Source : The origin of the inventory event, e.g., Purchase Order (PO). OrderURN , ReferenceNumber , OrderUid , OrderNumber : Various identifiers related to the order associated with this event. Code : The product code. BatchSerialNumber : Serial number for the product batch, if applicable. ContactName : The name associated with the location, such as "Main Warehouse". Quantity , UnitQuantity , UnitMeasure : Details about the quantity of the product moved or affected by the event, including the unit of measure. Example Use Cases Inventory Tracking : Use the API to track inventory movements within the warehouse. For example, when products are received, moved, or shipped, an event is recorded with all relevant details including product, quantity, and location. Order Processing : Integrate with an order management system to update inventory levels based on incoming orders (purchase orders) and outgoing orders (sales orders). The Source field can be used to differentiate between different types of transactions. Warehouse Management : Utilize the bin location details ( LocationBinUid , BinNumber , BinType ) to optimize warehouse space and manage stock locations efficiently. This can support strategies like FIFO (First In, First Out) or LIFO (Last In, First Out) inventory management. Reporting and Analytics : Generate reports on inventory levels, movements, and order fulfillment efficiency. Use data like EventDate , Quantity , and LocationCode to analyze trends over time, identify bottlenecks, or optimize inventory turnover rates. Integration with Logistics : For products being shipped, the inventory event data can be used to update logistics partners or systems about which items have been dispatched, including details like OrderNumber and ContactName for tracking and delivery purposes.
  • [Address List](https://app.theneo.io/datapel/datapel-api/endpoint-reference/address-list.md): Retrieves a list of address location details with associated Contact Name and AccountUid. Returns the primary Billing address and default Shipping address for the contact. Use Shipping address for despatch and receiving destinations, while invoices and bills should target the Billing address.
  • [Contact List](https://app.theneo.io/datapel/datapel-api/endpoint-reference/contact-list.md): Retrieves a list of customer, supplier, employee, and other contact records using a filter criteria. Make sure to limit results using the $top directive set to less than the maximum page size of 500 .
    • [Contact](https://app.theneo.io/datapel/datapel-api/endpoint-reference/contact-list/contact.md): Retrieves a single Contact by Uid using singleton format /public/contact?{ContactUid}
  • [Location List](https://app.theneo.io/datapel/datapel-api/endpoint-reference/location-list.md): Retrieves a list of locations using a filter criteria. Make sure to limit results using the $top directive set to less than the maximum page size of 500 .
    • [Location](https://app.theneo.io/datapel/datapel-api/endpoint-reference/location-list/location.md): Retrieves a single Location by Uid using singleton format /public/location?{LocationUid}
    • [Location Bins](https://app.theneo.io/datapel/datapel-api/endpoint-reference/location-list/location-bins.md): Retrieves a list of Bins using a filter criteria. Make sure to limit results using the $top directive set to less than the maximum page size of 500 .
  • [Attachments](https://app.theneo.io/datapel/datapel-api/endpoint-reference/attachments.md): Retrieves a list of file attachments using a filter criteria. Make sure to limit results using the $top directive set to less than the maximum page size of 500 . The source transaction is associated with RecordUid , for example when AttachmentType product is defined the RecordUid is an alias for ProductUid.
    • [GET Attachment](https://app.theneo.io/datapel/datapel-api/endpoint-reference/attachments/get-attachment.md): Retrieves a single Attachment by Uid using singleton format /public/attachment?{AttachmentUid}
    • [POST Attachment](https://app.theneo.io/datapel/datapel-api/endpoint-reference/attachments/post-attachment.md): Add a single BASE64 encoded document to an Order or Product. Properties and Values Item Number To attach an image or file to a Product Item asset you must specify a valid Item Number. TransID or Special2 When attaching an image to a Transaction you must specify the Order Number as the TransID or in the case of Sale Orders you can specify the Purchase Order Number as Special2 . Document Property The Document property is required and is a Base64 encoded file. The following file types are accepted: data:image/jpeg;base64 data:image/png;base64 data:image/bmp;base64 data:application/msword;base64 data:application/excel;base64 data:application/pdf;base64 Sample Document Property Select... "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAABHNCSVQICAgIfAhkiAAAAAlwSFlzAAAApgAAAKYB3X3/OAAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBlLm9yZ5vuPBoAAANCSURBVEiJtZZPbBtFFMZ/M7ubXdtdb1xSFyeilBapySVU8h8OoFaooFSqiihIVIpQBKci6KEg9Q6H9kovIHoCIVQJJCKE1ENFjnAgcaSG C6rEnxBwA04Tx43t2FnvDAfjkNibxgHxnWb2e/u992bee7tCa00YFsffekFY+nUzFtjW0LrvjRXrCDIAaPLlW0nHL0SsZtVoaF98mLrx3pdhOqLtYPHChahZcYYO7KvPFxvRl5XPp1sN3adWiD1ZAqD6XYK1b/dvE5IWryTt2udLFedwc1+9kLp+vbbpoDh+6TklxBeAi9TL0taeWpdmZzQDry0AcO+jQ12RyohqqoYoo8RDwJrU+qXkjWtfi8Xxt58BdQuwQs9qC/afLwCw8tnQbqYAPsgxE1S6F3EAIXux2oQFKm0ihMsOF71dHYx+f3NND68ghCu1YIoePPQN1pGRABkJ6Bus96CutRZMydTl+TvuiRW1m3n0eDl0vRPcEysqdXn+jsQPsrHMquGeXEaY4Yk4wxWcY5V/ 9scqOMOVUFthatyTy8QyqwZ+kDURKoMWxNKr2EeqVKcTNOajqKoBgOE28U4tdQl5p5bwCw7BWquaZSzAPlwjlithJtp3pTImSqQRrb2Z8PHGigD4RZuNX6JYj6wj7O4TFLbCO/Mn/m8R+h6rYSUb3ekokRY6f/YukArN979jcW+V/S8g0eT/N3VN3kTqWbQ428m9/8k0P/1aIhF36PccEl6EhOcAUCrXKZXXWS3XKd2vc/TRBG9O5ELC17MmWubD2nKhUKZa26Ba2+D3P+4/MNCFwg59oWVeYhkzgN/JDR8deKBoD7Y+ljEjGZ0sosXVTvbc6RHirr2reNy1OXd6pJsQ+gqjk8VWFYmHrwBzW/n+uMPFiRwHB2I7ih8ciHFxIkd/3Omk5tCDV1t+2nNu5sxxpDFNx+huNhVT3/zMDz8usXC3ddaHBj1GHj/As08fwTS7Kt1HBTmyN29vdwAw+/wbwLVOJ3uAD1wi/dUH7Qei66PfyuRj4Ik9is+hglfbkbfR3cnZm7chlUWLdwmprtCohX4HUtlOcQjLYCu+fzGJH2QRKvP3UNz8bWk1qMxjGTOMThZ3kvgLI5AzFfo379UAAAAASUVORK5CYII=" DocumentGIS This is the GIS information relating to the location of the device at the time of image capture. If the image is loaded from the Gallery the location of the device at the time of conversion to Base64 will also be acceptable. As it is possible for POSTing to the server to be delayed device location can not be taken at the point of upload. A sample GIS vector co-ordinate should be stored using Decimal degrees (DD): "DocumentGIS": "[eastings,northings]" format, example [41.40338, 2.17403] is 41°24'12.2"N 2°10'26.5"E.
  • [Create Sale Order](https://app.theneo.io/datapel/datapel-api/endpoint-reference/create-sale-order.md): This endpoint is used to queue a new sale order for creation in the Cloud.WMS workspace. It handles the comprehensive details of a sale transaction, including transaction headers, customer shipping information, payment details, and individual sale line items. POST Body Structure tREMOTETransHeader : Contains primary details of the sale order. Includes fields like DTD, Order Number, Dates (Posting, Order, Deliver, Customer), Customer and Shipping IDs, Salesperson details, Order and Layout Types, Status, Priority, Shipping and Tax details, Notes, Discount and Surcharge information, and other miscellaneous flags. tREMOTETransCustomer : Details about the customer for direct shipping. Fields include shipping address details (name, address, suburb, state, postcode, country), contact number, and email address. tREMOTETransSaleTenders : Payment information of the order. Specifies the Tender Type (e.g., PayPal) and the Tender Amount. tREMOTETransSaleLines : Line items of the sale order. Details of each item sold, including Line Number, Product Code, Description, Quantity, Unit Amount (inclusive and exclusive of tax), Tax details, and additional notes. Order Header The minimum required order header is shown below and contains all mandatory fields. It is important to note that either RemoteUid or ContactUid is required and the choice or which field to use will depend on the app developer. It is possible to provide both fields however RemoteUid will take precedence over other Uid fields. Select... { "tREMOTETransHeader": { "DTD": "remote", "LocationUid": "main_whs", "AccountUid": "OZISUPPLY", "SalespersonName": "default", "OrderType": "order", "LayoutType": "items", "StatusType": "open", "ShippingMethod": "default" } } Order Types Order types and submission actions can be set using the OrderType and StatusType fields. OrderType Description S or O or order Create transaction as standard Sale Order Q or quote Create as Sale Order Quotation R or return Create as Return Authority, auto generating a linked Goods Inward Order X or xchange Create an Exchange Sale Order , the negative sale line items will be returned to default inventory locations, while sale line replacement items are placed on pick hold U or update Create an Updated Revision of an open Sale Order, you must provide the LastRevision Number if not a new order will be created. The specified revision number will be cancelled (not deleted). The prior order must be Open, RTP, or NSA. Status Type Order Status Type determines the workflow that is applied to an order on submission. When OrderType is O or S, the StatusType can be set as Open (O), (D) Despatch/Ship, or (A) Allocate, in this case the order is placed on pick hold using the default stock allocation pick method. StatusType Description O or open order Create an Open Sale Order A or allocate as pick hold Create order and attempt to pick and hold inventory using the default stock selection method (FIFO,LIFO, MIN, MAX etc). D or ship and despatch Create order attempting to pick, pack, and ship all order lines. Delivery Details Shipping address formats Where the customer or contact exists within the cloud.WMS workspace and has an assigned Shipping Address there is no requirement to specify address details. On submission the address is initialised with the contacts default shipping details. An example is shown below. Select... <tREMOTETransCustomer> <ShipToName> Campbell Buswell </ShipToName> </tREMOTETransCustomer> When address details are not preset the format can be freeform or parameterised. If the address is parameterised the ShipAddress tags can be completed as shown below. An internal address decoder will attempt to correct and match freeform fields to parameters however is not 100% accurate. Select... <tREMOTETransCustomer> <ShipToName>Campbell Buswell</ShipToName> <ShipToAddress1>67 Foss Street</ShipToAddress1> <ShipToSuburb>Bicton</ShipToSuburb> <ShipToState>WA</ShipToState> <ShipToPostCode>6157</ShipToPostCode> </tREMOTETransCustomer> In the case of freeform address details the address can be assigned using the following rule. By specifying Direct Ship as Y the internal address decoder will be bypassed and each field assigned to corresponding parameters within the order. Select... <tREMOTETransCustomer> <DirectShip>Y</DirectShip> <ShipToName> Campbell Buswell </ShipToName> <ShipToAddress1> 67 Foss Street </ShipToAddress1> <ShipToAddress2> Bicton, WA, 6157 </ShipToAddress2> <ShipToAddress3> Australia </ShipToAddress3> <ShipToAddress4></ShipToAddress4> <ShipToSuburb> Bicton </ShipToSuburb> <ShipToState> WA </ShipToState> <ShipToPostCode> 6157 </ShipToPostCode> <ShipToCountry> Australia </ShipToCountry> </tREMOTETransCustomer> Utilise the DirectShip Tag to indicate this address should not be parsed and pass through directly as order address properties. Address line character limits In all cases the Address Lines are limited to 50 characters per line. Should the incoming tags exceed this length they will be truncated. It is recommended that the sender ensures that any line that exceeds 50 characters is carried over to the next line breaking on the nearest space from right to left. In total the address field supports a maximum of 150 characters. A possible work around where FOUR ADDRESS LINES are required is to replace the ShipToName with AddressLine1. Special Directives There are special directive fields that change the behaviour of the POST action. Setting Special1 with the following can determines how certain sale order properties will be configured. Using CUSTOM=TRUE; will force the sale order to use the alternate FORM for Order rendering. With ADDSHIPMETHODS=TRUE; any unrecognised shipping method will be created and assigned to the current sale order, this directive should only be used with Standalone WMS. Priority Field Order priority can be set using the following options, note that errors or warnings on order submission may override priority placing it on hold for review. Priority Description 0 or Normal Create transaction without priority. 1 or High Create as High Priority. 2 or OnHold or Hold Create as OnHold blocking order from all workflows until priority is cleared. 3 or Low Create as Low Priority Order , this assists with order workflow sorting. Order Line Items The sale lines node needs to repeat mandatory fields for each line item. It is recommended to use either SaleUnitQty or SaleQty . SaleUnitQty takes into account the unit of measure and is recommended for eCommerce integration use cases. To maximise rounding and tax amount calculation accuracy it is recommended to use Tax Inclusive Unit pricing. Directives for setting financial defaults To simplify the sending of line financial information the SalesLine node supports a ByHost directive. ByHost will indicate to the api server to use the default value for the product and contact for the specified directive. For example SalePriceByHost will ignore any price in the UnitAmount field and use the Contact default price for the specified Product Code. Using SaleTaxByHost will insert the default TaxCode associated with the Product code or Customer. This can be useful in the case of international or local orders where different taxes may apply. Select... "tREMOTETransSaleLines": [ { "Code": "Widget", "SaleUnitQty": "1", "SaleTaxByHost": "Y", "SalePriceByHost": "Y" } Web hooks Each order transaction can subscribe to a web hook service that will be notified as the inventory system performs business events and order status changes. The web hook POST payload will vary depending on the specific business event that triggers notification, however the transaction will always publish the OrderQid enabling client order lookup via GET endpoints. The WebHook field must define the URL to send the business event data when a trigger occurs. Credentials are optional and will be added to the POST header as a key value pair. Select... "tREMOTETransHeader": { … "WebHook": " https://wh.datapelapi.net ", "Credentials": "Credential_Key,Credential_Value", "EventScope": "create,cancel", … } The web hook URL must accept a JSON post body as per the example below. Select... { "transactionId":"QID-1234-5678-9012-3456", "status":"success", “event”:"create", "TimeStamp":"2024-01-28T12:54:58Z", "message":"User [superuser] Created Order#0065014 (SO-0499-7684)" } Reliability and Service Response To ensure reliable delivery of all message events by the web hook service, several key receiver requirements should be met. Acknowledgment of Receipt : Your server must respond with http 200 and send a simple JSON acknowledgement upon successfully receiving the message. Scalability : Your server should be able to handle high loads and scale according to the number of events expected based on application use cases. Message Queueing : Utilise message queues to handle bursts of events and ensure no data is lost during peak activity times. An audit event will be recorded within the Inventory Management System corresponding to each web hook notification. The event list can be used to reconcile business event messages received and sent over by date and time. It is best practice to maintain an internal monitoring and logging process that can manage service outages. The web hook service has a limited timeout and depends on the notification event, your server must respond within 2 to 5 seconds to ensure reliable delivery. Event Types The lifecycle of an Order follows a number of stages from creation to despatch, as the status of the order changes web hook notifications will be generated with an event type property. To limit the messages sent to the web hook set eventscope with a comma separated string of events from the list below. Event Description create Created new order approve or recall Approval or Recall action picked Order now fully allocated on pick hold cancel Order was cancelled packed Order now fully packed shipped Order confirmed as shipped closed Order closed and stock movement committed all Notifies on any event (default if scope is blank) It is important to note that order status can move forward or backward in the fulfilment process, so a packed order can become picked if the instruction is given to unpack the order. However, once an order is closed status can no longer change as this transaction has reached the end of its lifecycle. Audit Events Polling If you are unable to support web hook services to verify order creation success or failure then consider polling audit events. Polling is a method where the client application repeatedly (at regular intervals) makes requests to a server to obtain the status of an operation, in this case, to check if an order has been successfully processed based on a returned transaction ID. This method is useful in systems where the processing time of an operation is uncertain or when immediate notification of the operation's completion is not available. Order create polling involves two main steps: Posting to the Order Endpoint: Start the process by sending a POST request to the order endpoint. The endpoint transforms and queues the order returning a transaction ID. This transaction ID serves as a reference to the specific transaction initiated by your POST request. Checking the Audit Event Log for Status: After receiving the transaction ID, you periodically send GET requests to another endpoint, the audit log service, using the transaction ID to inquire about the status of your order. This audit log endpoint returns the current status of the order, indicating whether it has been successfully created or if there was a failure. Polling Example POST Order JSON on /public/order endpoint and receive an ID QID-XXX-XXXX-XXXX-XX GET AuditEvent JSON on endpoint/public/auditevents using the sample filter …. public/auditevents?$filter=contains(EventReference,'create.QID-D2F45F35-6FA9-4ACB-BB52-7538D01D1B6E') Review the response in the EventMessage property to determine the status of your order submission. If an error occurs the message property will contain more information to help identify the source of any issues. Note that only one error i s reported at a time. If there is no result, it is recommended to wait between 5 - 10 seconds before retrying the AuditEvent endpoint. On success use the GET Order or Orders using either OrderQid eq ‘QID-XXX-XXXX-XXXX-XX’ or OrderNumber, alternatively the OrderUid is returned in the (XXXXX) or (488) in the example below. You can expect one of three responses success Select... { "AuditEventUid": "998250", "AuditEventGroup": "Notification", "AuditEventDetail": "transactionId:QID-D2F45F35-6FA9-4ACB-BB52-7538D01D1B6E,status:success,event:create", "EventType": "Status", "EventMessage": "{ "transactionId":"QID-D2F45F35-6FA9-4ACB-BB52-7538D01D1B6E",\r\n"status":"success",\r\n"event":"create",\r\n"TimeStamp":"2024-02-01T15:59:13Z",\r\n"message":"OrderNumber 01021158 (488)"}", "EventReference": "create.QID-D2F45F35-6FA9-4ACB-BB52-7538D01D1B6E", "AuditEventTimeStamp": "2024-02-02 02:59:14" }, failure Select... { "AuditEventUid": "998262", "AuditEventGroup": "Notification", "AuditEventDetail": "transactionId:QID-A00CD195-AC50-4193-A336-FD96EA9AFE5F,status:error,event:create", "EventType": "Status", "EventMessage": "{ \"transactionId\":\"QID-A00CD195-AC50-4193-A336-FD96EA9AFE5F\",\r\n\"status\":\"error\",\r\n\"event\":\"create\",\r\n\"TimeStamp\":\"2024-02-01T16:23:58Z\",\r\n\"message\":\"DUPLICATE - Invoice Number already exists 01021158\"}", "EventReference": "create.QID-A00CD195-AC50-4193-A336-FD96EA9AFE5F", "AuditEventTimeStamp": "2024-02-02 03:23:59" } incomplete (noresult) Select... { "d" : { "__count":"0","results": [] } }
  • [Order List](https://app.theneo.io/datapel/datapel-api/endpoint-reference/order-list.md): The Order List endpoint allows users to retrieve a list of orders based on specified filter criteria. By using the provided parameters, users can limit the results, sort them, and access various details about each order, such as reference numbers, order dates, and shipping information. This endpoint returns only sale order types. Retrieves a list of Orders based on a filter criteria. Make sure to limit results using the $top directive set to less than the maximum page size of 500 .
    • [Order](https://app.theneo.io/datapel/datapel-api/endpoint-reference/order-list/order.md): The Order endpoint allows users to retrieve a single order, including order details, contact information, shipping address, and item details. For information regarding the nodes and properties refer to the Order List section https://app.theneo.io/datapel/datapel-api/endpoint-reference/order-list . Retrieves a single Order by Uid using singleton format /public/order?OrderUid in this example …/public/order?1032 Select... { "OrderUid": "1032", "ReferenceNumber": "SO-0388-8282", "OrderNumber": "001232", "PurchaseNumber": "PO98986", "Notes": "Thanks for your business", "OrderDate": "2024-01-31", "PostingDate": "2024-02-02", "DeliverDate": "2024-01-31", "OrderType": "Order", "StatusType": "OutofStock", "LayoutType": "Items", "TaxInclusive": "True", "AccountUid": "OZSUPPLY", "Contact": { "RemoteUid": "2339", "ContactUid": "OZSUPPLY", "LastName": "Customer", "FirstName": "" }, "ShippingAccountUid": "", "ShippingContact": { "ShippingRemoteUid": "", "ShippingContactUid": "", "LastName": "", "FirstName": "" }, "Location": { "LocationUid": "MAINWHS", "LocationName": "LOC-Main Warehouse" }, "ShippingAddress": { "ShippingLocationUid": "External", "AddressLine1": "12 Wombat Court", "AddressLine2": "", "City": "Perth", "State": "WA", "PostCode": "6009", "CountryCode": "Aus", "LastName": "" }, "Total": "300", "TotalExTax": "278.18", "CurrencyCode": "AUD", "SpotCrossRate": "1", "Terms": "COD", "Salesperson": { "SalespersonRemoteUid": "", "SalespersonContactUid": "", "Name": "", "LastName": "", "FirstName": "" }, "Payments": { "BalanceDue": "0", "LastPaidAmount": "0", "LastPaidMethod": "", "PaymentType": "", "OrderIsPaid": "False", "LastReconcileDate": "", "LastPaidDate": "", "PayNowUid": "", "PaymentNote": "" }, "Source": "", "Approved": "False", "Items": [ { "Product": { "RemoteUid": "3503547", "Code": "20010", "Name": "Widget", "UnitMeasure": "Each" }, "UnitPriceExTax": "1.500000000000000e+001", "UnitPrice": "1.500000000000000e+001", "TaxCode": "N-T", "DiscountPercentage": "0.000000000000000e+000", "LinePriceExc": "6.000000000000000e+001", "LinePriceInc": "6.000000000000000e+001", "UnitQuantity": "4", "LineDescription": "Best Selling Widget", "LineNote": "Blue", "LineNumber": "1", "LineStatus": "NoStockAvailable", "JobNumber": "", "JobNote": "", "Type": "LineItem", "SaleUid": "1032", "Articles": [ { "ArticleUnitQuantity": "4", "ArticleTags": "", "BatchSerialNumber": "WG22-BB202408", "BinName": "A1050", "LotNumber": "1", "InventoryUid": "223" } ] } ], "OrderStage": "Pending", "Status": "NoStockAvailable", "Allocated": "False", "AllocatedDate": "2000-01-01", "Priority": "High", "OrderNote": "sent via apiv2", "ShipNote": "please leave at rear entrance", "ShippingReference": "", "ShipMethod": "", "PalletCount": "1", "OrderWeight": "0", "OrderQid": "QID-2A70F179-4DB5-42E7-9D6B-0BFFA5B1C3BC", "Revision": "1", "UserFields": { "UDF1": "udef1", "UDF2": "udef2", "UDF3": "udef3", "UseCustomerDate": "False", "CustomerDate": "", "CustomerEmail": "test@test.com" }, "TimeStamp": "2024-02-01 21:03:28" }
  • [Create Transfer Order](https://app.theneo.io/datapel/datapel-api/endpoint-reference/create-transfer-order.md): This endpoint is used to queue a new transfer or despatch order. It supports internal bin to bin, warehouse to warehouse and warehouse to contact transactions. Details include header source and destination information, direct to contact delivery information, and individual transfer line items. POST Body Structure tREMOTETransHeader : Contains primary details of the transfer order. Includes fields like DTD, Order Number, Dates (Order, Deliver, Customer), Source and Destination Locations, Order and Layout Types, Status, Priority, Direct to Contact, Notes, and other miscellaneous flags. tREMOTETransCustomer : OPTIONAL Details about the delivery for customer direct transfers . In this workflow, products are shipped directly from warehouse to customer without using sale financials tracking. This transaction type is also termed a check out . Fields include basic shipping label address details (address lines 1 - 4, you should include suburb, state, postcode, country) and email address. tREMOTETransItemLines : Line items of the transfer order. Details of each item for transfer, including Line Number, Product Code, Description, Quantity, Unit Amount (inclusive and exclusive of tax), and additional job tracking code. Source details may include Batch Serial Number, Lot Number, and Bin Location Destination can include a Bin Location and Lot Number. tREMOTETransSupplier : OPTIONAL Details about the source address of supply. Fields include basic shipping label address details (address lines 1 - 4, you should include suburb, state, postcode, country). Order Header The minimum required transfer order header is shown below and contains all mandatory fields. It is important to note source location LocationUid is required and AccountUid being a choice between a receiving location or contact depending on the transfer type. Select... { "tREMOTETransHeader": { "DTD": "remote", "LocationUid": "main_whs", "AccountUid": "other_whs", "BuyerName": "default", "OrderType": "transfer", "LayoutType": "items", "StatusType": "open", "ShippingMethod": "default" } } Transfer Types Order types and submission actions can be set using the OrderType and StatusType fields. OrderType Description O or order Create transaction as standard Transfer Order I or internal Create Bin to Bin movement as Transfer Order Q or quick Create as Quick Transfer, which will auto fulfil and close. Source and Delivery Details Source Address Source address details will default to the supplying Warehouse Location . This can be overridden in cases where a shipment is being sent direct from an external party, yet the inventory is managed by a virtual warehouse within the WMS. To override the supply address include the tRemoteTransSupplier node. Shipping Address Shipping address details will default to the receiving Warehouse Location, in the case of direct despatch orders to customer from the supply warehouse, the customer account shipping details can be specified using a free form, four line address label. Select... <tREMOTETransCustomer> <ShipToAddress1> 67 Foss Street </ShipToAddress1> <ShipToAddress2> Bicton, WA, 6157 </ShipToAddress2> <ShipToAddress3> Australia </ShipToAddress3> <ShipToAddress4></ShipToAddress4> </tREMOTETransCustomer> Priority Field Transfer Order priority can be set using the following options, note that errors or warnings on order submission may override priority placing it on hold for review. Priority Description 0 or Normal Create transaction without priority. 1 or High Create as High Priority. 2 or OnHold or Hold Create as OnHold blocking order from all workflows until priority is cleared. 3 or Low Create as Low Priority Order , this assists with order workflow sorting. Transfer Line Items The transfer lines node needs to repeat mandatory fields for each inward line item. It is recommended to use either ItemUnitQty or ItemQty . ItemUnitQty takes into account the selling unit of measure. Financial considerations Transfer orders typically represent non-financial movement of inventory. No sale ledger records are created for transfer operations, however unit prices and discounts can be tracked and a typical use case is in the creation of proforma invoices or customs valuation documentation. Source Articles and Receiving Options Line items represent the movement of source articles or number of products from one location to another. The source and receiving details can be fully qualified , that is specify and exact article by Batch Serial Number, Bin Name and Lot, making it uniquely identified, and defining receive Bin Name in the target location. This will move the article with all its attributes to the new Bin, equivalent to physically moving the article from one place in a warehouse to another. Partially qualified line items may specify as little as source product code and unit quantity, allowing the WMS to select articles based on best practice inventory rotation rules with a receiver Bin Name. It is also possible in the case of Warehouse to Warehouse transfer to leave receiver Bin Name blank allowing default put away rules to be applied on receipt of the transfer order. Select... "tREMOTETransItemLines": [ { "Code": "Widget", "ItemUnitQty": "1" } Web Hook Event Types The lifecycle of a Transfer Order follows the typical despatch workflow from creation, pick, pack, ship and optional receive. As the status of the transfer order changes web hook notifications will be generated with an event type property. To limit the messages sent to the web hook set eventscope with a comma separated string of events from the list below. Event Description create Created new transfer order approve or recall Approval or Recall action picked Order now fully allocated on pick hold cancel Order was cancelled packed Order now fully packed shipped Order confirmed as shipped closed Order closed and stock movement committed all Notifies on any event (default if scope is blank) For more information on defining web hook details see Create Sale Order - Webhooks.
  • [Transfer Order List](https://app.theneo.io/datapel/datapel-api/endpoint-reference/transfer-order-list.md): The Transfer Order List endpoint enables users to retrieve a list of inventory transfer orders based on specified filter criteria. Users can leverage this endpoint to manage and oversee the movement of inventory, either between different warehouse locations or within the same warehouse from one bin slot to another. By utilising the provided parameters, users have the capability to refine their search results, sort the data, and access detailed information about each transfer order, including reference numbers, transfer dates, source and destination locations, and status. This endpoint specifically caters to transfer order types, encompassing both inter-warehouse transfers and intra-warehouse movements. Ensure to limit the number of results retrieved by using the $top directive set to a value less than the maximum page size of 500 , to optimise the efficiency and manageability of the data returned.
    • [Transfer Order](https://app.theneo.io/datapel/datapel-api/endpoint-reference/transfer-order-list/transfer-order.md): The Transfer endpoint allows users to retrieve a single transfer or despatch order, including order details, contact information, shipping address, and item details. For information regarding the nodes and properties refer to the Inward Order List section https://app.theneo.io/datapel/datapel-api/endpoint-reference/transfer-order-list Retrieves a single Transfer Order by Uid using singleton format /public/transfer?OrderUid in this example …/public/transfer?1032 Select... { "OrderUid": "435", "ReferenceNumber": "TO-0109-3642", "OrderNumber": "WMSREMOTE", "Notes": "WMS Remote Transfer from PHOTO-FACTORY to PHOTO-MAIN", "OrderDate": "2024-03-04", "Type": "Inventory", "StatusType": "Transfer", "LayoutType": "Items", "Contact": { "RemoteUid": "", "ContactUid": "", "LastName": "", "FirstName": "" }, "Location": { "LocationUid": "PHOTO-FACTORY", "LocationName": "LOC-PhotoFactory" }, "ShippingAddress": { "ShippingLocationUid": "PHOTO-MAIN", "AddressLine1": "Drewery Lane", "AddressLine2": "\nMelbourne, VIC, 3000", "City": "", "State": "", "PostCode": "", "CountryCode": "", "LastName": "" }, "Total": "0", "TotalExTax": "0", "Items": [ { "Product": { "RemoteUid": 77177335, "Code": "Camera-01", "Name": "FujiFilm X100V" }, "DiscountPercentage": null, "UnitQuantity": 1, "LineNumber": 1, "PutAwayBinName": "D-30", "PutAwayBinType": "1", "PutAwayLotNumber": 1, "Type": "LineItem", "TransferUid": 435, "Articles": [ { "ArticleUnitQuantity": 1, "ArticleTags": "", "BatchSerialNumber": "WED1047", "BinName": "F01", "BinType": "1", "LotNumber": 1, "InventoryUid": 1589 } ] } ], "OrderStage": "COMPLETE", "Status": "Closed", "ShippingReference": "", "ShipMethod": "Transfer", "TimeStamp": "2024-03-04 11:26:34 " }
  • [Create Purchase Order](https://app.theneo.io/datapel/datapel-api/endpoint-reference/create-purchase-order.md): This endpoint is used to queue a new purchase or inwards order. It supports purchase transaction details, including header, supplier information, direct to customer delivery information, payment details, and individual purchase line items. POST Body Structure tREMOTETransHeader : Contains primary details of the sale order. Includes fields like DTD, Order Number, Dates (Posting, Order, Receive, Supplier), Supplier and Shipping IDs, Buyer details, Order and Layout Types, Status, Priority, Shipping and Tax details, Notes, Discount and Surcharge information, and other miscellaneous flags. tREMOTETransCustomer : OPTIONAL Details about the delivery or customer for direct or drop shipping . In this workflow, products are shipped directly from supplier to customer bypassing a warehouse. Fields include shipping address details (name, address, suburb, state, postcode, country), contact number, and email address. tREMOTETransPurchaseLines : Line items of the purchase order. Details of each item purchased, including Line Number, Product Code, Description, Quantity, Unit Amount (inclusive and exclusive of tax), Tax details, and additional notes. Order Header The minimum required order header is shown below and contains all mandatory fields. It is important to note that either RemoteUid or ContactUid is required and the choice or which field to use will depend on the app developer. It is possible to provide both fields however RemoteUid will take precedence over other Uid fields. Select... { "tREMOTETransHeader": { "DTD": "remote", "LocationUid": "main_whs", "AccountUid": "OZISUPPLY", "BuyerName": "default", "OrderType": "order", "LayoutType": "items", "StatusType": "open", "ShippingMethod": "default" } } Order Types Order types and submission actions can be set using the OrderType and StatusType fields. OrderType Description O or order Create transaction as standard Purchase Order Q or quote Create as Purchase Quotation R or request Create as Request Order, also called a requisition. Delivery Details Shipping address Shipping address details will default to the Warehouse Location associated with the order entity, so for traditional purchase to inventory orders this node can be omitted. However, In the case of drop shipping direct to customer from the supplier, the customer account shipping details are used, or can be specified using the DirectShip option. In the case of freeform address details the address can be assigned using the following rule. By specifying Direct Ship as Y the internal address decoder will be bypassed and each field assigned to corresponding parameters within the order. Select... <tREMOTETransCustomer> <DirectShip>Y</DirectShip> <ShipToName> Campbell Buswell </ShipToName> <ShipToAddress1> 67 Foss Street </ShipToAddress1> <ShipToAddress2> Bicton, WA, 6157 </ShipToAddress2> <ShipToAddress3> Australia </ShipToAddress3> <ShipToAddress4></ShipToAddress4> <ShipToSuburb> Bicton </ShipToSuburb> <ShipToState> WA </ShipToState> <ShipToPostCode> 6157 </ShipToPostCode> <ShipToCountry> Australia </ShipToCountry> </tREMOTETransCustomer> Utilise the DirectShip Tag to indicate this address should not be parsed and pass through directly as order address properties. Priority Field Inward Order priority can be set using the following options, note that errors or warnings on order submission may override priority placing it on hold for review. Priority Description 0 or Normal Create transaction without priority. 1 or High Create as High Priority. 2 or OnHold or Hold Create as OnHold blocking order from all workflows until priority is cleared. 3 or Low Create as Low Priority Order , this assists with order workflow sorting. Purchase Line Items The purchase lines node needs to repeat mandatory fields for each inward line item. It is recommended to use either PurchaseUnitQty or PurchaseQty . PurchaseUnitQty takes into account the buying unit of measure some care should be take to check for differences between buying, inventory, and selling units. To maximise rounding and tax amount calculation accuracy it is recommended to use Tax Inclusive Unit pricing. Directives for setting financial defaults To simplify the sending of line financial information the PurchaseLines node supports a ByHost directive. ByHost will indicate to the api server to use the default value for the product and supplier for the specified directive. For example PurchasePriceByHost will ignore any price in the UnitAmount field and use the Supplier default price for the specified Product Code. Using PurchaseTaxByHost will insert the default TaxCode associated with the Product code or Supplier. This can be useful in the case of international or local orders where different taxes may apply. Select... "tREMOTETransPurchaseLines": [ { "Code": "Widget", "PurchaseUnitQty": "1", "PurchaseTaxByHost": "Y", "PurchasePriceByHost": "Y" } Web Hook Event Types The lifecycle of an Inwards Order follows a number of stages from creation, receiving, closure and billing. As the status of the inward order changes web hook notifications will be generated with an event type property. To limit the messages sent to the web hook set eventscope with a comma separated string of events from the list below. Event Description create Created new inwards order approve or recall Approval or Recall action split Order part received open Order has no receive line or all lines released cancel Order was cancelled billed Order confirmed as billed closed Order now fully received or forced closed no further receives allowed all Notifies on any event (default if scope is blank) For more information on defining web hook details see Create Sale Order - Webhooks. As with sale orders, inward orders can move forward or backward in the receive process. The typical event sequence is create , split (if only part of the order is receipted), then closed when all items are received. A partially received order can be “released” which will undo any inventory that has yet to be assigned to despatch orders. When an inwards order is released it will trigger the open event. Once an inwards order is billed it can no longer change as this transaction is the end of its lifecycle. The web hook URL must accept a JSON post body as per the example below. Select... { "transactionId":"QID-1234-5678-9012-3456", "status":"success", “event”:"split", "TimeStamp":"2024-01-28T12:54:58Z", "message":"User [superuser] Status Inward Order 345674 (RRN-0599-2810) {OPEN} to {SPLIT}" } By default inward orders will only raise events based on status change. However some settings allow split orders to raise multiple events as inward order receiving line count changes. In this configuration there is a risk of event overrun, especially when multiple orders are being received using scanning devices and committing changes in real-time. If your application requires this event detail it is always best to discuss your requirement with our team before undertaking solution development.
  • [Inward Order List](https://app.theneo.io/datapel/datapel-api/endpoint-reference/inward-order-list.md): The Inward Order List endpoint allows users to retrieve a list of inbound supplier or transfer orders based on specified filter criteria. By using the provided parameters, users can limit the results, sort them, and access various details about each order, such as reference numbers, order dates, and shipping information. This endpoint returns purchase, workorder, and checkin inward order receipt types. Make sure to limit results using the $top directive set to less than the maximum page size of 500 .
    • [Inward Order](https://app.theneo.io/datapel/datapel-api/endpoint-reference/inward-order-list/inward-order.md): The Inward Order endpoint allows users to retrieve a single purchase or goods inward order, including order details, contact information, shipping address, and item details. For information regarding the nodes and properties refer to the Inward Order List section https://app.theneo.io/datapel/datapel-api/endpoint-reference/inward-order-list . Retrieves a single Inward Order by Uid using singleton format /public/inwardorder?OrderUid in this example …/public/inwardorder?1032 Select... { "OrderUid": "4", "ReferenceNumber": "PO-0324-0361", "PurchaseNumber": "0200002", "SupplierNumber": "", "Notes": "", "PurchaseDate": "2020-04-24", "PostingDate": "2024-02-08", "DeliverDate": "2020-04-24", "OrderType": "Order", "StatusType": "Bill", "LayoutType": "Items", "TaxInclusive": "False", "AccountUid": "*ALLLOCATIONS", "Contact": { "RemoteUid": "1870895953", "ContactUid": "*ALLLOCATIONS", "LastName": "*ALLLOCATIONS", "FirstName": "" }, "ShippingAccountUid": "", "ShippingContact": { "ShippingRemoteUid": "", "ShippingContactUid": "", "LastName": "", "FirstName": "" }, "Location": { "LocationUid": "TEST MAIN", "LocationName": "LOC-TEST MAIN" }, "ShippingAddress": { "ShippingLocationUid": "External", "AddressLine1": "124-128 Lap Lane", "AddressLine2": "", "City": "Eastwood Hills", "State": "NSW", "PostCode": "2410", "CountryCode": "", "LastName": "*ALLLOCATIONS" }, "Total": "1155", "TotalExTax": "1050", "CurrencyCode": "AUD", "SpotCrossRate": "1", "Terms": "Net 30th After EOM ", "Buyer": { "BuyerRemoteUid": "83", "BuyerContactUid": "15", "Name": "user15, user15", "LastName": "user15", "FirstName": "user15" }, "Payments": { "BalanceDue": "0", "LastPaidAmount": "0", "LastPaidMethod": "", "PaymentType": "", "OrderIsPaid": "False", "LastReconcileDate": "", "LastPaidDate": "", "PaymentNote": "" }, "Source": "", "Approved": "False", "Items": [ { "Product": { "RemoteUid": "-1142087431", "Code": "BatchItem2", "Name": "BatchItem2", "UnitMeasure": "" }, "UnitPriceExTax": "2.000000000000000e+001", "UnitPrice": "2.200000000000000e+001", "TaxCode": "GST", "DiscountPercentage": "0.000000000000000e+000", "LinePriceExc": "2.000000000000000e+001", "LinePriceInc": "2.000000000000000e+001", "UnitQuantity": "1.000000000000000e+001", "LineDescription": "BatchItem2", "LineNote": "", "LineNumber": "1", "JobNumber": "", "JobNote": "", "Type": "LineItem", "PurchaseUid": "4", "Articles": [ { "ReceivedUnitQuantity": "5", "ReceiveDate": "2020-04-24", "ArticleTags": "", "BatchSerialNumber": "", "BinName": "", "LotNumber": "0", "ReceiveOrderUid": "2" }, { "ReceivedUnitQuantity": "5", "ReceiveDate": "2020-04-24", "ArticleTags": "", "BatchSerialNumber": "", "BinName": "", "LotNumber": "0", "ReceiveOrderUid": "2" } ] } ], "OrderStage": "Complete", "Status": "Closed", "WorkOrderInwards": "False", "LastReceiveDate": "2020-04-24", "ReceiverName": "USER5, USER5", "Priority": "", "OrderNote": "", "ShipNote": "Memo: !*ALLLOCATIONS Order from NSWSTORE", "ShippingReference": "", "ShipMethod": "Delivery - Paul", "OrderQid": "", "Revision": "1", "UserFields": { "UDF1": "", "UDF2": "", "UDF3": "", "UseSupplierDate": "False", "SupplierDate": "2020-04-24", "SupplierEmail": "" }, "TimeStamp": "2024-02-08 02:56:11" }
  • [Create Transaction](https://app.theneo.io/datapel/datapel-api/endpoint-reference/create-transaction.md): This endpoint is used to queue and process transaction data for inventory management. It supports various transaction types, including goods inward or check in (CI), depatch order or check out (CO), transfer orders (TO), and adjustment orders (AO). Transactions are short form inventory actions that are similar to journals within an accounting system. They contain the minimal number of fields to create a valid Goods Inward, Despatch, Adjustment and Transfer Order. POST Body Structure tREMOTETransHeader : Contains primary details of the transaction order. Includes fields like Transaction Number, Date (Order, Deliver), Source and Destination Locations, Transaction Type, Status, Priority, Contact, Notes, and other miscellaneous fields. tREMOTETransLines : Line items of the transaction order. Details of each item for transfer, including Product Code, Description, Quantity, Unit Amount (inclusive and exclusive of tax), and additional job tracking code. Source details may include Batch Serial Number, Lot Number, and Bin Location Destination can include a Bin Location and Lot Number. Transaction Types Order types and submission actions can be set using the TransactionType field. There are two classes of type a completed or pending transaction. To indicate a pending type use CIP, TOP, or COP. Together with TransactionType , the Status property can be used to trigger automated allocation of inventory using PICK and further progress workflow as SHIPPED by setting either PICK or SHIP respectively. Adjustments do not support the pending option. OrderType Description CO, COP as check out Create stock delivery transaction as standard Check Out or Despatch Order TO, TOP as transfer Create Bin to Bin or Location to Location stock transfer movement as Transfer Order CI, CIP as check in Create stock receive or transaction as standard Check In or Goods Inward AO or adjustment Set article count as standard Adjustment Despatch Address Shipping address details will default to the receiving Warehouse Location, in the case of Transfer Order. For all other transaction types the address will default to the Shipping details of the selected Contact . Priority Field Transfer Order priority can be set using the following options, note that errors or warnings on order submission may override priority placing it on hold for review. This property is not used for Adjustment transactions. Priority Description Normal Create transaction without priority. High Create as High Priority. OnHold Create as OnHold blocking order from all workflows until priority is cleared. Low Create as Low Priority Order , this assists with order workflow sorting. Transaction Line Items The transaction lines node must repeat mandatory fields for each inward line item. Note Quantity is always Unit Quantity and takes into account the buying or selling unit of measure dependent on transaction type. Sample Check In or Inward Order Select... { "NewDataSet": { "tREMOTETransHeader": { "TransID": "9797987", "TransDate": "2024-03-18", "SrcLocation": "MIDWEST", "Contact": "DECTEC Supplier", "User": "Clarke, Connan", "TransactionType": "CI" }, "tREMOTETransLines": [ { "Item": "ANC555", "Quantity": "5", "BRN": "" } ] } } Sample Transfer Order Select... { "NewDataSet": { "tREMOTETransHeader": { "TransID": "", "TransDate": "2024-03-18", "SrcLocation": "MIDWEST", "DstLocation": "MIDWEST", "Contact": "DECTEC Supplier", "User": "Clarke, Connan", "TransactionType": "TOP" }, "tREMOTETransLines": [ { "Item": "ANC555", "Quantity": "5", "BRN": "" } ] } } Sample Adjustment Order Select... { "NewDataSet": { "tREMOTETransHeader": { "TransID": "", "TransDate": "2024-03-18", "SrcLocation": "MIDWEST", "Contact": "DECTEC Supplier", "User": "Clarke, Connan", "TransactionType": "AO" }, "tREMOTETransLines": [ { "Item": "ANC555", "Quantity": "5", "SrcBin": "A1", "BRN": "" } ] } } Errors and Warnings When posting transactions several errors and warnings can be encountered. Understanding these potential issues can help in troubleshooting and ensuring smooth transaction processing. Here is a list of possible errors and warnings that might arise during the import process, along with their meanings and suggested actions. Errors Invalid Transaction Type Description : The transaction type specified in the JSON or XML does not match the expected type for Transactions. Suggested Action : Ensure the TransactionType field in the XML is set to "CO,TO,CI,AO" or for pending "COP,TOP,CIP" transactions. Missing Item Code or Barcode Description : An item code or barcode is missing in one of the transaction lines. Suggested Action : Verify that all Item element in the JSON or XML contains a valid Product Number or Barcode (Primary or Secondary). Invalid Quantity Description : The quantity for an item specified in the transaction line is invalid (e.g., negative numbers). Suggested Action : Check the Quantity fields in the to ensure all quantities are positive numbers, selling or buying units depending on the Transaction Type. Missing Source Location ID Description : The source location code is missing in the transaction header. Suggested Action : Ensure the SrcLocation field is filled with a valid location code. In some cases no location will substitute the system default location. Failed on XML Convert Description : The system was unable to parse the JSON or XML file, possibly due to malformed XML. Suggested Action : Check the XML file for correctness and adherence to the expected format. Check for special character escape sequences or hidden characters that may not be visible as plain text. Missing Transaction Content Description : The JSON or XML file does not contain transaction lines or is improperly formatted. Suggested Action : Verify that the Transaction includes at least one Line Item element with complete item details. Warnings Skipped Due to Status Description : Transactions marked with certain statuses are skipped. Suggested Action : Confirm that the Status field in the tREMOTETransHeader is set correctly for the intended transaction type. Processing Halted Due to Errors Description : Errors encountered during the import process may halt further processing of the transaction. Suggested Action : Review the specific errors provided, correct the issues in the XML file, and attempt the import again. Batch or Lot Number Missing Description : Optional warning when batch or lot numbers ( BRN or Lot ) are missing for inventory items that require them. Suggested Action : If batch or lot tracking is relevant for the items being checked out, ensure that these fields are populated. General Suggestions for Troubleshooting Double-Check Format : Ensure that your JSON or XML file strictly follows the structure and formatting rules expected by the system. Review Mandatory Fields : Confirm that all required fields for a Transactions and particular type are present and correctly filled out. Validate XML : Use XML validation tools to ensure that your XML file is well-formed and adheres to the expected schema. Consult Documentation : Refer to the detailed API documentation for specific fields and requirements related to Check-Out transactions.
  • [Workspace Options](https://app.theneo.io/datapel/datapel-api/endpoint-reference/workspace-options.md): Get the default workspace configuration options. This endpoint retrieves the default configuration options for a workspace account. These configuration options define various setup properties, default behaviours, and custom field definitions for the workspace. Additionally, it provides the workspace administrator contact account address and contact email details. This endpoint is particularly useful for external applications that need to synchronise with the workspace settings. By accessing these centralised configuration options, external applications can ensure consistency in workflows, reduce the need for rekeying shared information, and streamline the app integration process. This endpoint is under construction, contact Datapel Support if you require the use of this resource.
• [Change Log](https://app.theneo.io/datapel/datapel-api/change-log-1.md): See all updates and changes to our API listed by Date. Title Description Title Date Version Description 2024-OCT-28 2.0.1028 New Estimates endpoint added Endpoint Name : estimates Change : Use endpoint to get list of estimated kit and assembly units that can be built based on available component inventory. 2024-AUG-26 2.0.0826 New JobCodes endpoint added Endpoint Name : jobcodes, jobcode Change : Use endpoint to get list of jobcodes and jobcode by Uid. 2024-JUL-24 2.0.0724 Documentation clarification Endpoint Name : all GET endpoints Change : Clarification on use cases for $apply with $filter keywords in OData Standards Support sec 2024-July-12 2.0.0712 New Location Bin endpoint added Endpoint Name : locationbins Change : Use endpoint to get list of location bins. 2024-July-09 2.0.0709 New Attachment POST endpoint added Endpoint Name : attachment Change : Use endpoint to add document attachments to products or order transactions. 2024-July-08 2.0.0708 New WorkspaceOptions endpoint added Endpoint Name : workspaceoptions Change : This endpoint provides configuration and workspace setting information. 2024-July-06 2.0.0706 New AuditEvent POST endpoint added Endpoint Name : auditevent Change : This endpoint is designed to allow integration developers to provide status, security, error and warnings directly to the audit list within the customer workspace. 2024-July-03 2.0.0704 Notice on property retirement Endpoint Name : Inward Order List Property : InvoiceNumber Change : This field causes confusion between Despatch and Sale Order properties and intended as Supplier Invoice Number or Supplier Reference Number. To address the ambiguity the field will be renamed to SupplierNumber . The InvoiceNumber field will no longer be available from 2025-1-1 . In the meantime, both SupplierNumber and InvoiceNumber will be available from the endpoint however it has been removed from the documentation to avoid new builds incorporating retired properties.