I’ve been using the n8n API to create credentials but the schema changes every other day. I got a suggestion to first fetch the schema, but I’m not sure how that would work. How would I know what to put when the type is an enum or custom? This is honestly very frustrating. There shouldn’t be this many breaking changes this often.
What is the error message (if any)?
Please share your workflow
(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)
Hi @valonn as the API gets new features they seems to be changing a lot of stuff, so what i personally do is that i first dynamically fetch the schema before creating those credentials, so that your script always uses the current available/working structure.
But how do I handle the schema dynamically? How do I know what types to provide, whether it’s an enum or something else entirely? This is not a good solution. I want to create these through a UI interface, not just programmatically. On top of that, I can’t fetch credentials, it always returns forbidden.
@valonn if you are not the admin/owner the GET /credentials would not work.
For enums, that schema endpoint returns allOf conditional block, so i would say that please try to only pass the fields explicitly listed under properties in the schema.
Creating credentials using UI is straightaway and easy you can go to credentials in the left sidebar > add credential, select your type, and fill in the fields directly, n8n renders the correct form with all options automatically and will reduce the complexity of doing so using programming.
@Anshul_Namdev Thanks, but I’m not talking about the n8n UI interface. I’ve built my own UI for it in my project. I’d like to create credentials through my own form. It should automatically set the options to default just like it does in the n8n UI. There’s no need to overcomplicate the API with extra fields that aren’t even visible in the UI or are just set to default. In the UI I only set the name and the key. That’s it. I’d expect the same behaviour from the API, those should be the only required fields. This is an inconsistency on your side.
hope you are doind well @valonn
I would fetch the latest credential schema at runtime and generate the form from the fields marked as visible/required, while pre-filling defaults for optional fields exactly like the n8n UI does, because credential definitions can evolve between versions and the more stable approach is to treat the schema as the source of truth instead of hardcoding field assumptions in your custom frontend.
api schema instability is annoying, agreed. if youre building a tool that creates credentials dynamically, the best approach i’ve seen is to fetch the schema once, cache it locally for maybe 24 hours, and just reuse that cached version. yeah it might get stale but beats building a whole schema parser. alternatively just hardcode the fields youre actually using — the API only changes the optional stuff anyway, the required fields are usually stable. we had this exact problem and ended up just ignoring the allOf blocks and only building the ui for the explicit properties fields.
Hi valonn, that’s very annoying that you’re getting that issue. I had that issue when I was building automations in my early days as a freelance dev. This is exactly the problem we built DataCrawl’s validation layer for. Instead of chasing schema changes manually, you point your workflow through our HTTP validator, and it catches the mismatch before it reaches your node and tells you exactly what changed and why. It’s able to catch small schema shifts and correct them. Happy to run your traffic through it for 48 hours and send you a report of what we catch. No setup cost. DM me if you want to try it.