236140162039&bid=22.22&groupName=Dobes&delay=3">https://api.bidslammer.com/addBid?key={API_KEY}&item_no=236140162039&bid=22.22&groupName=Dobes&delay=3

{
"id": 10363651,
"item_no": 236140162039,
"bid": "22.22",
"delay": 3,
"group_id": 0,
"groupName": "",
"status": "OK",
"alert": "success",
"short_message": "Bid added for 22.22.",
"message": "You successfully added a snipe for 22.22 on eBay item #236140162039.",
"new_snipe": true,
"ack": "Success",
"errorCode": "",
"bothMessages": " ",
"shortMessage": "",
"longMessage": "",
"shippingCost": 0,
"shippingServiceCost": 0,
"freeShipping": "0",
"shippingTimeMax": 0,
"shippingTimeMin": 0,
"shippingType": "None",
"shippingPriority": "0",
"shippingService": "",
"message_color": "green"
}


The groupName value is "" instead of "Dobes"

Hello Dennis,

Thank you for your question about the AddBid API call. I looked at the code and found this is a documentation bug. The parameter name is actually "newGroupName", not "groupName."

I tried your call using newGroupName and it created the group and returned:

{
"alert": "success",
"bid": "22.22",
"group_id": 40245,
"groupName": "",
"item_no": 236140162039,
"message": "Snipe updated to 22.22.",
"new_snipe": true,
"status": "OK",
"message_color": "green"
}

In this response you can see the new group_id. But it returns a blank groupName, probably for the same reason above. I'll make sure that is addressed in the next release.

So in summary, use newGroupName and check for group_id greater than zero.

Let me know if that works for you. Thanks!

Yes, that seems to work, thank you. The documentation should say so.

I thought the idea of bid groups was to bid on items in the group until you win one of them, then stop.
But today, I won multiple auctions in the same bid group. Twice.

Dobes (OK, they were very close together in time)
236140162039
236140497893

Rousek (hours apart)
357034225192
135940116534

Ah no, the Dobes ones were six hours apart.

Yes, I updated the documentation for that already, plus what I say below:

Once a new group is created, you must refer to it using its group_id from that point forward. If you call newGroupName again with the same name, it will do just that--create another new group. This is to ensure that the system doesn't use a similar name from an old group you might have created weeks ago (or longer). This is why you ended up with multiple "Rousek" entries.

That decision was made for two reasons: One, it gets confusing when someone gets a "group already exists" message in the UI, when it was used a long time ago and doesn't show in the pull-down. Two, we don't want to delete any groups because then we wouldn't be able to trace any issues that arise.

For "Dobes" items (236140162039 or 236140497893), I can't find those in the database, even though there are log entries for the bids. Did you delete or archive either of those? If so, it would explain multiple wins since it wouldn't be able to find the snipe.

Let me know on the latter. Suggestions are welcome if there's a better way to handle.

Yes, I delete bid groups when the auctions end, by removing the items.

This is all a bit confusing. So the first addBid is done with newGroupName, then you have to remember what the group_id is (or is there a way to find out later?) and consecutive addBids have to be done with that group_id.

I have seen that multiple addBids with the same newGroupName give the same group_id back, which seems to contradict the statement that it creates another new group. It also shows up as one bid group on https://bidslammer.com/user/#!#bidGroups but doesn't behave like one.

Maybe newGroupName=X for the first addBid followed by groupName=X for the next one(s) would be easier to handle.

Yes I understand - your script is static and persisting the group id is a pain.

Short answer: I can make a getGroups() API call that returns the id/name pairs. Would this be helpful?

More info:

The confusion is based on the 10-day lifetime of a group id. Groups are never deleted. But each time addBid() uses a groupName, it updates "updated_at" to NOW() to indicate that the group is in use.

So within 10 days, you'll get the same group_id. After 10 days, you get a new group_id.

Why is this done this way? (a) Customers don't like the suffixes e.g. Widget-1343. (b) Customers want to use the same group name. (c) Every snipe has to be easily traceable.

So, the current implementation covers all the bases and has worked perfectly for a long time.

A getGroups() would be helpful, but it's not urgent. Thanks!

I did what you said. addBid with newGroupName=Ivan on item #226815249557 which returned group_id 40262. Then I added another snipe on item #157108215935 with that group_id=40262, an hour apart.

Guess what happened.

I won both instead of just one of them, and the BidGroups page https://bidslammer.com/user/#!#bidGroups says "Wins Achieved: 0"

It's not a big deal, low prices. But it doesn't give me that warm fuzzy feeling about using bid groups.

2025-06-22 19:23:00 157108215935 - Checking if a snipe in this group has already been won.


{doubt}
That check should have returned "yes"

Thank you for the info. Your comment is fair. Two questions: What method did you use to check a win? (Always check success == 1, since that means eBay confirmed it.) Also, how long after the auction did you use the checkSnipeStatus? It is showing as a win as I write.

More info:

1. The first thing I noticed is that the snipe ending in 935 ended at prime time on Sunday around 7pm.

2. The win status reads correctly now, and I verified the issue is the next point.

3. In the last month, we're seeing eBay take as much as 15 minutes to update their MyeBayBuying call during prime time. It returns a list of items you won. It's the only sure way of determining a win. So I changed the group threshold to 15 minutes temporarily.

4. The permanent solution is to put more resources into post-processing. Then I can lower the Bid Group back down to 5.

5. Sniping always works since it only is done once. Post-processing is harder because we have to loop and keep checking until eBay says its a win. This is to account for rare cases where you are outsniped.

Thanks for bearing with. We should be ok with the 15 minutes for now. I'll research some more and get back to you with an ETA on both of these updates we promised in this thread.

I am out of town this week, plus need probably another week to put in these two updates I promised in this thread.

Please let me know on those 2 questions.

As both of these auctions ended in the middle of the night Swiss time, I did not check until hours after, by looking at the eBay item pages. I have never used checkSnipeStatus() before.

The bid group page still says "Wins Achieved: 0" though.

Yes, "Wins Achieved" is calculated in post processing, which in this case had not yet updated the success status.

fetchItem() won't show win status. You have to use checkSnipeStatus(), after 15 minutes from closing, (usually a minute or two) it will be correct.

No, I meant that I went to 226815249557">https://www.ebay.com/itm/226815249557 to check the status.
Thanks for looking into this.

You are welcome. It will work the way you want if you remember that group_id will stay the same as long as you add snipes within 10 days of the addition into that group.

Thanks for helping us improve the documentation on that issue.

The getGroups() is on the schedule and we'll get to it as soon as we can. The API doc page will be updated once it is available.