API shared between OctoPrinter devices


I have OctoPrint running on 2 Raspberry PI 3's as each of those are connected to the respective printers. I am Cura 3.3.1 currently and was using Cura 3.2.1 before. I notice that Cura will not allow me to save a different API for the IP address OctoPrint. Can I tell both of my OctoPrint units to use the same API? If this is possible then managing my printers would be so much simpler and not having to change the API each time I change printers.

If this is possible, then how?



I never print from Cura. I always just slice in Cura and then upload the file using the OctoPrint interface, do a little prep-work and then start the job in OctoPrint. So I've never configured Cura to try to directly talk to the printer/OctoPrint nor needed to.


I can't test it but try editing ~/.octoprint/config.yaml on one system and replace the api key (near the top) with the one from the other system. Be careful not to mess with the spacing as I believe that is important.


I can confirm that messing up the spacing will make a yaml file unhappy. Clever idea, btw. Looks like you're making both OctoPrint installations use the same API key. :+1:


That is how I am.doimg it. Is slicing in cura and the uploading to the printer via IP octoprint. That is why if I could make the API the same in both octoprint, then it will talk to them based on IP address.

Many Rebels paid dearly with their lives for this message to be sent from Imperial held Space.


Did you try my suggestion?


I have looked using putty into the raspberry pi3 board and i can not find the config.yaml anywhere....also I have pulled the sd card out and looked at the boot and I do not see the config.yaml. So where does one look for such a thing? Tools you suggest for this?


Is there a way that I can get to the file without having to use the clunky linux interface? I normally do any XML or other editing using Notepad++. I know I can not mess up to bad and keep the spacing using this as I am custom to it. So is there a way that I can get the config.yaml file?


I'm afraid you're reasonably stuck in the clunky Linux command line world.

nano ~/.octoprint/config.yaml

Do a Ctrl-W and search for "api", then type in the one from the other instance. Then do a Ctrl-o and follow the prompts to save it, then a Ctrl-x to exit. Restart OctoPrint and this instance should now have the same API key as the other one.


The config.yaml file contains sensitive information and is purposely not placed where it can easily be found.

I am also a long time Windows user and a big fan of Notepad++. When you add a Unix/Linux/BSD based system you need to get comfortable with the minimum of tools that are regularly used in those environments. These are SSH (PuTTY on Windows works very well) and a text file editor on the Linux side. VI is the defacto standard but that involves a significant learning curve. Nano is a lightweight editor which by default, keeps its "help" on the screen at the bottom.

A slightly more advanced tool which I use is WinSCP. This is a file manager that can speak many file-oriented protocols. You can use the username "pi" and your SSH password to bring up a window into the home directory of the "pi" user. The only tricky part is that ~/.octoprint is a hidden file and won't show until you type CTRL+ALT+H or change the setting in the panels section of Options, Preferences.

After installing WinSCP and enabling display of hidden files, you can "download" config.yaml, edit it with Notepad++, and "upload" it back to your OctoPrint system.


...being careful to leave the UNIX-style of line endings rather than the CR+LF Windows-style.


That's one nice thing about Notepad++, it recognizes and preserves line endings (but has the ability to switch).


Fun fact:

That I should live to see this day! :sob:


Man that works like the best and butter on a hot pan. Thank you for info on the WinSCP...nice tool for remotely getting to the config file. Yeah Notepad++ is one of the best. I use it daily for XML file editing. So I did a replace of the API and downloaded over writing the file currently in Octo. It has connected and now my Cura can talk to either machine via the IP address using the same API code. Slick Baby Slick.

Thank you -morgan and all others that gave me the info.

Linux is basically a lowered version of the old Dr. Dos right there at the cusp of DOS. Unfortunately I have to learn Linux now since my company believes that Linux is a better thin client operating system than that of windows. I believe more since they dont have to pay royalities to MS.

Thank you again.


For 34 years, writing solutions for Microsoft-based computers was my bread and butter. There must be a compelling reason why I now wouldn't be caught dead coding to .Net or to Windows 10. My own son was last year in charge of VisualStudio.com, btw, and I gave him and all my students the same advice I'm giving you: it's time to switch operating systems to anything-but-Windows.

Get yourself a live boot Ubuntu USB and give that a try.


I have a copy of the Mint....I havent build a VM for it to run yet....but will when I have a free moment. I will look into the Ubuntu also.

So since I have changed the API in the other Octo, Cura is acting strangely. We are running a print currently on the other machine, having issues with missing layers now on the 5th retry we think we have figured it. So after this print works or fails, I want to reboot the machine and see if that is cause of Cura.....if not then I will check the logs and see what is giving cura heart burn.


If you're using Cura (on your workstation) to slice and then also send/print the job as well, then I'm pretty sure Cura's printer profile/settings need the correct API key, as now changed.