I maintain my club’s website and it’d be great to be able to do things like displaying the best rounds for each course, a record of when people have got aces, calculating people’s handicaps for the course, and tracking the bag tag standings, all of which is just managed manually at the moment.
I’ve seen similar requests on Reddit too, for example:
I’d also like to be able to pull our weekly tournament scores via the api into a place where we have handicaps to make our end of the round calculations and payouts faster.
Hey Peter and Ryan,
Really appreciate you adding this here! Suggestions like this are taken to heart and we’ll be sure to keep this mind for future updates. I’m sure you’ve used this feature before, but you are able to Export to CSV in your League Tools and can import these into a database if you already have one created. I know not exactly what you may be trying to achieve, but a great option for the time being. Keep the ideas coming!
I and a few of my compatriots are chomping at the bit for a UDisc public API. I run a number of python modules for random draw doubles, triples, monthly bag tag and annual unsanctioned tournaments and manually exporting to csv, and then using an in excel formula to match registrant names with UDisc results is cumbersome.
Some of my colleagues are also looking at a pet project that would benefit from UDisc integration.
I’m not sure if what I would like to see fits in here with this situation but I am also currently running a league that plays mostly out of the course I am an ambassador for. It’s a handicap league where handicaps are created after a player completes two rounds in the league. I’m currently taking the scores out of UDisc and entering them into another site that we run the league out of because it gives leagues the option of using handicaps. I’d love it if we could just do it all in UDisc , any chance that might be something added to the app in the ( NEAR) future?
I would love to run a handicapped league but honestly I don’t have the time to create all the necessary spreadsheets to make the calculations. I would totally pay extra if UDisc could handle that side for me.
A public API is something we would also love, but isn’t currently on the roadmap for the near-term. However, being able to provide some helpful information for player handicaps is on the roadmap.
Keep in mind that offering a public API is a huge + low cost marketing opportunity. Just put in the terms of service that any time statistics or content derived from the API is published, that a credit be included and a link back to UDisc.
This would be the cheapest ad spend you guys will have ever made, and continue to keep UDisc in the public consciousness. With the recent loss of the live scoring of the pro tour, it might be the best time in fact to go on the offensive with expanded public promotion, and this is low hanging fruit.
In what universe is developing a public API low cost? This would require development, documentation, support, etc. Would be a massive undertaking for uDisc and likely raise costs again.
I’ve been a software architect for more than 20 years, and I’ve written multiple REST API’s in that time and they are neither difficult, nor costly (at least when done property they don’t need to be). They obviously already have something generating their CSV files, so the core data tools are already there, they just need to repackage the delivery into a REST API and that is a long established standard. Seriously, you could spin out the first endpoints in a day.
I agree with Kevin Farley here … creating a web api wouldn’t be much work … at least let me export the results using a URL … right now I have to manually go to each of my 15 league’s pages and click on the button … but if there was a way I could construct a URL and have it download it automatically would be amazing.
I could then write a program to hit the URL, download the file, then automatically import the results into my system (a Google Spreadsheet) to do the stats on all my leagues that I do.
While it’s true there is not any major technical challenge with creating a REST endpoint, creating a public API requires a lot more thought and due diligence to do well.
We have to consider many factors like security, privacy, and abuse prevention. And one of the biggest factors is maintaining the API and managing changes: if we publish an API, folks will expect it to not break, so we would have to version APIs in backwards compatible ways.
At this point, it’s helpful to understand what use-cases folks have for an API, but building a public API is not on our near-term roadmap.
@brianhannan I do think a URL-based download for event exports makes sense though and is something we can roll in to our upcoming league updates.
“security, privacy, and abuse prevention”
Please accept this high-five from a Security Guy.
Can someone put into english all this geek stuff ? API public or not security privacy and abuse prevention of what ? Look all I know is i enter score in the app and then after its all done I gotta go to another app and enter scores cause UDisc can’t add a handicap league function ? It sure seems like it should be possible. I mean Disc Golf Scene did it .
Honestly, the URL-based download solves most of what I’m looking to accomplish though an API would allow me to have more reliable code.
Let me us know when you get the URL-based download feature in place! I will start using it immediately.
Thanks so much!!
Geek here … any time you have an API someone can abuse it and shut it down with denial of service (DOS) attacks. You want to make sure any data you’re sharing publicly doesn’t violate someone else’s private data … you’d be surprised what it takes to prevent attacks and privacy of data.
I also have to input scores into another app for what I’m doing but I wouldn’t expect UDisc to provide the feature I am providing. Having an API would make it easier and more reliable to create an interface from UDisc to any other code you or someone else might want to program. But having a URL-based download of the export would allow anyone to do just about the same … the difference is you’d have to be able to have your code digest an Excel file as opposed to JSON or XML. I’m going to download the Excel file and generate XML from it and then do my programming based on the XML.