This is shortcut for the original /orders endpoint to add orders into BonifiQ
An important part of the program points is awarding point for purchases that customers made. In order for points to be given we need to receive purchases that the customers made.
Order State
In BonifiQ an order can be in one of these 3 states:
- Completed: An order in a completed state will receive points according to the configuration in BonifiQ panel
- Canceled: An order that is incomplete, not paide or returned. If any points was awarded they will be removed
- Pending: An order that is neither Completed nor Canceled.
You dont need to send pending orders to BonifiQ. You can send them when they are completed (or canceled).
The pending state exists for integrations that requires this flow.
To set the State of the order use the IsCompleted and IsCancelledOrReturned fields. Whenever one of them is true the respective OrderCompletedDate or OrderCancelledDate must be set.
Order Status
The OrderStatus field is the status in the platform. This is merely informative
Order Total
This is a very important field as it determines how many points the user will be awarded. This value must not consider shipping costs, taxes, discounts, promotions, giftcard, etc In other words, the value must be what the customer really paid discounted shipping
Coupon
The Coupon field is important as is the way BonifiQ is aware of an used coupon or reward. Use this field as follow:
- If this order used a reward from the
Redeemendpoint, them pass here theExternalCodereturn from the redeem api call - If this order didt not used an reward from BonifiQ pass here the coupon used by the customer, if available
Authorizations
Use API Basic Auth Keys
Body
Purchase Order Model
This is the Id in the client store.
Date of the customer's purchase.
Date the order reached the completed state (usually it's invoiced or delivered).
if the order is cancelled, contains the date.
Status at the client's order system.
if true the order was cancelled or returned.
If true it means the order has reached its final status and points can be awarded to the consumer.
Can be used at Loyalty Programs. Important: these values should not include Shipping costs.
Buyer registration.
Products listed on the order.
the date from the last update on this order.
Coupon code used on this order.
This is a key-value list of extra information regarding the order. It could be informative only or being part of an business rule to be used later.
The Payment Method used in this purchase. Should be the more specific as possible (ie: instead of using "Credit Card" use "Visa Credit Card" and so on). This field can be used later on to create extra points purchase rules
A Branch is physical location or outlet of a store (loja, filial, etc). This is used to receive information of which store the purchase was made. It can be later used to create rules for points or filtering reports.
A sales person is the person responsible for the sale. It can be used for filtering reports.
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.