Corfman Clan

All this is pretty standard OAuth2. Read up on it and the flow will make more sense. Also, you mention the use of "non-typical http methods" but that really isn't the case with REST web services. Read up on REST web service implementations and you will find that this is all pretty standard stuff.

Have you been using the swagger for trying things out? I highly recommend it. https://api.Groundspeak.com/api-docs/index https://staging.api.Groundspeak.com/api-docs/index

You're messing up the request URI. You have: $APILink="https://staging.api.Groundspeak.com/v1/userwaypoints/?referenceCode=GC12345"; But you should have: $APILink="https://staging.api.Groundspeak.com/v1/userwaypoints/?fields:referenceCode"; Note that you are specifying what is returned to you. The reference code here would be the reference code of the newly added waypoint. That is, you are not specifying what geocache you want to add the waypoint to, that's specified in the waypoint structure you pass in.

Well it is planned to occur every 10 years.

Lost and Found events did not need to have a Lackey in attendance. They just had to be applied for ahead of time, accepted, and held within some limited time period. I don't remember what else was required of them but I believe the event name had to start with, "10 Years!" or something like that.

Geocaching HQ has been sending out regular correspondence about this to their API partners for over a year. It shouldn't be a surprise. I guess you are no longer on their list or perhaps your email doesn't match what they have. If you want to keep CacheMaid going, I suggest contacting them directly.

What does that even mean.

That was the case even before Geocaching HQ nuked about 15,000 caches in Nevada this spring.

Actually, it's barely over 3000.

Yes, the old API is now deprecated and no longer accessible. The old OAuth1 tokens should still work, however that wont last as Geocaching HQ is moving to OAuth2. As far as I know, they haven't announced when OAuth1 access will be retired.

I'm happy to have received one . After applying I realized I hadn't hid a physical cache in the last four years so wasn't expecting this. After I received the notice today I checked and see I did host a couple of events so I assume that's what saved me.

So now everyone knows SwineFlew logged a will attend. Nice

So everybody that hides a cache is going to have to somehow come up with this passcode and leave it in the cache? Sounds doable in some other universe.

I've found a couple of caches that basically needed to be done as an overnight backpacking trip into Grand Canyon. One was a multicache and the other a Wherigo. Both where off the north rim of the canyon, which is much less accessible than the south rim. The finals for each are outside the park. Both used landmarks/signs already within the park. These might give you an idea to work with. Canyoneering-Nankoweap GC Indian Hollow to Deer Creek This is another multicache that requires a hike through designated wilderness to the park boundary and back out. Nankoweap Views

It's fine for me. It's probably the browser you're using.

Yep, that was pretty hilarious to read.

So I received an email from, "The Logbook" today with the above subject line. The recommended cache, GC5P2FA was archived close to two weeks ago. The best recommendation ever!

That's a leap of faith. It may have been bad timing with a hardware issue. We really don't know if the issue was due to load. Maybe it was, maybe not. It's unfortunate, but I'm not going to speculate on the cause.

It may or may not be relevant but was offered as a possible explanation for what you are seeing. It would be relevant if, for example, skip is initially set to 9000, and progressed from there. In this example, 1000 caches would be retrieved and then things would end when skip reaches 10,000. Personally, I think GSAK has a bug or a macro has a bug, but what do I know?

Yes, and that is what is being discussed above.

I also see 26% and I'm not using Firefox.

I don't think that is the case. The limitation is that you can't have 10,000 < (skip + take). So if your geocache search has over 10,000 caches in the result set, you're only able to retrieve those that fall in the first 10,000 of the result set. It's not an issue with the number of caches you try to retrieve, but with where the caches you try to retrieve fall in the result set. That is, you can retrieve caches 1 to 10,000 but you cannot retrieve caches 10,001 and greater, even if you first try to retrieve caches 10,001 to say 10,050 (skip = 10,000, take = 50).

Since it's a note, and not a found it, how courteous can it be? Seriously, I look to see if the cache is found, not whether someone wrote a note or not. Seems you should just write a found it and later edit it or delete it and then write a new found it.

Then why not just write a found it, then later write another found it and delete the first?

It defines the UTC offset for a particular location at a particular instance in time. The UTC offset for a location may vary throughout the year. The time zone takes all that into account. UTC offset by itself is really only good for a specific instance in time.