NinjaOne API Connection

[alandepew]

Has anyone setup a connection with NinjaOne using the HTTP connector? We have setup the OAuth iClient but are getting an undefined token when calling out. I have a feeling it has to do with the double authentication that happens. The API says to first call /oauth/authorize and then use that authorization code to get an access token from /oauth/token.

Ninja One Public API Reference

You can see from the test call we are getting an undefined token:

Here is the iClient setup:

[aaronpaulanthony]

Hi Alan,

Thank you for reaching out!

For connecting to the NinjaOne Public API from integrator.io, I would recommend configuring the connection to use OAuth 2.0 Client Credentials rather than the Authorization Code grant type, assuming this is a server-to-server integration and does not require user-delegated authentication.

Could you please try the following configuration?

• In your connector**,** configure the OAuth 2.0 iClient with the following settings:
  • Grant Type: Client Credentials
  • Access Token URL: https://app.ninjarmm.com/ws/oauth/token
  • Client ID / Client Secret: Use the credentials generated during the NinjaOne application registration.
  • Scope: Specify the appropriate scopes required for your use case (for example, monitoring if applicable).
  • Token Delivery: HTTP Header -> Authorization: Bearer

One issue that commonly causes problems is using the wrong regional endpoint. Please ensure that the base URL matches your NinjaOne tenant. For example, some tenants use the ninjarmm.com domain, while others use ninjaone.com. Using the incorrect domain may cause the token request to fail or return an unexpected response.

Additionally, verify that the required scopes are explicitly configured in the iClient. Leaving the scope field blank can result in an undefined or invalid token response, depending on the tenant configuration.

I hope this helps. Please let me know if you're still encountering any issues!

[Mark_Hensler]

We are currently using Client Credentials rather than Authorization Code.

I can get the same credentials to work in Postman. The connection in Celigo passes connection tests and shows as "Online". However, we cannot use the connection to pull data into any flows.

Can you confirm that the "Redirect URIs" in NinjaOne should include "https://integrator.io/connection/oauth2callback"?

[sreevaniamara]

@Mark_Hensler
Yes, https://integrator.io/connection/oauth2callback is the correct Redirect URI to use in NinjaOne.

Since you're using Client Credentials and the connection tests as "Online" but isn't pulling data into flows, could you try the following:

In the iClient configuration, update the "Send client credentials via" field to "HTTP body" and then test the export to see if data comes through.

If the issue persists, we'd like to capture the debug logs to investigate further. Here's how:

1. On the export step, click "View debug logs" (as shown below).
2. In the debug logs panel, set the capture duration and click Apply to enable logging for the next few minutes.
3. Click Send to trigger the export.
4. Share the captured logs here so we can take a closer look (Mask any sensitive data before sharing).

View Debug Logs on the export step:

Enable Debug Log Capture:

[Mark_Hensler]

The connection fails in flows:

Yet, the connection is online and tests are successful:

[Mark_Hensler]

I just noticed the "How to test" portion is blank. So, I'm no longer sure how accurate the "connection is working" claim is.

[Mark_Hensler]

When I call an endpoint in Postman with a missing Authentication header, the response looks like this:

So in Celigo, I set:

Then I took an endpoint that works via Postman:

And I attempted to setup the "How to test" portion:

When I click "Test Connection", I get an error:

When I view the log, the request appears to be missing the Bearer token:

And the Response is an expected error:

Assumed pertinent areas of our config:

[sreevaniamara]

Hi Mark,

Thanks for the details! The "Bearer undefined" error typically points to the iClient not parsing the token response correctly, which can sometimes happen due to a misconfigured or corrupted iClient setup.

As a quick troubleshooting step, we'd recommend creating a fresh iClient from scratch and re-testing the connection in your flow.

• Grant Type: Client Credentials
• Access Token URL: https://app.ninjarmm.com/ws/oauth/token
• Client ID / Client Secret: Use the credentials generated during the NinjaOne application registration.
• Scope: Specify the appropriate scopes required for your use case (for example, monitoring if applicable).
• "Send client credentials via" : "HTTP body"
• Token Delivery: HTTP Header -> Authorization: Bearer

If the issue persists after that, we'd suggest reaching out through one of these channels for deeper investigation:

• Submit a Support Ticket: https://docs.celigo.com/hc/en-us/articles/4407535381147-Submit-a-support-ticket
• Attend Office Hours: https://docs.celigo.com/hc/en-us/articles/360045798291-Get-real-time-help-in-Office-Hours

[Mark_Hensler]

Brand new Connection with a brand new iClient:

I will look into creating a support ticket.

[tylerlamparter]

Can you set Valid domain names to ninjarmm.com?

[Mark_Hensler]

I made the change that Tyler suggested on my original NinjaOne connector, and it worked.

I don't understand why this worked. I assume that this would indicate communication with a different subdomain or no subdomain. However, all of the endpoints that I have used in Postman are app.ninjarmm.com.

[tylerlamparter]

Hey Alan, good question and glad you got unblocked.

The "Valid domain names" field is a security control added as part of the HTTP Adapter OAuth 2.0 redesign a couple years back. Before Celigo makes any OAuth request (auth, token fetch, refresh, revoke), it checks the destination URL's domain against that allowlist. If nothing matches, the request gets blocked. The intent is to prevent Celigo's infrastructure from being used to broker OAuth flows to arbitrary domains, which matters on a multi-tenant platform where iClients can be shared.

For NinjaOne, the OAuth endpoints are under app.ninjarmm.com, so ninjarmm.com covers it.

That said, the main usability gap here is that when domain validation blocks a request, you get an undefined token instead of a clear error explaining what happened. Taking this as feedback and we'll look at what we can do to surface a better error message for this case, and potentially simplify the field for situations where the token URL is already configured on the iClient. Appreciate you documenting it since it'll help others hit the same issue.

[Mark_Hensler]

Thank you for the insight, Tyler.

Some vendors (i.e. Atlassian, LogicMonitor) use the subdomain to identify the tenant. For these vendors, I would want my iClient to allow traffic to my subdomain/tenant (client-abc.vendor.com) but not any other subdomain/tenant (client-xyz.vendor.com). Is this achievable?

[tylerlamparter]

Supporting exact subdomain matching seems like a reasonable ask and a tighter security posture than what's possible today, so we'll look at what it would take.