Hello, I don't think the checkSnipeStatus api endpoint is working.

This returns an empty page
curl -v "297298588182"">https://api.bidslammer.com/checkSnipeStatus?key=XXX&item_no=297298588182"

I wasn't able to get a response for any item won or loss.

Hello Dax,

Thank you for your question about the API call. I'll try to reproduce the problem on our end.

If a software change is needed on our end, it will be a few days to put the app through the full test suite before releasing new code.

Thanks! There's also a typo in the API docs referencing fetchItem instead of checkSnipeStatus

Thanks again. In the meantime, would love to hear about how you are using the API. If you have a moment.

Buying pokemon cards :)

Cool :) Are you using a program? Cron? The suspense is unbearable.

I'm the dev for the site. I want to make a collector site. My thing is comics, and of course we have so many collectors. I would love to hear any ideas you have about collecting, and features you wish you could find online.

Customers drive features. It is known :D

Just for our own inventory tracking. We compare the win list vs what we receive in shipping. We pull down the API of our wins, and we compare it to the vault scrapes :)

so thank you!

I also see this happen kind of often. We won this snipe:
17062924371">https://www.ebay.com/p/17062924371

But it shows as won = 0 and success = -2

Do you think there is a bug in the winner checker?

Thanks for asking. Sniping is easy. The hard part is determining win/loss status.

Even if we place a bid at 1 millisecond before closing, and it returns "Success," someone could still beat the bid at 1/2 millisecond.

The only true way to determine win/loss is to use their "GetMyeBayBuying" call... but it sometimes takes 5 minutes for them to register a win.

So we split the sniper into 2 parts. The sniper--- and a post-processor. When the sniper is finished it sets status of -2. This triggers the post-processor, which runs indefinitely and sets success = -3. Then it evaluates with everything it possibly can.

That's why checkSnipeStatus() isn't immediate.

I'm checking into this in detail ... trying to decide the best way to return the status. At the very least, we'll have to return "in progress" or something.

Any thoughts you have on the matter are greatly appreciated.

Interesting. I've got 2000 auctions that ended within 6 days ago. I see -2 for 818 of them. Does that mean they haven't been through the post-processor?

Ah - that's the answer. Assuming you are familiar with MySQL:

We grab a LIMIT, and WHERE the ending time is within the last hour. My thinking is that we just need to increase the LIMIT and extend the ending time.

I will need some more time to look into this --- in 25 years of running this, there are always new situations that arise. I appreciate your feedback and patience.

Haha I’m too familiar with MySQL :)

That makes sense. I must have enough auctions to go beyond the hour. How many auctions does eBay let you check? My API is limited to 5000 a day, so I have to be very careful.

We are bound by a strict agreement with eBay that prohibits us from providing API access in a way that might enable users to bypass their own usage limits.

If our API is being used in this manner, it could jeopardize our standing with eBay and potentially lead to our service being blacklisted.

Accordingly, I need to clarify the following:

1. Approximately how many API calls are you making per day, particularly to the fetchItem endpoint?

2. Are you using our API to retrieve data for items you are not sniping through our platform?

The goal is to work together on a proper use case rather than build out a bunch of monitoring and throttling code. eBay is usually generous with call limits if you apply—given your volume, I’m fairly certain they’d approve the next tier, which I believe allows up to 100K calls.

Please let me know.

Hello, just a friendly reminder to reply to the above. Could you give a fairly comprehensive explanation of how you are using the API? I mean from a programming standpoint.

Could you list each of the commands you are using and number of calls a day?

The objective is to ensure our contract with eBay is upheld but not interrupt your overall needs.

Oh sorry, I didn't see this message. I'm making a couple thousand requests when I look up items. Sometimes zero. Just depends if I'm getting cards that day. I just stop if I run out of credits.

1. To your fetchItem endpoint? Zero. I just use my own scripts. I don't plan on switching.
2. No. I'm only calling your addBid endpoint.

Yeah! You would think! But they told me no. The only thing I use their API for is searching for items. I've heard from a lot of people they've gotta like that recently, so I don't know. I just have to buy less items. Haha

Thank you. So you are using eBay's API to search, and then addBid on our site to add?

We're already doing fetchItem's for you every 4-6 hours or so.

The reason I need to clarify: I refactored the sniper AND the refresher in the Feb. release to accommodate your volume, specifically to use fewer open database connections. So I didn't really have the resources right now to put in a lot of throttling and checking.

I hope to keep this relationship open and honest. Thanks for helping us keep an eye on things---case in point, helping make sure the getSnipeStatus works. I increased the resources for getSnipeStatus, and will repair the call very soon.

Assuming your feedback on all this is positive, do you have time to leave a review at TrustPilot? It would help --- there were some glitches in Feb and a good review would help us a lot.

Yes, exactly.

That's interesting. I'm always happy to test! I have been relying on getUserItems, but now after you explained the status codes to me (-1, -2, etc), I see why I've been marking so many items as "lost" when I actually won them. I'll wait until checkSnipeStatus is fixed. Then I can make more targeted queries.

Sure. I'll go leave a review this weekend.

Awesome!

Sniping is easy. The hard part is determining the win/loss status and accounting for all the various situations. eBay's error messages are usually OK but there is one, "TUV Error" that covers every Trust & Safety situation. Any negative review we incurred was always for that situation.

