Sage 200 has a dedicated developer and partner community who use our developer tools extensively to customise the software to customers business requirements. We'd like to hear feedback on areas where the API needs to be extended.
Thanks for that, the Sage 200 API is in the process of being built out and the onboarding has also changed. Its worth reaching out to your partner or your developer to see if they can support with an API connection. Details on the API onboarding can be found here, and information on what is available in the API is here.
We currently use DPD, for which we do have an API, but I am told that the API has never worked properly or efficiently and is very unreliable.
We have been looking at using couriers Parcel Force and TNT/Fedex as alternatives. In reality we are likely to use at least 2 couriers (for different types of parcel), but incorporating an API for 2 different couriers just seems a step too far, when I the one we have now doesn't work very well on its own.
Despatch : There should be API's in place to interact with ALL the popular Courier software packages, to automatically load addresses, print labels, import tracking numbers etc. Financially we should change courier, but can't, because Sage does not have an API that will work with any of the 3 alternative courier networks we have considered.
If you try to call any API function the normal behavior is to return an xml with success or failure details, i.e. trying to create a supplier invoice for a supplier that doesn't exist. This all works well, however if the API fails because there are no available user licences, it just fails. There is no error status returned as part of an error XML. We use Codeless platforms for a lot of our Sage200 Integration and not enough user licences available is a really difficult error to deal with because there is no error.
Sage 200 has a dedicated developer and partner community who use our developer tools extensively to customise the software to customers business requirements. We'd like to hear feedback on areas where the API needs to be extended.
Jo Kirkup
almost 6 years ago
in API
0
Idea Accepted - Gauging Support
The ability to have an endpoint for Journals would be very useful as its standard on other systems
Thanks for that, the Sage 200 API is in the process of being built out and the onboarding has also changed. Its worth reaching out to your partner or your developer to see if they can support with an API connection. Details on the API onboarding can be found here, and information on what is available in the API is here.
We currently use DPD, for which we do have an API, but I am told that the API has never worked properly or efficiently and is very unreliable.
We have been looking at using couriers Parcel Force and TNT/Fedex as alternatives. In reality we are likely to use at least 2 couriers (for different types of parcel), but incorporating an API for 2 different couriers just seems a step too far, when I the one we have now doesn't work very well on its own.
thanks for the comment Brenda, could you let us know which courier networks you use?
Despatch : There should be API's in place to interact with ALL the popular Courier software packages, to automatically load addresses, print labels, import tracking numbers etc. Financially we should change courier, but can't, because Sage does not have an API that will work with any of the 3 alternative courier networks we have considered.
If you try to call any API function the normal behavior is to return an xml with success or failure details, i.e. trying to create a supplier invoice for a supplier that doesn't exist. This all works well, however if the API fails because there are no available user licences, it just fails. There is no error status returned as part of an error XML. We use Codeless platforms for a lot of our Sage200 Integration and not enough user licences available is a really difficult error to deal with because there is no error.