When posting a sales invoice with 500+ invoice item lines to the endpoint "/sales_invoices" the invoice is being created successfully in Sage, however, the response to the Post request is the following Bad Request:
- Bad Request 400 - The backend has not responded within 28s while proxying this request. Please try again later. (Proxy)
Any help on this one would be very much appreciated.
I am using Sage Business Cloud Start
an invoice with 500 line items sounds huge. The API does not have a limitation, but a 400 response might be expected from time to time. The issue is that the backend of Sage Accounting is creating the invoice but it takes longer than the timeout of our API infrastructure.
The 400 is returned because the request took longer than 28 seconds, but it is actually executed in the backend. This is why you can see the created invoice later, but not as a response to your large request.
My recommendation would be to not try to create such big invoices, maybe you have a way to either split it to multiple invoices or combine similar line items of the invoice.
I hope this helps and makes some sense.
Thanks for the response. My issue here is the that request I make to the Sage API is returning a 400 Bad Request, which indicates to the client that the request failed. However, the request has actually succeeded within Sage, this has to be incorrect? If the invoice has been created within Sage then the API response should be 200 OK.
Is it the case that the Sage Business Cloud API is subsequently calling another API to create the invoice and this is what's timing out? if this is the case then would it b possible to increase your timeout to something greater then 28 seconds (which I assume is just a default connection timeout)?
I'm coming back with an approach you can take to solve your problem:
The API has a feature which allows you to make idempotent requests (learn more about this here:https://developer.sage.com/api/accounting/guides/idempotency/)
This allows you to submit the creation of an invoice asynchronously. After you sent in an object with a given idempotency ID, you get back a success response that the request arrived successfully in our application.
This should be a way to not receive Bad Request issues because the execution took too long. I hope that helps.