[Bug]: It seems that the RestAPIAuthentication type has changed from Bearer to Basic.

[malgogi]

Symptom

I have been receiving a 401 error response when calling getUser method.
In Document, we confirmed that the authentication type is Basic.

Related Links

auth.ts

[EinfachHans]

Same problem for me. Start receiving a lot of 401 error's. Support chat checked my code and said there was a change from Bearer to Basic.

Except i think this is a breaking change and should have been announced prominent (or did i missed it?), this should be adjusted here asap

[EinfachHans]

I created a PR to address this.

Meanwhile i was able to create a workaround, but only because i use httpApi: wrapHttpLibrary(...) and then have axios send the request. Like that i'm able to manipulate the headers and replace Bearer with Basic

[tomimarkus991]

What is going on with this library, seems abandoned

[julianCast]

Is there any news to update auth header from bearer to header? OneSignal is requiring the change before 4th Dec

We’re reaching out today because some of your API requests to certain OneSignal endpoints have not included the basic authentication scheme.
Starting December 4th, we will enforce this requirement for your apps. If you don’t add authentication by this date, then requests will return an error.

[kpturner]

This seems to be par for the course for OneSignal.
You would at least expect one of two things:

1. The SDKs are kept aligned with the API rather than just ignored abandoned
2. The SDKs are documented clearly as deprecated in favour of accessing the API directly

As somebody who played a major part in recommending OneSignal to the company I work for, I now feel that I have made a mistake. They simply have not got their act together.

[mk-dev-1]

This seems to be par for the course for OneSignal. You would at least expect one of two things:

1. The SDKs are kept aligned with the API rather than just ignored abandoned

2. The SDKs are documented clearly as deprecated in favour of accessing the API directly

As somebody who played a major part in recommending OneSignal to the company I work for, I now feel that I have made a mistake. They simply have not got their act together.

Fully agreed. It is completely embarassing how this change is treated. It is going to be a lot of fun when everything starts breaking in 4 weeks.

Somehow I am not surprised, yet still disappointed....

[julianCast]

I got a response from OneSignal about this matter 😞

"Our Server Side SDKs are not currently recommended for production. They are not currently being worked on, and it's likely that they will be overlooked for this change. We advise switching to use the REST API directly.

I will reach out to the Engineering team to ensure this is made clearer, and if they can share more information on when they expect these to be production-ready.

OneSignal"

[kpturner]

Meanwhile new users who develop in node will jump on this as the official node SDK for the REST API and build software around it oblivious to the fact that they are using something that is broken/unsupported/abandoned. Great!

[kpturner]

I would like to know, if we are to now use the REST API directly, where we are supposed to get the types from? Sure we can infer them from the current documentation, but what happens when they change? It doesn't look like the REST API is even versioned to protect clients from breaking changes.

[sherwinski]

Hey everyone,

Apologies for the radio silence on this issue as the team has been heads down on other parts of our SDK.

1. The SDKs are kept aligned with the API rather than just ignored abandoned
2. The SDKs are documented clearly as deprecated in favour of accessing the API directly

Completely agree on these points and moving forward, our team will be prioritizing better support for our client libraries. In the meantime, we recommend using the REST API directly for user-centric endpoints until we get the chance to add them to the SDKs. Please keep an eye on our releases for future updates.

In regards to OP's issue, I tested the latest version of the SDK and can confirm it is working regardless of the auth prefix. Please respond back if this is still not the case for you.

[kpturner]

@sherwinski

In regards to OP's issue, I tested the latest version of the SDK and can confirm it is working regardless of the auth prefix.

That is only because the deadline for changing to the new auth method is 4th December 2025. After that, this SDK in its current guise will stop working.

[sherwinski]

@kpturner For what it's worth, the December 4th deadline only applies to the Update User, View User, and Delete User endpoints when targeting users via Aliases. Targeting user by OneSignal_ID should still work unauthenticated. Looking at this SDK, view user and update user should be fine while delete user still needs to be updated.

Our team is working on patching a fix for that now.

[kpturner]

For us, where we only use it to fetch user information via external_id and send push notifications, that is not really positive news. To be honest, to have an SDK where some things work and some things do not is worse than having the whole thing not work. Less ambiguous.

OneSignal support are pushing people to access the REST API directly and drop the use of the various SDKs - so we are getting mixed messages. Once you drop the SDK and access the API directly you are fairly unlikely to return to it. However, accessing the REST API directly wthout and SDK means:

• No types (for typescript)
• No version protection on the API

[sherwinski]

Looking at this SDK, view user and update user should be fine while delete user still needs to be updated.

Quick update: we released 5.0.0-alpha-02 to address this point.

Our team will be looking to address the inconsistencies with the auth prefix in the near future -- please let me know if you have any questions.