AuthRocket has 3 different APIs, each with several available API methods.
Both AuthRocket APIs are accessed via a *.authrocket.com URL. You will use your Secret API Key to access these APIs. As such, they are intended to be used only by server-side app(s).
The LoginRocket API is accessed via a *.loginrocket.com URL. This API does not require your Secret API Key and may be safely accessed by your users via a web browser, mobile app, or any other client-side app. Additionally, this API supports both CORS and JSONP.
The Core API includes all the basic API methods that may be used to create, update, authenticate, verify, and otherwise manage users and accounts. If your server-side app needs to talk with AuthRocket at all, these are the APIs you’ll likely start with.
The Core API includes Memberships, Orgs (Groups), Sessions, Social Logins, and Users.
Learn more about Accessing the AuthRocket APIs.
The Extended API covers both extended functionality related to users and accounts, as well as configuring and managing the rest of your AuthRocket service.
Many of our customers use only the management portal to configure and otherwise manage their service. However, if you need to automate some portion of your AuthRocket service beyond users and accounts, this is the place look.
The Extended API includes Auth Providers, Connected Apps, Credentials, Email and Webhooks, Events, Notifications, Realms, and Signup Tokens.
Learn more about Accessing the AuthRocket APIs.
The LoginRocket API contains all the methods available for direct use by your users. These cover much of the same functionality as our LoginRocket hosted logins and signups feature. For those using the hosted LoginRocket, you may not need to access these directly. But, for those wanting to integrate the login and/or signup process more tightly into your app (whether web or mobile), these are the API methods you’ll need.
Learn more about Accessing the LoginRocket API or the LoginRocket API itself.
When a resource is created, updated or deleted, there may sometimes be a delay between the time the data is added, changed, or marked deleted and when the new state shows up via a subsequent query or when any old data is actually removed from our systems and backups. This is a result of an eventual consistency architecture and other factors including audit logs, event logs, rolling backups, replication delays, reporting systems, etc.
Questions? Find a Typo? Get in touch.