Hello everyone! My name is Kostas Petrakis, and I'm excited to introduce myself as a LeanIX Developer Evangelist, bringing over 25 years of experience in the trenches of engineering (particularly with Python and Go) to the party!
My mission with my fantastic colleagues is to elevate the developer experience by enhancing our documentation and ensuring your daily workflows with LeanIX APIs, and tools are as smooth as butter.
However, I can't do it without you! Your voices are invaluable in shaping the future of our developer resources.
So, don't hold back! Share your thoughts, challenges, and improvement ideas related to LeanIX APIs, documentation, and tooling. ️
We'll start small, taking thoughtful steps to pack a punch and deliver real, tangible value.
I'm also new to the team, so while I may not have all the answers, I'm a passionate learner and problem-solver ready to dive deep and find them!
I look forward to connecting and collaborating with all of you!
Introducing LeanIX Developer Evangelist: Let's Chat APIs, Docs & More!
+2
Hi
1.) Webhook event types
In the current list of webhook event types, some event types are missing, see here. This makes it difficult to develop certain automation scenarios, and the generic FACT_SHEET_UPDATED event is not an alternative - it’s HUGE and does not cover all cases.
My wish list sorted by priority:
- LIFECYCLE_PHASE_CHANGED
- LIFECYCLE_PHASE_CHANGING_SOON
- COMMENT_CREATED
- COMMENT_UPDATED
- COMMENT_REPLY_ADDED
- COMMENT_DELETED
- TODO_CREATED
- TODO_UPDATED
- TODO_DELETED
Lower prio, but still on my wish list:
- FACT_SHEET_VIEWED
- USER_ACCESS_WORKSPACE (MTM)
2.) MTM GraphQL endpoint
Up until today, we still need to use the MTM GraphQL endpoint for some scenarios, even though it has never been officially released for customers. It would be awesome to either have it released officially, or provide an official endpoint with all capabilities of the MTM GraphQL endpoint (fast, low overhead + providing all user/permission data including roles + last_login date per workspace)
3.) Alternative API endpoint for pathfinder/v1/models/metaModel
This endpoint has been deprecated without providing the functionality in an alternative endpoint, see here. After deprecating the endpoint, we will still need an API endpoint to understand which fields of the data model are used/unused in the views.
I might add some more feedback later, also regarding more generic, broader and more strategic approaches on how to elevate developer experience, but those are the specific issues I am most concerned about.
Except for this, I am really happy with the stability of LeanIX and its APIs and integrations, my LeanIX Automation Platform as well as the Python Module are running with very little maintenance required, and is making all of our customers very happy. Thanks for doing such a great job, LeanIX!
Hi
Hi
I have some additional topics to the useful proposals of Thomas:
I’d like to have some queries/mutations added to graphql: Todos, Transformations
For webhooks it’d be great, if you’d be able to provide old and new values to the FACTSHEET_UPDTED (similar to FACTSHEET_FIELD_UPDATED) event making it easier to filter outgoing events.
For the Azure Function Examples, I recommend to adjust/provide code to the v2 model to be up to date.
What about a cookbook for developing code with step by step manual how to develop something like the webhook e.g. for TIME using AzureFunction with VSCode? - gGoup it by chapters e.g. how to setup VS Code (reusable) via howto filter webhooks messeages via js, source code, testing in VS up to deployment. E.g. I use for TIME the FACTSHEET_FIELD_UPDATED to pre-filer messages going out to Azure.
Finally, what about exchanging code via community for free (without warranty) - perhaps reviewed by you and your colleagues?
Best regards,
Carsten
Hi
Specifically, we're focusing on:
- Gradually updating and expanding our example scripts: We want to ensure they're clear, current, and helpful for various use cases.
- Enhancing cross-referencing with ongoing documentation updates: This will create a seamless user experience and keep information synchronized.
- Enrich our API and Webhook documentation providing better guidance for our consumers.
Your suggestion of incorporating code reviews is definitely intriguing! While it's not currently on our immediate roadmap, we'll keep it in mind and explore its potential value for the future.
Meanwhile, I'm actively collecting all your insights about APIs and Webhooks. Analyzing this feedback will help us refine our documentation and APIs to better align with your and other users' needs.
Thank you again! Your contribution is essential for making our resources even better.
+1
The above are great suggestions. I will add a few of my own:
- It would help to have more documentation on things like the internal names of standard fields and relations. For example, I can’t find any documentation on the standard facetKey values. The GraphQL docs only say it is a string. It took me too much effort to figure out that to find all fact sheets where a particular user is subscribed I needed to use a facetKey string of “Subscriptions.”
- As a developer of a number of custom reports, the docs and examples could use some love. The current info assumes a lot of existing knowledge on the user to get started. While I consider myself a great developer/engineer, I had not used some of the specific technologies (Vue, Bite, tailwind, etc), so it took me quite a while to get my first report working. In addition, many of the examples provided used older patterns (like using the Vue Options API instead of the current/modern Composition API).
- Another ask on the custom reports front would be for LeanIX to provide some standard Vue components that would make it easier for customers to more easily create reports that visually look more like the standard LeanIX report.
Thanks
Hello
I appreciate your valuable and insightful feedback! As a relatively new member of LeanIX, some of the concerns raised resonated closely with my own initial observations.
We're actively collaborating with the team responsible for both the library and developer documentation to address these issues. We're committed to making improvements that benefit everyone using custom report guides.
While I can't provide a specific timeline right now, please be assured that your feedback is valued and driving positive change. We'll be transparent and share updates on our progress as we have them.
In the meantime, feel free to ask any questions or share additional thoughts you might have. Let's keep this conversation going!
Hello
regarding Webhooks: I proose to add an event Todo completed, claimed or due date reached. I should include all Task data and the related factsheet id.
Best regards
Carsten
+2
4.) API access to the list of instances
I am using the full instance/region list for my auto-detection logic within LeanIX Automation Platform, so that an API token is enough to configure the whole connection to LeanIX.
So far, I have to rely on either somebody in Ops giving me a heads-up about new instances/regions, plus my own scanner to detect new instances, which is very unreliable. I think the mtm/instances/ endpoints might work fine, but they are internal-only.
5.) API that provides the Webhook IPs or IP ranges for every region (maybe part of point 4.)
In the setup logic of LeanIX Automation Platform, I automatically create firewall rules to only allow Webhook requests from official LeanIX Webhook IPs.
So far, I have to request the IP lists manually from Ops, which is a major drawback, especially since the IP ranges change sometimes and I get support calls whenever something breaks.
Thanks
Reply
Login to the community
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.