Got one last week where a guy tried to buy a rifle scope, and we tried to explain and he insisted a scope isn't a weapon. His ticket was entitled "Your service sucks" and he remains unconvinced.

One lady tried to buy diamonds from a different country that wasn't her original profile.

Nice to have a fellow programmer on board... BTW if you ensure that 5 minutes pass before you check status, the odds are 99%+ it's correct.

Hahaha! They get so upset about that stuff. It's beyond our control, but they just get angry. That's too bad.

Sure, I'll test again.
checkSnipeStatus returns empty still:
curl "135841175466"">https://api.bidslammer.com/checkSnipeStatus?key=3502ca8d4c9923eb&item_no=135841175466"

getUserItems looks like it works! There are no -2s anymore :)

Oh I didn't release anything yet. But as you noticed, I did "up" the resources for the post processor by 4X.

I can still see a few slipping through, and need to investigate those next. I"ll try to fix the API call ASAP.

Haha oh! Yeah it’s already better :)

Haha oh! Yeah it’s already better :)

Good to hear :)

Let's think out of the box here -- what API call would serve you best?

One-at-a-time calls for status might not be the solution. Perhaps a "GetAllStatusForEverythingInTheLastWeek()" call could be better.

I'd like to close this ticket due to length... please hit me up at support at bidslammer dot com for discussion of your needs.

I sure appreciate that review!

You wrote: "The checkSnipeStatus as it's written would really work perfectly for me. I know which auctions I'm bidding on and when they're done. So one call to that would be easier than parsing any other endpoint. Thanks!"

Feel free to use email but I decided it might be better to keep it here for context.

This is good info. I'm trying to decide whether or not a call to checkSnipeStatus should report as-is (whatever the value is in the db at that moment of the call), or if I should go through the post-process routine. The latter does the following: (1) Checks for the eBay "PlaceOffer" payload; (2) Updates the value, and (3) if there is no payload, try a brute-force method. I'll send you a sample debug output--- just for grins... no action needed on your part.

I'm thinking I could do a quick fix for a quick call. But also could add a "force=1" parameter that forces it to re-evaluate.

No reply needed--I'll let you know when the new release is tested and released.

I got the debug message. Yeah, I wonder if they even can change their systems at this point. It has to be a very old codebase!

For my purposes, I'm mainly interested in win/loss and the final price. Basically exactly what gets returned with getUserItems. I know when the auction ends, so I would wait until it's finished to check at all. Does that help?

They change it over and over, by deprecating one API and replacing it with another. For example, they deprecated their "Finding API," so we had to rewrite the search feature to use the "Browsing API."

https://www.devgem.io/posts/switching-from-ebay-finding-api-to-browse-api-for-keyword-based-item-search

Make sure to wait 5 minutes before checking the win/loss status. We're using GetMyeBayBuying, which sometimes does not show a win for a few minutes.

I hope to write soon with the update. Thanks again for the help to make the API solid. We consume our own API, and that is the only API call we created just for customers---someone asked for it last year.

This is what we use:

https://developer.ebay.com/devzone/xml/docs/Reference/ebay/GetMyeBayBuying.html

It's tough for your account since we can get 200 items per page --- so we have to pull over many pages to get all of your items.

This is why you're an A-list customer :-D, as we can use your account to test the extreme cases. The goal, of course, being to make the system completely bulletproof.

More soon!

Really! I had no idea. I thought they gave you a data feed or something.

The checkSnipeStatus call is ok now. I suggest waiting 5 minutes after the auction ends.

There is still an issue with "bidResult" being blank. That is intended to contain the human-readable error message.

Until I can address the above issue, here is the error list:

https://onlinephp.io/c/1b60e

Yes! Great! It looks like the data is good. There's no "won" parameter, but that's fine. I can figure it out from the winner username.

One weird thing. This is an auction I sniped that ended 16 hours ago:
306281351766">https://www.ebay.com/itm/306281351766

But it looks like it was relisted automatically, so the checkStatus returns this
"ends_pretty": "in 29 days",

My other tests behaved normally, but I've seen auctions that do this. I don't know how to filter it out. Will you bid on the auction again when ?

You should always check 'success' which == 1 to indicate a definite win. If it is equal to 1, it means it showed up in your GetMyeBayBuying list of wins and is a sure win.

For item 306281351766, notice that success == -47. That is a Fixed Price listing--those can't be sniped unless the amount is exact.

More info:

https://bidslammer.com/help/can-i-snipe-buy-it-now

Ah, I see. That's super helpful.

What I've found is that sometimes an auction will turn into a Fixed Price auction. Like if you fetch the data for that auction, it's the old auction data. But then if the seller wants to, they can cancel the auction and say it's out of stock. Then it turns into that Fixed Price listing with 0 quantity.

Yes. That happens frequently. Especially with collectables. It is a loophole eBay has never addressed: A way to preserve the listing’s watch count, traffic history, or feedback record.

It can also be a tactic to avoid final value fees on auctions if they decide to sell the item outside eBay or relist it later under different terms.

eBay’s system is heavily influenced by feedback mechanics. The threat of negative feedback shapes seller behavior. Many of the loopholes—like your cited scenario and also private offers -- exist because eBay prioritizes transaction volume and buyer satisfaction. Sellers navigate that system to avoid penalties or protect their reputation.