TRANSACTION
Endpoints
Get transactions
GET /transaction
Description: Returns transactions based on the provided filters. If no date filter is provided, the default search returns data from the last 30 days using transaction date as reference.
Note: If no date filters (date_from and date_to) are provided, the API returns data from the last 30 days by default.
Note: When applying customer data filters, anonymous reviews are excluded from the final result..
Responses:
200 OK: Returns a list of transactions.201 Created: Returns an object containing the link to the CSV file.400 Bad Request: Invalid parameters.404 Not Found: No transaction found.
Return Object:
Create transaction
POST /transaction
Description: Creates a new transaction. It is necessary to have previously registered the store and the employee.
Note: Created transactions do not update the customer's CPF.
Note: This endpoint accepts both internal (store_id, employee_id, customer_id) and external IDs (store_integration, employee_integration, customer_integration). Make sure to use only one type of ID per resource in each request.
Note: If the internal or external customer IDs (customer_id or customer_integration) are not sent, it is possible to create the customer by providing the name, document, email, phone, and/or phone2 parameters.
Note: If the name field is not sent, it will assume the value of the cpf or email field, according to the defined business rule.
Responses:
201 Created: Transaction successfully created.422 Unprocessable Entity: Validation error.
Get transaction by id
GET /transaction/{id}
Description: Returns a transaction based on the provided id.
Responses:
200 OK: Returns the transaction.400 Bad Request: Invalid ID.404 Not Found: Transaction not found.
Reverse transaction by id
DELETE /transaction/{id}
Description: Reverses a transaction, removing it from reports but keeping it in the system.
Responses:
200 OK: Transaction successfully reversed.400 Bad Request: Transaction not found.
Using transactionId for assertive queries:
For the current Infrastructure, queries that sum transactions over long periods are major offenders, as they overload our servers and generate slowness both in the query in question and in the next ones. Therefore, it is recommended:
- Queries that perform a quantitative scan (count) or search within a time interval, using
transactionIdas a search parameter: