Vending API Events: Handle Delayed and Duplicate Updates Without Double-Counting Sales
WEIMI INSIGHTS / DATA INTEGRATION
Receiving an event twice should not create two sales.
Define transaction identity, event timing and reconciliation before connecting vending data to your own reporting system.
IDENTITY
Which transaction does this update describe?
ORDER
When did the event happen and when did it arrive?
RECONCILIATION
How will missing or inconsistent records be found?
Agree the data contract and update rules before importing events into reports; message delivery and business activity are different counts.
01 / BUYER NOTES
Start with the provider’s actual event contract
A vending platform may offer event notifications, periodic reports or a query interface. Confirm what the proposed service supports and obtain the documentation. Do not assume the presence of an API includes webhooks, guaranteed ordering or a complete historical feed.
Ask which business events are available and what each means. Order creation, payment authorisation, physical delivery and final settlement describe different stages. A reporting system should not count every stage as a separate sale.
This guide sets out integration design questions. It does not claim that a particular WEIMI platform provides the event fields or delivery guarantees discussed here. Verify the actual interface before building around it.
02 / BUYER NOTES
Use stable transaction identity for business records
The receiving system needs a dependable reference connecting updates about the same transaction. Ask whether the source provides a unique transaction identifier and how its uniqueness is scoped. A cabinet ID plus a local sequence may require different handling from a globally unique reference.
Keep event identity separate where the interface provides it. Several events can belong to one transaction, and a repeated delivery can represent the same event. The integration team should define the database rules using the actual contract rather than guessing from sample values.
Do not use product name, price and timestamp alone as a supposedly unique key without assessing the risk. Two customers can buy the same product at the same price close together. A convenient approximation can merge legitimate activity or create duplicates.
03 / BUYER NOTES
Distinguish event time from receipt time
An update may arrive later than the business action it describes. Record the relevant timestamps supplied by the interface and the time your system received the message. Use explicit time-zone handling so reports remain interpretable across locations.
A delayed update should not automatically be reported as a new sale in the current hour if the metric is intended to describe when purchases occurred. Define the reporting rule and how late-arriving data changes an earlier period.
If the source does not provide the timing required for a report, state that limitation. Do not label a receipt-time chart as exact customer purchase time without evidence. Accurate reporting begins with the meaning of the available fields.
04 / BUYER NOTES
Process repeated updates according to the contract
Some interfaces can redeliver notifications or return records already seen in an earlier query. The receiving system should use documented identity and state rules to avoid counting the same business activity twice. Confirm the provider’s behaviour rather than assuming every message is new.
For a hypothetical transaction T42, receiving a completed update twice should leave one completed transaction in the business view when both messages represent the same event or state. The implementation must still preserve enough diagnostic information to investigate delivery issues.
Do not confuse ignoring duplicates with ignoring later corrections. A subsequent valid update may change the transaction outcome or add a relevant adjustment. The integration needs a defined way to apply changes while retaining an appropriate history.
05 / BUYER NOTES
Do not let arrival order overwrite stronger evidence
Updates may need to be interpreted using sequence information or state rules defined by the provider. Ask whether ordering is guaranteed and how the system represents corrections. Without those details, a late earlier-stage message could make a completed transaction appear pending again.
Create a state-transition review with the integration team. Identify permitted transitions, unresolved states and the source of authority when records disagree. Avoid inventing a generic rule that every numerically larger status or later arrival is always correct.
If the API lacks information needed to resolve an ambiguity, route it to reconciliation or support. An uncertain record should not be forced into a success category merely to make a dashboard total balance.
06 / BUYER NOTES
Build reconciliation alongside the live feed
A live feed can help operations react quickly, while a periodic comparison can identify missing or inconsistent records. Ask which source reports or historical queries are available for reconciliation and how their scope relates to the event stream.
Compare consistent periods and definitions. A machine sales report, a payment report and a bank settlement can legitimately represent different stages or amounts. Reconcile them through the relevant references and documented rules instead of assuming all totals must match immediately.
Test duplicate delivery, delayed arrival, a missing update and an authorised correction using the provider’s permitted test environment. Keep real customer and payment data out of development examples where it is not needed. Acceptance should show the correct business result as well as successful message receipt.
Three records with different meanings
Incoming message
Represents: One delivery of information to your system.
Do not assume: One message equals one new sale.
Transaction record
Represents: The current interpreted state of a business transaction.
Needs: Stable identity and documented update rules.
Reconciliation result
Represents: A comparison of defined records over an agreed scope.
Needs: Consistent timing, amounts and state definitions.
PRACTICAL ANSWERS
Questions worth asking before you order
Does a webhook delivery prove the product was dispensed?
Only if the documented event specifically represents that outcome and the underlying system supports that evidence. Read the event definition.
Can I count API responses to calculate sales?
Not reliably without understanding the records. Responses can include repeated updates, non-sale events or several records for one transaction.
Should late data be discarded?
Not automatically. Apply the agreed reporting and correction rules so valid delayed activity is handled accurately.
YOUR NEXT STEP
Review the data contract before building the dashboard
Share your reporting requirements and integration architecture with WEIMI. Confirm the available identifiers, event meanings and reconciliation options for the proposed platform.
Explore equipment →Discuss your requirements →