How to test an auction integration before going live
The visible auction interface is the easy part to demo. Most of the risk sits in what happens when the state underneath it changes.
Before production you will want to see how your application handles registration, auction and lot data, bids from competing bidders, outbid states, reserves, proxy bids where they apply, timing, closing, errors and dropped connections. This guide is not an exhaustive QA specification. It explains why a realistic sandbox is a good place to find these problems early, and gives you a workflow and checklist to use.
Last updated: 7 October 2026
Why the interface is only part of it
A lot page with a price and a button looks finished long before the application is. A bidder does not experience the layout. They experience whether the price they saw was the price they bid against, whether they were told promptly that someone passed them, and whether the lot closed when and how they expected.
Those behaviours depend on authoritative auction state held by the server. Your interface displays that state and sends requests towards it. Testing is largely about confirming that the two stay in step when several people act at once and when connections misbehave.
If you are still deciding how much of this to own, read should you build your own auction engine first. The rest of this guide assumes you want to build the website and experience yourself.
What is an auction sandbox?
An auction developer sandbox is a non-production environment where you can integrate with auction infrastructure and exercise bidding workflows without touching a live customer auction. You connect your application, look at realistic sales and lots, and bid as several test users.
The Bidlogix sandbox is a private, test-only environment with sample sales, lots and registrants. Credentials are issued by the Bidlogix team and emailed to you, and it includes the BidJS embed and BiddingAPI REST and WebSocket access. Sandbox data is test-only, with no real payments or real emails.
Request access online through the sandbox page. Eligible developers can start a 30-day trial with a card at checkout; the trial begins when checkout succeeds, not when the request is submitted. It continues as a paid monthly subscription until cancelled. Credentials are typically emailed within one business day of the trial starting. Existing clients and some regional requests follow a different route, so check the current terms and eligibility on that page rather than assuming the offer applies to every request.
The testing advice in this guide is general. Apply each point only where the feature is supported and configured for your sandbox, and ask the Bidlogix team if you are unsure what your access includes.
What you can build and test
There are two routes, and they test different things. They are not feature-for-feature equivalents, so do not assume everything in one exists in the other.
BidJS: embed the bidder experience
BidJS is the frontend route. It provides bidder-facing auction components that you embed in a website, while the surrounding pages, navigation and branding stay yours.
Here you are testing the embedding: page placement, scripts loading, behaviour inside your layout, and how your site and the embed coexist on mobile.
Explore BidJS →Bidding API and SDK: build your own interface
For a custom auction application, Bidlogix provides REST, WebSocket and TypeScript SDK access. You design the screens and journeys.
Here you are testing your own state handling: how you render updates, represent pending and outbid states, and recover after a disconnect. Note that auction setup and administration still use Bidlogix platform workflows.
Explore the Bidding API →For the wider picture of building the site around either route, see how to build an auction website.
A practical prototype workflow
A sensible order is below. The steps are a general approach, not a prescribed Bidlogix procedure, and the exact setup details come from the current documentation and your onboarding emails.
Choose a route
Decide whether BidJS, a custom interface on the Bidding API and SDK, or a mix suits the product. Test the route you expect to ship.
Request sandbox access
Use the sandbox request form. Credentials are issued by the Bidlogix team and emailed to you.
Connect the application
Follow the current BidJS and Bidding API documentation for your route. Ask the team to confirm SDK access and any configuration you are unsure about.
Work from representative data
Start with the sample sales, lots and registrants. Where your access allows, create or configure representative test auctions and lots using the documented platform/admin tools. Otherwise, agree suitable examples with the team. Confirm that reserve or proxy-bid settings you need are available in your sandbox.
Use several bidder accounts
Competing bidders are the point. Keep at least three registrants open in separate browsers or devices.
Exercise changing state
Bid, get outbid, watch the price change on other screens, and run through closing.
Break the connection on purpose
Go offline mid-auction, switch networks, suspend a tab, then recover.
Check small screens
Run the whole journey on a phone, not just a narrow desktop window.
Review the journey end to end
Walk it as a new bidder, then write down what you still need before production.
Concrete test scenarios
Each scenario below is a general recommendation with the observation you should be looking for. Treat the server as the authority: if your screen and the server disagree, the screen is wrong.
Two bidders, one lot
- Do
- Two registrants bid in quick succession on the same lot from different browsers.
- Expect
- Both screens converge on the same current price and leading bidder. The losing screen shows a clear outbid state rather than a stale price.
Bid below the minimum
- Do
- Submit an amount lower than the next valid bid.
- Expect
- The bid is rejected, the interface explains why in plain words, and the displayed price does not change.
Maximum bid against a manual bid
- Do
- Where proxy bidding is configured, one bidder sets a maximum and a second bids below it.
- Expect
- The server decides who leads and at what price. Your interface never reveals the first bidder’s maximum and does not assume its own bid won.
Reserve not met
- Do
- Where a reserve is configured, bid below it, then above it.
- Expect
- The interface reflects reserve status only as far as your configuration chooses to show it, and the result at close matches what the server reports.
Bid near the close
- Do
- Place a bid shortly before the scheduled end, with another bidder watching.
- Expect
- Your countdown is treated as a display aid. If the end time moves or the lot closes, the interface follows the server state.
Dropped connection
- Do
- Disconnect a bidder, let others bid, reconnect.
- Expect
- The reconnected client shows current price, leader and end time, not the values from before it dropped.
Uncertain submission
- Do
- Cut the connection just after pressing the bid button.
- Expect
- The interface shows an unconfirmed state, then reconciles against authoritative state before telling the bidder what happened.
Uncertain submissions and reconnection
The hardest state to design is not success or failure, it is not knowing. A bid was sent, the connection dropped, and no confirmation arrived. The bid may have been accepted, rejected or never received.
A safe general pattern is to mark the attempt as unconfirmed, avoid blindly resending, and on reconnect refresh authoritative state before telling the bidder anything. Whether your client replays events or re-fetches current state is a design choice. What matters is that it ends up showing what the server holds. This describes a testing approach, not a built-in retry or replay behaviour of any Bidlogix product, so confirm what the WebSocket and API offer in the documentation.
Testing checklist
Tick items off as you go. Skip anything your sale does not use. Ticks are not saved if you leave the page.
Why not just mock the auction engine?
Mocks are good for development. They let you build components quickly, write unit tests and work offline. Keep them for that.
A mock only does what you told it to, though, and the mistakes you make about auction behaviour are baked into it. If you assume a bid response always arrives before an update event, your mock may agree with you; actual delivery order depends on the documented integration and network conditions. Competing bidders, rejected bids, changing end times and live events need integration testing as well as simulation.
So connect a prototype to genuine auction infrastructure fairly early, then keep the mocks for fast tests of your own code. The two are complementary.
From sandbox to production
The sandbox exists so you can validate an approach: which route fits, how your interface copes with changing state, and what you still need to build. It is test-only, and production requirements such as your sale setup, regions and volumes are a separate conversation.
Before a release, document which parts your team owns: identity and bidder approval, catalogue presentation, supported auction rules, payment or post-sale workflows, and support when bidding fails. Keep sandbox and production configuration separate and never expose server-side secrets in browser code. Plan how you will observe failed bids and disconnects without logging credentials or unnecessary personal data, and agree who handles incidents.
A successful prototype is not a capacity test or a guarantee of production readiness. Confirm expected concurrency, supported features, operational responsibilities and any deployment or contractual requirements with Bidlogix. Recheck the full journey against the agreed production configuration before launch; do not assume sandbox data or settings transfer automatically.
When you know what you need, contact Bidlogix about production requirements. Sandbox availability, scope and permitted configuration can differ by situation, so confirm anything your plans depend on rather than assuming it carries over.
Try it against a real bidding engine.
Request a private developer sandbox with sample sales, lots and registrants. Current terms and eligibility are on the sandbox page.