Welcome to the RingCentral Community

Thanks for the clarification, Benjamin. I'll get back to work :-)

Ah, that helps make a little more sense of things.

There are a few ways to tackle that situation:

1. Do as you've stated, and have that customer use their RingCentral Account to Authenticate to the Developer Portal. Then have them create a new Application (provide them with all the necessary settings, permissions, etc... your code will require), once they've created the application ask them to provide you with the API keys and credentials.

2. You can author your application code to operate on Heroku and implement one-button deployments. Then in your app.json you set the parameters which the customer must supply (API Keys, Username, Password) and will be made available to your application via Environment Variables. You can do this with many of the PaaS providers, and DockerHub too (IIRC).

3. Provide the source code to your customer and have them implement and deploy and provide them with placeholders where they must enter their API Key and Credentials.

4. Build the application to support a POST configuration route which expects a known X-Auth-Signature Header value, and provide the customer with the stub code to create the app and enter the required data themselves in the POST request using the one-time use X-Auth-Signature Header value you provide them.

5. Same as #4, except you provide an easy-to-use UI for the customer to enter the required configuration data which is password protected.

6. (Not exactly the same use case, but an alternative) Implement 3-Legged OAuth on a Public Server/Web application, and then provide a UI for them to configure the application.

I think i just screwed up by using my own developer account for testing. I've basically got a daemon running and it was fine on sandbox while I was testing. Graduated to production under that scenario because I suppose I didn't think it through. I went to set up the daemon on the end customer's' server and then ran into the authorization issue since my developer account is not associated with the customer's organization. The quick fix I attempted was to create a new app with a public type. Didn't look too closely at the allowed Authorization Flows until trying to authenticate afterward as I was trying to get it running to start working on graduation requirements. I'm guessing I should have created the app using the customers' credentials instead as it does not appear that I can change the organization under my credentials as it stands now. I'm looking at an extensive rewrite if I need to implement oAuth for this one customer, so I'm guessing I should just use their admin account to create the app? I did have to backtrack a little bit to figure out what had gone wrong since it allowed me to create the app with no authorization flows.

You're correct Rusty, currently Authorization Flow is not supported when application type is Server-only (No UI).

Server-only (No UI) applications are services/workers and as no client-side code is exposed, it is expected that developers can store credentials in a secure location of their choosing in the server-side (I typically use environment variables) for the running instance of the application.

Is there a use case where a Server-only (No UI) application/integration would need to be anything other than private (only able to operate with the RingCentral Account which created the application)?

The question is how you are going to obtain end user's credentials in this case. Public apps are allowed to work on behalf of different RingCentral accounts' users. So you will need to authenticate users somehow. If your app is headless, the usual scenario for private apps is to place credentials in configuration. But you can't do it for public app. Am I missing something?