Authentication for API calls is explained in this documentation. The documentation will give you background and specific information regarding all of the methods mentioned below. The following is clarification regarding common misunderstandings and reasons authentication on a call might fail:

The key thing to understand is that the different authentication methods give you different rights. Who the session is created for dictates what you can do. The whole point of authentication in an API call is to "prove" to Luminate that whoever is making the request is allowed to do so. For server side calls (SR), you'll always authenticate using the login and password of your API administrator and white listing your IP address. That gives you the security access to do whatever that API administrator is allowed to do. So if you make a server side call and put in the correct username/password but it still gives you an error and tells you you don't have permission to make the call --- that would indicate that you want to look at the security settings for your API Administrators groups. If you never set that group to have Group API permissions for example, and then you tried to make a call about groups, it would give you an error. This is equivalent to certain admins not seeing certain menu options because of their security access.

Client-side (CR) authentication is different. Because client-side methods are called from within a constituent's browser, they are almost always placed on a page hosted within Luminate (like a Pagebuilder page). This is how CR methods were intended to be used. Because of this, rather than providing a username and password, all you need to do is place [[S86]] on that page and that tag will return a token for the "auth" parameter. We do this because you have to have admin access to be able to actually edit a pagebuilder page, which is proof enough. This is the only way to use a CR method with the rights of an admin.

The other way to authenticate client side methods is to establish a session for the constituent. When you do this, the behavior of what you can and cannot do is determined by what the constituent can and cannot do. This essentially mirrors the difference between what an admin can do on the back-end and what a constituent can do on the front end. For example a constituent can view information about their own profile and donate, but they can't view information about other constituents or refund transactions. This type of authentication is what you get when you use Single Sign On, Login, or authenticateUser.

The natural response to this information is usually "The method I want to use is only available client side, and I want to make the call from an external page, how do I do that?" This is possible, and there is a free tool that you can use to assist you, but we don't support it. This is a javascript library called "Luminate Extend"  that allows you to authenticate CR calls remotely. This code is provided as-is and is not supported, though there are instructions included.  If you do end up needing any assistance, the best thing to do is ask a question on the community ( Here is where you can download the library.