Introducing LeanIX Developer Evangelist: Let's Chat APIs, Docs & More!

Hi @Kostas-LeanIX, my 2 cents of feedback that I collected during my ~8 years of developing LeanIX scripts, integrations, automations, KPIs and reports:

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 @Thomas Schreiner , thank you so much for sharing your experience and insights! Feedback like yours is what helps us continuously improve the user and developer experience!

Hi @Kostas-LeanIX ,
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 @Carsten , thanks so much for taking the time to share your feedback! Your insights are valuable and touch upon some exciting initiatives we're already working on.

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.

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 @geoffrey.lowney !
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 @Kostas-LeanIX ,

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

@Kostas-LeanIX I just noticed two missing topics on my list:

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.