Introduction
- 20 Feb 2024
- 4 Minutes to read
- Contributors
- Print
- DarkLight
- PDF
Introduction
- Updated on 20 Feb 2024
- 4 Minutes to read
- Contributors
- Print
- DarkLight
- PDF
Article summary
RetailVista ERP is an enterprise solution for retailers that stores valuable data to support retail processes. It consists of a frontend GUI, with other frontends being RetailVista Mobile and RetailVista POS. The backend is Retail3000, which currently has a SOAP-based API interface and a REST API interface. The webservices will become obsolete after 2024, with the REST API replacing them. Currently, GET functionality is available for all entities, and write and delete functionality will be added in the next major update. RetailVista ERP and Retail3000 are designed on an API-first basis, allowing third-party developers to access and rebuild the UI parts. The application is quick and responsive, relying on the availability and responsiveness of the API environment. Integration with Retail3000 should consider configurable workflows and different implementations across companies and instances.
Did you find this summary helpful?
Thank you for your feedback
RetailVista ERP is an enterprise solution for retailers to maintain all there valuable data to support any kind of retail process. When we are tallking about RetailVista ERP, we actually mean the frontend GUI. Other frontends are RetailVista Mobile and RetailVista POS.
The backend of RetailVista ERP is Retail3000, our service platform. At this moment it consists of a legacy webservice SOAP based API interface, together with a REST API based interface. The webservices will get obsolete after 2024 while the REST API is replacing all the webservice methods. At this moment (Q1 2024), GET functionality is available for all the entities of Retail3000. We are working hard to get the write and delete functionality available on the next major update. When that is finished, we offer full CRUD operations on every entity.
RetailVista ERP and Retail3000 is a unique combination because it's fully designed on API-first base. All the API methods we are offering are being used by our frontends also. We use the same stuff, there is no other entrance for our own UI frontends. This makes it possible that we can guarantee that every frontend UI part can be rebuilt by yourself, all data is available to third party developers as well.
We have taken care that RetailVista ERP is a quick and responsive application. Because it's based on the above described API, you will understand that it's very important for us that the API environment is available and responsive. We offer the possibility to create any kind of API integration, but always based on fair use policy. That's a wide description, but it actually means that we expect 3rd party developers to think about their designs and not to waste valuable hardware resources on our side. Besides the costs we have to make on hardware, it might affect the user experience of a slower frontend. In this article we share our best practices and quality guidelines when building API integrations.
Because REST API is relative new within Retail3000 and not completely finished yet, this documentation is also in progress. Feel free to comment on articles here so we can improve where necessary. For those familiair with our previous webservice API interface, there are a few major differences:
| Reverse proxy | With webservices, we where using a reverse proxy as gatekeeper. To access this proxy, a valid reverse proxy API token has to be submitted and the proxy was responsible for counting traffic and eventually blocking access in case of very high traffic. It was not a rate limiter and it wasn't able to temporary suspend access when too much data was requested. With the REST API, there is no reverse proxy server anymore. |
| Rate limiting | Instead of a reverse proxy server, the REST API will use rate limiting. At this moment (Q1 2024) there is no rate limiting active, but this will be the case on the next major update. We don't have information on the limits that will be applied from that moment, but somewhere in 2024 we will release that info. In the meantime we advise to track already for a 429 error which will indicate a rate limitation is active. And of course, keep track of our best practices not to flood our systems. Both will be important when the rate limiter will become active from our side. |
| Sealing | The webservices based API implementations were allowed to access all entities and execute all methods. With the REST API implementation, we are going to 'seal' an API integration as part of the certification process. We will track the used methods and evaluate the parameters used. All the used methods are part of a seal which will part of the production API token. With this seal active on the production environment, it will not be possible to call other methods not part of the seal. When new methods are added to an update of an API integration, it needs to be certified again to get the seal updated. |
| API token | The meaning of an API token will change when moving from webservices to the REST API. With webservices, the API token was used for the reverse proxy server. Besides this token, a username and password was still required for the final authentication, after passing the reverse proxy server. With REST API, only an API token is required and that token is used as authentication token. RetailVista ERP administrators can create their own tokens from within user management. |
| Certification | The webservices based API implementations didn't require certifications. As described in the explanation on sealing, API integrations on our REST API interface will require certification though. Without certification no seal is available, making it impossible for an API integration to communicate with a production environment. |
Please keep in contact with us when you create new integrations. We prefer that you use REST API instead of webservices, but because write and delete functionality is only available yet on a very small scale, it might be possible that you still have to use webservices. Another approach can be that we decide to give priority to the entities for which you need write and delete access.
A lot of the workflows are configurable in a lot of ways by changing settings or setting up different scenario's and assigning these to the related entity. This is something to remember when integrating with Retail3000. It could be that different behavior occurs between companies and/or instances, due to different implementations. Ensure that you know the variables that are important to your application. We will cover some of the more general ones while going through the modules but there are too many to address them all.
Was this article helpful?