Home / Documentation / Notifications
Documentation
Notifications and webhooks
When something happens on your auction — a lot closes, a bidder is outbid, a closing time is pushed back — Auction Experts tells your system straight away, without you having to ask.
The alternative, and what most systems do without this, is polling: asking “has anything changed?” every thirty seconds, forever, almost always hearing “no”, and still being half a minute behind. You tell us once where to reach you, and we do the reaching.
We tell you what changed; you fetch what you need
A notification carries two things: what happened, and which thing it happened to. We call an address you choose, carrying the identifier of the lot or auction concerned, authenticated with a secret agreed between us. No lot description, no price, no bidder name.
https://your-site.example/webhook/lot-ended/3f2504e0-4f89-11d3-9a0c-0305e82c3301Nothing else. Your system then asks our API for whatever detail it needs.
That reads like a limitation and is the opposite. The reason is staleness. If we packed the closing price into the notification, that price would be a photograph taken at the moment we sent it — and by the time it arrives, is read and is acted on, it may have moved. Your system would be deciding on a number that was already out of date, with no way of knowing.
Because we send only an identifier, your system comes back and asks for the current state, and whatever it gets is true right now. It is impossible to act on stale data, because we never send any.
There is a second benefit that shows up over years rather than days. Most notification systems accumulate fields — every integration wants one more thing added, and each addition is a new value that can quietly disagree with reality. Ours cannot drift, because there is nothing in it to drift. That is why the format has never needed a version.
What we can tell you about
Eighteen notifications. Each one is switched on individually for your auction house — you receive the ones you have asked for, not all eighteen by default. Each also has a technical identifier, which we confirm with you when we switch it on; the descriptions below are the contract.
Bidding — the time-critical ones
| What happened | Why it matters |
|---|---|
| A closing time was pushed back | A bid landed in the final moments, so the lot stays open longer. Your countdown is now wrong. This is the most urgent thing we send. |
| Someone was outbid | Drives the “you’ve been outbid” nudge that brings a bidder back. Fires for automatic proxy bids too, not only manual ones. |
| A bid was accepted | That bidder is now winning. Live leaderboards, bid counts. |
| A bidder opened the bid screen | An interest signal, ahead of any actual bid. |
Lots and auctions opening and closing
| What happened | Why it matters |
|---|---|
| A lot closed | Bidding is over on that lot. Triggers your end-of-lot handling: result pages, invoicing, notifying the winner. |
| The last lot of an auction closed | The auction is genuinely finished, as opposed to merely past its scheduled end time. Staggered closing means the two can be hours apart. |
| A lot opened for bidding | Go live on your side at the same moment we do. |
| An auction opened for viewing | The catalogue is public. Time to promote it. |
| An auction reached its end time | The scheduled close, whether or not every lot has finished. |
| A reminder came due | Someone asked to be told before a lot closes, and now is the time. |
Catalogue changes
| What happened | Why it matters |
|---|---|
| A lot was added, edited or removed | Keeps your catalogue in step with ours without a nightly re-import. By volume this is the busiest thing we send, by a wide margin. |
| An auction was created | A new sale exists. |
| An auction was edited | Dates, description, terms — anything on the sale itself. |
People registering
| What happened | Why it matters |
|---|---|
| Someone started registering | The opening edge of the funnel, and the only way to spot an abandoned signup — giving up produces no notification of its own. |
| An email address was confirmed | They clicked the link. For most auction houses this completes registration. |
| A phone number was verified | Only where SMS verification is switched on. |
| A lot was added to a watchlist | The clearest interest signal there is. Feeds “lots you’re watching are closing soon”. |
| A lot was removed from a watchlist | Interest withdrawn — the same signal, in reverse. |
What happens when your site is down
This is the part worth reading closely, because it is the part most systems get wrong.
We write it down before we send it. The notification is recorded in our database first, and only then transmitted. If anything goes wrong afterwards, the record is still sitting there waiting.
We try immediately — the first attempt is within seconds of it happening.
If that fails, we keep trying. Seven attempts, spaced progressively further apart: 30 seconds, 2 minutes, 10 minutes, 1 hour, 6 hours, 24 hours. That covers roughly 31 hours, chosen deliberately so that a site which goes down overnight or over a weekend still gets everything it missed once it comes back.
A separate sweep runs every minute looking for anything that slipped through the fast path. A failure there costs a short delay, never the notification itself.
Two responses stop the retries early. If your system reports that the address does not exist, or refuses our credentials, we stop rather than hammer it seven times — those are wrong settings, and repeating the call will not fix them.
A repeat is possible, and safe
The same notification can arrive twice. If a delivery lands but the confirmation back to us is lost, we retry. That is by design: better twice than never.
It is safe because every notification carries an identifier, so acting on the same one twice reaches the same result. Key your handler on that identifier and ignore one you have already processed.
Order is not guaranteed either. A notification that spent an hour in the retry ladder arrives after ones sent since, so arrival order is not event order. The safe pattern follows from the first rule on this page: the notification tells you that something changed, and you fetch the current state through the API — never apply notification contents in the order they arrive.
Switching one on
Tell us where to send it and we will switch it on. It takes effect on the very next occasion — no software release, no downtime, and nothing to deploy on your side beyond the endpoint itself.
There is no self-service screen for this today; it is a configuration change our team makes. In practice that is fast, and it is worth saying plainly rather than implying a dashboard that does not exist.
Three things worth understanding
The countdown that fixes itself. A bid arrives eight seconds before a lot closes, so the closing time moves. Every other site showing that lot is now counting down to the wrong moment — unless it is told. We tell you, within seconds. On any auction with automatic extension enabled, this happens routinely.
Stop asking, start being told. Before: your system asks “anything new?” every thirty seconds, thousands of times a day, almost always hearing no, and still half a minute behind. After: silence, until something actually happens. Less load on both sides, and faster.
Nothing gets lost overnight. Your site goes down at 2am. Ours does not stop and does not give up — it holds everything and keeps trying for the next day and a bit. When you come back up, you get the lot.