Accept new requests for public API access

[+niraD]

According to the Help Center article Public API program, Groundspeak is "no longer accepting new requests for public API access."

This is killing the public API program through attrition, as existing API license holders leave the market, with no new developers being able to obtain a license to fill the void left by their departure.

Please resume accepting new requests for public API access, so abandoned API-based apps can be replaced by new, supported API-based apps.

[+fizzymagic]

3 hours ago, niraD said:

According to the Help Center article Public API program, Groundspeak is "no longer accepting new requests for public API access."

This is killing the public API program through attrition, as existing API license holders leave the market, with no new developers being able to obtain a license to fill the void left by their departure.

Please resume accepting new requests for public API access, so abandoned API-based apps can be replaced by new, supported API-based apps.

+1 yes!

Or alternatively fix existing features (such as pocket queries) so that the available data matches that obtainable through the API.

[+on4bam]

Not accepting new requests will probably drive people to the "official apps" if their apps stop being developed. So there might be a reason for not allowing new players.

 

[+arisoft]

3 hours ago, on4bam said:

Not accepting new requests will probably drive people to the "official apps" if their apps stop being developed. So there might be a reason for not allowing new players.

 

Or the API is so overloaded that they want to limit the number of users. Whatever the reason is, it gives the wrong signal that the game is over.

[+niraD]

9 hours ago, on4bam said:

Not accepting new requests will probably drive people to the "official apps" if their apps stop being developed.

Or it will drive people to better apps that do not use the API. The most famous is c:geo, which scrapes the geocaching.com site and thereby violates the geocaching.com TOU. But before the API was available, I used one called GeoBeagle that worked very well using PQs and Android's link injection mechanism; no site scraping was required.

[Love]

Although we are not accepting any new partners into the program at this time, we may consider options for opening the Geocaching API to partners in the future. We're still forming our plans on what this will look like so we don't have much information to share at this time. If you are a developer and have an idea you'd like us to consider, we'd be happy to add you to our wait list. Once we have new information regarding the Geocaching API program, we'll reach out to you. 

 

Submit a request via our help center (select #10 Business Partnerships) from the drop-down menu and include your username and information about the application you'd like to use our API on. 

[+NYPaddleCacher]

10 hours ago, Love said:

Although we are not accepting any new partners into the program at this time, we may consider options for opening the Geocaching API to partners in the future. We're still forming our plans on what this will look like so we don't have much information to share at this time. If you are a developer and have an idea you'd like us to consider, we'd be happy to add you to our wait list. Once we have new information regarding the Geocaching API program, we'll reach out to you. 

 

Submit a request via our help center (select #10 Business Partnerships) from the drop-down menu and include your username and information about the application you'd like to use our API on. 

I am a developer (with 30 years of experience) and have done a fair amount of development with GIS based applications, search engines, and semantic web technologies.  I don't have a specific idea for an application, but if I could had access to the API I could develop some prototypes (even it wasn't using "production" data) to determine if an idea would be feasible.  I wouldn't know if I could be a business partner unless I could try out a things with the API to determine if I could create something useful. 

[+frinklabs]

Wouldn't GSAK provide enough of an interface, via its macros, to the API to do some proof of concept stuff?

From the gcApi macro documentation:
 

• GcApi(sMethod,[sPostData],[sCaption]) : string
• This function is for advanced users and gives you access to the Groundspeak live api. 
• sMethod - The api method to call (see Groundspeak live api link above).
• sPostData - Optional and only required if the method uses post data (enter and empty string, if there is no post data and you also want a caption)
• sCaption - Optional - a value here will show in the caption of the api dialog that displays when this function is used.
• The return string of this function is the XML data returned by the api call, or the error message if the api call ended in error.

[+niraD]

4 hours ago, frinklabs said:

Wouldn't GSAK provide enough of an interface, via its macros, to the API to do some proof of concept stuff?

Only if one uses MS Windows.

[+NYPaddleCacher]

18 hours ago, frinklabs said:

Wouldn't GSAK provide enough of an interface, via its macros, to the API to do some proof of concept stuff?

From the gcApi macro documentation:
 

• GcApi(sMethod,[sPostData],[sCaption]) : string
• This function is for advanced users and gives you access to the Groundspeak live api. I
• sMethod - The api method to call (see Groundspeak live api link above)
• sPostData - Optional and only required if the method uses post data (enter and empty string, if there is no post data and you also want a caption)
• sCaption - Optional - a value here will show in the caption of the api dialog that displays when this function is used.
• The return string of this function is the XML data returned by the api call, or the error message if the api call ended in error.

I've never really looked at the gcApi macro.  As I see it, there are two limitations with that approach.

GSAK isn't free.  I've been using the pre-8.* version almost since I started geocaching but haven;t used it often enough to justify paying for the upgrade.

It requires write code using the GSAK macro scripting language.   I'm primarily a Java and Ruby programmer.  I can write code in other languages but am most efficient when writing in Java or Ruby. 

As niraD mentions, GSAK is a windows application.  Although I have access to a windows machine my primary development machine is a Mac.  I've installed GSAK using Wine, and it sort of works but is a big pain.  There are other options (virtual box, dual boot setup) but they're more intrusive than using Wine. 

That said, this gcApi macro might be enough to get me to upgrade GSAK but I would prefer  direct accesss to the API even if it were in a "sandbox" environment that wasn't using production data. 

[+on4bam]

23 minutes ago, NYPaddleCacher said:

GSAK isn't free.  I've been using the pre-8.* version almost since I started geocaching but haven;t used it often enough to justify paying for the upgrade.

Having paid twice since 2006, that's $60 or $5/year, way less than having a drink during a caching day (or fuel).

 

[+HHL]

38 minutes ago, NYPaddleCacher said:

[...] It requires write code using the GSAK macro scripting language.  [...]

Right. But there is actually no need for coding a macro. GSAK's core api fuctions via the app's menu (as seen in my screenshot in thus thread) is sufficient for using the Api interface.

Hans

[+thebruce0]

Yup, gsak is cheap. And worth it. And deservedly worth it.

You could alternative write a wrapper.  GSAK can get all the data, and since it's placed in a SQLite database, you can create your own 'wrapper' to mimick the API at least in conceptual interaction.  With minimal adjustments if you're granted access, you'd already have the proof of concept utilizing a non-live database with functionality you can almost guarantee is available with the API (especially if the documentation is available to you).  That's one option.

Better would be for GS to implement a test/trial API account for developers to use, that's heavily throttled if that's a concern. That can allow developers to create and test concepts and GS can easily keep them under tight access and control.

[+NYPaddleCacher]

23 hours ago, thebruce0 said:

Yup, gsak is cheap. And worth it. And deservedly worth it.

You could alternative write a wrapper.  GSAK can get all the data, and since it's placed in a SQLite database, you can create your own 'wrapper' to mimick the API at least in conceptual interaction.  With minimal adjustments if you're granted access, you'd already have the proof of concept utilizing a non-live database with functionality you can almost guarantee is available with the API (especially if the documentation is available to you).  That's one option.

Better would be for GS to implement a test/trial API account for developers to use, that's heavily throttled if that's a concern. That can allow developers to create and test concepts and GS can easily keep them under tight access and control.

I've worked on other platforms that use SQLite so that wouldn't be an issue for me.  I could create a data access layer for the SQLite database but that would still mean a dependency on GSAK, which means having a PC running windows.  To me, an API should be client agnostic.  Speaking of wrappers,  if I were able to use the API I'd probably create a java library or ruby gem that I could include in java or ruby applications.  

My preference would also be for a test/trial API account for developers to use.