Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification about the SDK #25

Closed
Munsio opened this issue Dec 12, 2024 · 1 comment
Closed

Clarification about the SDK #25

Munsio opened this issue Dec 12, 2024 · 1 comment

Comments

@Munsio
Copy link

Munsio commented Dec 12, 2024

Hi,

Sorry if this sound a little dumb but I couldn't find any indication if this package is getting any treatment regarding other API use cases like creating a license/user etc.

Or will there be an official API Client for such things in the future? And if not do you accept PRs on this SDK expanding the feature set for User actions like this?

Edit: The slice response was a mistake on my end.

Regardless of the question above I also found a "bug" within the API when retrieving a User.

According to the Documentation https://keygen.sh/docs/api/users/#users-retrieve you can either use the ID or the E-Mail address for fetching. Also E-Mail addresses are unique within an account.

Unfortunately when trying to use the E-Mail address the API is returning a slice with 1 User, so you can't use both within the same go method without checking the input parameter.

@Munsio Munsio changed the title Clarification about the SDK and missing explanation in the Docs Clarification about the SDK Dec 12, 2024
@ezekg
Copy link
Member

ezekg commented Dec 13, 2024

Not dumb at all. I'd love to eventually support more API operations. The SDK was initially an exploration into what a 'reference' client-side API would look like that others could use to implement other clients. But we already have webhook verification in the SDK, which is a server-side function, so I'm totally open to PRs introducing additional actions such as license and user creation.

The full API's surface area is really big, so I probably won't get to implementing everything in the API anytime soon, unless we move to a generated SDK based on e.g. an OpenAPI spec. But open to PRs to introduce certain things.

The way I've extended the SDK myself is by defining a keygenext package. For example, the CLI extends the SDK to add release creation and publishing, artifact uploading, among some other things.

@ezekg ezekg closed this as completed Dec 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants