Add or remove points from a customer
This endpoint allows you to add or remove points to/from a customer.
Some important remarks
- Use
OperationType=0if you want to add points. UseOperationType=1if you want to remove points - If you want to add points, use a
positivenumber (eg: 10). - If you want to remove points, use a
negativenumber (eg: -10)
The ChangeKey field
This field allows you to create idempotency: even if you make the exactly same request twice it will change points only once. As distributed systems should be fault-tolerant it may result in requests being done more than one time. Not using the ChangeKey may duplicate a change-point request thus adding or removing more point than intended
How to use this field
Inform some string that is unique for this change.
For instance: if you are adding 10 point for customerID=ABC regarding the OrderId=123 purchase he just made, our key could be ADD-ABC-10-123
If you dont need this kind of verification you can just use some time-related string, such as 2023-01-01 23:59:00:000
The Reason field
This field is important to track why some point are given/taken from the customer. This information is internal-use only, it will not be visible to the customer.
Authorizations
Use API Basic Auth Keys
Path Parameters
Body
Point changing information
Change Points from a customer. Either E-mail or CustomerId are required
Amount of points to add or remove from customer. If adding it must be positive. If removing it must be negative
Either is adding or removing points from customer
0, 1 Information regarding why these points are being add/removed. Internal information only. Required.
This is a unique key for this add/remove point removal. If you try to use the same key more than once it will result in error
Customer-facing reason displayed in the customer's points history. Optional, max 255 characters. HTML tags are stripped automatically. If null, empty, or whitespace, the default system message is shown.
Response
Standard response envelope used by the External API.
Error message returned when the request fails validation or processing.
For warnings and successful responses, consumers should usually inspect Result, Code and Severity first.
Legacy numeric error code derived from internal API errors when available.
This field is relevant only for error flows that use ApiResponseErrorDescription.
Business payload returned by the endpoint.
Endpoint-specific business code formatted as a two-digit string, such as 03 or 07.
This field is available for success, warning and error outcomes.
Symbolic enum name associated with Code, such as CheckoutNotFound.
Final severity of the response.
Success means the action completed as expected, Warning means the request was valid but the business outcome is informational or non-ideal, and Error means the request should be treated as a failure.
0, 1, 2 Convenience flag that is true when Severity is Warning.
Warnings are valid 200 OK business outcomes and should not be handled as transport or validation errors.
Indicates whether the request failed and should be handled as an error response.
This flag is reserved for real API errors; warnings must keep this property as false.