Whenever I make an API call, I am given an error message that states that I do not have the authority to take that action. How do I properly authenticate my API call?
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.