[API Reference - Stackable API] Redeemebales -> object bug

[karolinatrzcionka]

When the Validate Stackable Discount is used for the first time, the redeemables -> object is set to "voucher" but the object itself is not present in the API request. When user pastes the voucher id and tries to run the request the payload comes as invalid (see attachment)

User needs to change the object to anything and then back to voucher to get this working

[MaciekVoucherify]

Some 'bigger' issues I have found so far:

1.Create segment - should there be a drop-down list and possibility to select ‘empty’ slots? Shouldn’t it be fixed and set to ‘static’ in Static and ‘auto-update’ in Dynamic? Because now you can select 'empty' field which causes API call to fail. Also when you switch to Dynamic we already have 'static' selected inside it at the beginning. It doesn't cause error, however, as in the code window it says 'auto update'.

2. Also, there is some bigger issue that causes the call to fail all the time - you cannot add customers in both cases. In static there are no fields to be filled with information whereas in dynamic filter object is lacking some information as well.

3. Metadata only limited to strings so far.

4. In orders API 'Download Export' is missing.

5. Problems while pasting customer source_id, in a lot of cases it adds additional spaces or weird signs. (videos on basecamp)

6. In update voucher API call in percentage discount, 'type' field is missing causing the whole call to fail (because of this missing field the 'value' is borrowed from the amount discount). All of other categories have this field so when you do amount, there is amount in the code. In unit, there is unit. But because of this issue percentage always shows amount and this is the error you get: "details": "It is not possible to change Voucher discount type".

7. Export gift card transactions - in the dashboard resource is shown as “-s”.

8. The issue with the App Id and App Token has not been fixed. They still disappear after switching between calls so you either have to refresh the page or paste the keys again.

9. In most of the Validations, Redemptions, and Stackable Discounts APIs within the order body there is another customer object called 'customer object object' same goes for the referrer - 'referrer object object'. This has to be checked again, think there are some mistakes there. In other calls from these categories (redemptions) there is - 'order object object'.

10. Not sure if its a mistake or not but in rollback stackable redemptions I have noticed 2x order object in 200 section, they are one below another.

[janiksam]

@MaciekVoucheirfy @karolinatrzcionka I have addressed the above concerns as follows:

0. Validate Stackable Discounts - that behavior is on readme's side, there is not much we can do here on how they populate values in the Try It section. We could potentially identify a default value, but I don't know if that what we want to do because promotion_tier and promotion_stack are are viable options. We could also go with an example value (as we do in the customer object - customer ID)
1. [ ] - Updated per note/request above
2. [ ] - True - The Create Segments endpoint will need to be updated as noted in the comment. It is one of the work-in-progress endpoints.
3. [ ] - True - I reached out to the readme team on this beforehand and they noted that it would be an big re-write of how they using a certain component so it most likely wont' be a quick solution.
4. [ ] - True - Download Export is now under the Exports API - because there is more than one resource type that can be exported and then downloaded
5. [ ] - Could you please send the link to the basecamp task (please forward through slack)
6. [ ] - True - I don't know why it populates it, even though it should technically not, but I can assume that it is because I have the value defined as a default under the amount definition because it seem to me (please test this if you can to confirm) that this is required for the AMOUNT type discount. I have fixed this by defining it as an example value and it should not affect the other discount types.
7. [ ] - True - this has been reported to our development team
8. [ ] - There have been several updates to the security and server objects that should have removed this behavior. Please verify to see if API keys persist through the different pages.
9. [ ] - I have tried to eliminate these repeated objects, please let me know if there is any remaining so we can address
10. [ ] - I think this is the way the API response was designed. We can touch base to see if there is something that needs to be changed. But I can see from the examples that there are two order objects in the response.

[karolinatrzcionka]

@janiksam regarding Validate Stackable Discounts issue, I think that setting one of the dropdown values as default should do the trick. The rest of the values (promo tier and stack) will still be there and the user will have the possibility to switch to one of them, right?

[janiksam]

Just writing a note here from our conversation on slack so we can track progress. I've addressed the concerns listed in the above git hub bug report and my comments can be found here. And the updates in this pull request. We tested the login today with Maciek and it seems to be working fine except when we have metrics enabled (history). I have disabled the history to get rid of undesired behaviors. can share a summary of what we found during our sync today when the history is enabled (which enables a replay request button). I've also went through the endpoint comments left by Maciek and addressed all 18 except these 2: https://github.com/voucherifyio/voucherify-openapi/issues/84#issuecomment-1514778874 https://github.com/voucherifyio/voucherify-openapi/issues/283#issuecomment-1505291878

[janiksam]

@karolinatrzcionka, regarding above comment for Validate Stackable Discounts. You are correct. I have updated the default value to be voucher