API

Janrain provides access to advanced features through a RESTful web API that requires only the ability to post HTTPS requests and parse XML or JSON responses. You can use these requests to retrieve contact data, map an identity to multiple accounts, and more. The RESTful format allows you to communicate with your application, and relay the results to your own site.

Janrain also uses RESTful APIs for user authentication.

Note: Our RESTful API supports both POST and GET methods, but for security reasons, POST should be used.

User Data

User Data - EntityType

POST/entityType.addAttribute
Adds an attribute to an existing entityType schema and all stored objects of that type. Note: Each attribute requires a type which defines the nature of the data to be stored.
POST/entityType.addRule
This call creates rules for user data validation on specific attributes in your schema. User data can be validated or transformed by this rule when it is added or updated. Example uses for entityType.addRule: Defining a validation rule that rejects strings that don't match a regular expression, such as rejecting username values that are not in the English alphabet. Truncating input to a certain length. See the Data Validation topic for a detailed overview.
POST/entityType.create
Create a new entityType with the specified set of attributes. EntityType JSON Structure for attr_defs Here is a basic example of a small, JSON formatted schema: [sourcecode language="js"] attr_defs=[{"name":"Name","type":"string","case-sensitive":false},{"name":"Description","type":"string","length":1000,"case-sensitive":false}] [/sourcecode] This creates a new schema with the required default attributes such as id, uuid, as well as the two new ones defined in the JSON above: name and description.
POST/entityType
Return a JSON representation of an existing entityType.
POST/entityType.getAccessSchema
Retrieve the access schema for a particular client. An access schema defines the subset of attributes to which a client has read or write access.
POST/entityType.list
Return a JSON representation of all entityTypes.
POST/entityType.removeAttribute
Remove an existing attribute from an entityType. Warning: All data associated with this attribute will be lost!
POST/entityType.removeRule
This removes any data validation currently configured for a specific attribute in a schema. For a detailed explanation of creating validation filters, refer to the Data Validation topic.
POST/entityType.rules
This lists the data validation rules that are currently set on a specific entityType. Each rule has a uuid identifier associated with it which is listed as well. See the Data Validation topic for a detailed overview.
POST/entityType.setAccessSchema
Set the access schema for a particular client. An access schema defines the subset of attributes to which a client has read or write access. Each client can have one read access schema and one write access schema defined. Which access schema is used depends on whether the API call performs a read operation or a write operation. Note:  if you want to give a client read and write access to the same set of attributes, you must set the read and write schemas in two different calls. Defining the attributes parameter When granting permissions to a top level attribute in the schema, use the attribute name formatted in JSON. Example:  ["aboutMe","created"] When granting permissions to an attribute that is part of a larger object, use an attribute path. The attribute path begins at the root of the schema, and uses slashes to navigate from the plurals to the target sub attribute. For example, to refer to the city attribute in the primaryAddress plural, use:  ["/primaryAddress/city"] For more information, refer to the Attributes topic and the Create an API Client page.
POST/entityType.setAttributeConstraints
Set the list of constraints for an attribute. Warning: This is not an additive operation, you must pass in the entire set of constraints. The available constraints are required, unique, locally-unique, alphabetic, alphanumeric, unicode-letters, unicode-printable, and email-address. Note: Refer to the Attribute Constraints topic for more information. Removing Constraints Instead of removing a constraint, use this call to overwrite the existing constraint with a new constraint. If an attribute currently has the unique and required constraints, and you want to drop the required constraint, then you would pass in constraints=["unique"]. The constraints argument must be a valid JSON array, however you can pass in an empty array, which is the equivalent of no constraints at all.

User Data - Entity

POST/entity.bulkCreate
Create multiple new data records of a specific entityType in a single API call. If the request is structurally valid and properly authorized, it is added independently. The result contains a list of results from each record addition, including the id or a failure message for each record.
POST/entity.count
Count the number of records in an entityType.
POST/entity.create
Create a new data record for an entityType. Once created, the new id, and uuid are returned. Formatting the Attributes parameter The following is an example of a valid attributes value: [sourcecode lang="json"] {"name":"Fred","Description":"Test User"} [/sourcecode]
POST/entity.delete
Delete a single entity (and any nested objects) from an application, or delete an element of a plural. Please note, all data removed with this API call is permanently deleted. Note: This must be a POST request, and due to validation, cannot be passed as URL parameters. The POST needs to be formatted using body parameters instead.
POST/entity
Retrieve a single entity (and any nested objects). Validating User Passwords The entity call may also use two optional parameters to validate a password. See the Validate User Passwords topic for more information.
POST/entity.find
Retrieve user information from an application. These data entities are returned in JSON format. This information may be filtered using the optional parameters provided. The following operators are supported in the filter parameter, from highest to lowest precedence. is null, is not null (postfix) not, ! (prefix) >, >=, <, <= (infix) =, != (infix) and (infix) or (infix) Note: Previous releases of this call included the contains operator. This operator has been removed because its behavior was counterintuitive. If you use this operator now, you will get a 485 error. Note: For the filter parameter, String values specified by operators must be surrounded by single quotes. Integer values work either with or without single quotes. Examples Get all data The entity.find call takes a max_results parameter. You can set that to a high value, or it's also possible to step through sets of values with the first_results and max_results parameters, for example, in batches of 1000: first_result=0&max_results=1000 first_result=1000&max_results=1000 first_result=2000&max_results=1000 Get only the most recently updated data There is a lastUpdated attribute added automatically to schemas. Sort on this by using the sort_on parameter. This takes a JSON list of parameters. A minus (-) in front of the attribute sorts it by descending order, so in this case sorting by the most recently updated would be: [sourcecode lang="text"]sort_on=["-lastUpdated"][/sourcecode] Find users with a birthday [sourcecode lang="text"]filter='birthday is not null'[/sourcecode] Find female users only [sourcecode lang="text"]filter='gender != "male"'[/sourcecode] Adding more than one condition to a filter: [sourcecode lang="text"]filter='gender="male" and birthday > "2012-06-13 18:02:56.012122 +0000"' [/sourcecode] Differentiating between Registrations and Signins You can use the entity.find call to differentiate between new user registrations and return user sign-ins. See Registration and Sign-in. More Comprehensive Examples List If you'd like to see a broader set of examples of API calls to the entity.find endpoint, please see the Example /entity.find Calls page in the Reference section.
POST/entity.purge
Use entity.purge to both permanently delete all entities in the specified entityType, and their history. Caution: This call deletes all data and the data cannot be recovered.
POST/entity.replace
Replace part of an entity with a value. Any object attributes that you do not specify are replaced with null. Plural values are replaced, and all new elements are automatically assigned ids. For an additive operation, use entity.update.
POST/entity.update
Updates part of an existing entity by appending attributes with data. This data is provided in a JSON object that specifies the path to the attribute, and the value to use. Any object attributes not in the JSON provided are left alone. Plural values are appended, unless an ID is provided, in which case the plural data is replaced. For more information on entity.update, see the Update an Entity topic.

Partner

POST/app/add_bp_bus
This call creates a bus owner and password, and a new Backplane bus with the new owner the owner of the new bus. The client gets access to the new bus and the call requests access tokens for the client. All the relevant data is then stored and can be retrieved with the get_backplane_properties call. Note: only available with Backplane 2.0.
POST/apps
This call lists all applications managed by a partner. This constitutes one "parent" RP and some number (possibly 0) of "child" applications, created with create.

Partner - Admin

POST/admin/add
This call adds an administrator user to the RP. Note: Multiple user entities can be associated to the same email address. When you set verify to false, attempting to add an admin user with such an ambiguous email returns an error. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/admin/delete
This call deletes an admin user on an RP. Note: The API call will not delete an admin if they are the only (non-pending) admin for that RP. The call will respond with an error in this case. In the dashboard, choosing to delete the last admin of an RP will cause the RP to be deleted. The delete API call should be used for that purpose when using the API. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/admin/get
This call returns all admin users currently assigned to the RP. It also lists the email associated with each admin user, and if they are subscribed to notifications. Accepted Content-types application/x-www-form-urlencoded multipart/form-data

Partner - App

POST/app/add_domain
This call adds a domain to an existing Social Login application. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/app/create
This call creates a new Social Login application. You can use the new application immediately for authenticating with OpenID-enabled providers (Google, AOl, and so on), but non-OpenID providers, such as Facebook, require additional configuration. After calling this function, use set_properties to enable these additional features. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/app/create_invite
This call generates an email invitation for administrative access to an existing application. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/app/delete
This call deletes an existing application. This operation completely destroys the Social Login application and is irreversible. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/app/get_pending_invites
This API call is deprecated. Please use the admin/get call instead. This call gets a list of all pending invitations for an Social Login application. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/app/get_properties
This call returns a list of the configured properties for an Social Login application. You can use this in conjunction with /partner/v2/app/set_properties, which can be called after /partner/v2/app/create to configure the application. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/app/get_provider_permissions
This call returns an Social Login application’s permissions for a provider, as set with the set_provider_permissions call. Refer to set_provider_permissions for permissions details. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/app/reset_api_key
This call resets the API key for a given partner RP application. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/app/set_properties
This call configures Social Login application properties for a given application. Use this function to bind a given application to a given provider. For example, after calling create, use this function to set up a binding to a Facebook application. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/app/set_provider_permissions
This call sets an Social Login application’s permissions for a provider. The permissions that you can set depend on the provider, service level, and whether the provider has been configured or not. You can set permissions if, and only if, you pass them in the permissions parameter. Each request replaces the existing set of permissions. The old ones are cleared and the new ones set. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/app/verify_domain
This function automates the server-side component of the provider-specific domain verification mechanism. This function should be called before /partner/v2/app/set_properties to complete the domain verification process. Only Google and Yahoo! support this feature. Accepted Content-types application/x-www-form-urlencoded multipart/form-data

Social Login

Social Login - Mapping

POST/all_mappings
The all_mappings call returns all of the stored mappings of an application, which is identified using the application's apiKey. These mappings associate users with multiple identity provider accounts using a primary key. Note: The mapping API lets sites store each of the user's external identifiers along with the primary key of the site's user/account record on the Janrain server. They are then included on every call to auth_info where the social identifier has been previously mapped. Read the Account Mapping overview topic to learn more. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/map
Use the map to associate a primary key with a user's social identity. Note: The mapping API lets sites store each of the user's external identifiers along with the primary key of the site's user/account record on the Janrain server. They are then included on every call to auth_info where the social identifier has been previously mapped. Read the Account Mapping overview topic to learn more. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/mappings
The mappings call returns all the stored Identity Providers associated with a particular user's primary key. Note: The mapping API lets sites store each of the user's external identifiers along with the primary key of the site's user/account record on the Janrain server. They are then included on every call to auth_info where the social identifier has been previously mapped. Read the Account Mapping overview topic to learn more. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/unmap
Unmapping removes an Identity Provider from a primary key as well as allowing you to optionally unlink your application from the user's account with the provider. It may be helpful to review the mappings call. Read the Account Mapping overview topic to learn more. Accepted Content-types application/x-www-form-urlencoded multipart/form-data

Social Login - Login

POST/add_or_update_access_token
Adds or updates an OAuth access_token for a user outside the usual login flow. When a user logs in with an OAuth1 or OAuth2 Identity Provider, Janrain will request an OAuth token from the provider. This OAuth token is used when making subsequent API calls to the provider. The add_or_update_access_token call adds a token retrieved using a different method to Janrain. Possible Use Cases: If you are migrating an existing application to Social Login or have otherwise acquired an OAuth token for a user outside of Janrain, you may wish to pass that token to in in order to make Janrain RESTful API calls for that user. Data is needed for a user that has never registered using Social Login before. The user's ID and access token are recorded, making it possible to use the get_user_data endpoint. Only these identity providers support this call: Facebook RenRen Soundcloud Foursquare Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/auth_info
This call is used to authenticate Social Login users. You must use https to make this call. During the authentication process, the auth_info call is used to retrieve the profile information of the user. Using the apiKey of the application, and the one time token provided by Social Login, it returns the requested data from the Identity Provider. Examples of auth_info responses by provider are available in the auth_info Overview topic. Accepted Content-types application/x-www-form-urlencoded multipart/form-data Portable Contacts Format The Portable Contacts Format is industry standard. You can find the details at: http://portablecontacts.net/ accessCredentials Fields The list below shows the fields returned by accessCredentials, listed by Provider. Amazon — accessToken, uid, expires, refreshToken, scopes Disqus — accessToken, uuid, expires, refreshToken, type Facebook — accessToken, expires, uid, type Flickr, MySpace, Yahoo! — oauthToken, oauthSessionHandle, oauthTokenSecret, type Google — oauthToken, oauthTokenSecret, scopes, type Google+ — accessToken, uid, expires, scopes, type Instagram — accessToken, uid, scopes, type LinkedIn, Orkut, Twitter — oauthToken, oauthTokenSecret, type Mixi — accessToken, refreshToken, expires, scopes MYDIGIPASS.COM —  accessToken, uid, type PayPal — uid QQ — accessToken, uid, scopes, type Ren Ren — type, oauthToken, uid, expires Sound Cloud, Sina Weibo — type, oauthToken, uid tumblr — oauthToken, oauthTokenSecret, uid, type VK — accessToken, uuid, expires, scopes, types Microsoft Account — eact, type Xing — oauthToken, oauthTokenSecret, uid, type Provider Fields The list below shows the fields returned by provider, listed by Provider. Facebook — albums, games, groups, videos Foursquare — type, pings, relationship LinkedIn — associations, patents, numRecommenders, industry, following, courses, certifications, publications, positions, jobBookmarks, honors, groupMemberships, mFeedRssUrl, skills, proposalComments, recommendations, volunteer Mixi — occupation, bloodType, favoriteThigns Paypal — verifiedAccount SalesForce — local, userType, active
POST/get_app_settings
Enables you to make API calls to get the following application properties (from the application settings page of the dashboard). privacy policy — This URL is sent with requests for registration data and is displayed by the identity provider as a link to the user. favicon — The URL of your favicon, which can be displayed by some identity providers during authentication. domain redirect — This feature is only available for enterprise level apps and apps owned by Janrain's partners. A URL redirect destination for users visiting your sign-in url (such as, http://foobar-signin.rpxnow.com). post tokens to token_url — Use the POST method of HTTP requests to submit auth_info tokens to your token URL. one-time use auth_info tokens — Tokens for the auth_info API call can be used only once. google profile url — Return users' globally unique Google profile URLs as the identifier element in the auth_info API call response instead of the OpenID URL. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/get_available_providers
Returns a list of configured providers for an application. The providers call is similar, but only returns providers configured for an application. This call is used if you are using custom code for Social Login instead of using the Janrain JavaScript implementation. There are no required parameters or authentication to use for get_available_providers. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/get_contacts
The get_contacts call uses the apiKey and identifier to return a list of all the contacts related to the user. The data returned and type of relationship differs between Identity Providers. The Identity Providers that support this call are: Facebook — Only for apps created before April 30th, 2014. Apps created after this date do not have access to get_contacts. Please refer to this support notification for more information. Google Google+ Twitter — Does not support friends. Does support followers, following, and friendships. See get_contacts Response for more details. Yahoo! LinkedIn —  r_network permission is required to use get_contacts. Windows Live Salesforce Disqus Mixi Myspace Sina Weibo RenRen Soundcloud Tencent Weibo Tumblr VK — Does not support friendships. Does support friends, followers, and following. See get_contacts Response for more details. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/get_user_data
Note: certain tiers may not have access to this feature. Use the get_user_data call to obtain an up-to-date copy of a user's profile as previously returned by an auth_info API call. Warning: It is possible that the access token will expire prematurely if the user deauthorizes the customer's application or if they change their password. Your implementation of this call should take this into account. This feature is supported for identifiers from the following providers: Facebook - Note: When using Facebook, this call must be made in the lifespan of the access token. This is typically 60 days. Microsoft Account Yahoo! Twitter MySpace LinkedIn Renren Sina Weibo SoundCloud Provider specific data is the same as returned by auth_info. See the auth_info documentation for a detailed list. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/providers
This call returns a list of configured sign-in or social providers configured for an application. Note: This API call does not use the apiKey to identify the application, but rather, it must be called on the application's domain. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/set_app_settings
Enables you to make API calls to set the following application properties (from the application settings page of the dashboard). privacy policy — This URL is sent with requests for registration data and is displayed by the identity provider as a link to the user. favicon — The URL of your favicon, which can be displayed by some identity providers during authentication. domain redirect — This feature is only available for enterprise level apps and apps owned by Janrain's partners. A URL redirect destination for users visiting your sign-in url (such as, http://foobar-signin.rpxnow.com). post tokens to token_url — Use the POST method of HTTP requests to submit auth_info tokens to your token URL. one-time use auth_info tokens — Tokens for the auth_info API call can be used only once. google profile url — Return users' globally unique Google profile URLs as the identifier element in the auth_info API call response instead of the OpenID URL. Separate settings in the set_app_settings call with an ampersand (&). So the query: [sourcecode lang="xml"]privacyPolicy=https%3A%2F%2Fmysite.com%2Fprivacy&favicon=http%3A%2F%2Fmysite.com%2Ffavicon.ico&googleProfileUrl=true[/sourcecode] sets privacyPolicy, favicon, and googleProfileUrl. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/set_auth_providers
Use set_auth_providers to define the list of identity providers provided by the Janrain server to sign-in enabled pages. This is the same list that is managed by the dashboard. This call modifies the list of providers presented to the user. Accepted Content-types application/x-www-form-urlencoded multipart/form-data

Social Login - Configure RP

POST/add_domain_patterns
Use the add_domain_patterns call to append domains to the current whitelist for an application. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/get_backplane_properties
Use this call for Backplane Protocol enabled Janrain solutions only. For more information on updating web elements with the Backplane Protocol, please read the Backplane Protocol page. The get_backplane_properties call queries the Backplane server to verify that Backplane credentials have been set up. If the proper credentials are in place, details are returned. If not, no details are returned. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/get_domain_patterns
Use this call to return a list of all domains currently whitelisted for an application.
POST/set_backplane_properties
The set_backplane_properties call configures the Backplane server used to communicate with all of the Backplane enabled apps on a page. For more information on updating apps with the Backplane, please refer to the Janrain Backplane page. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/set_domain_patterns
Use the set_domain_patterns call to replace the current whitelist for an application. Accepted Content-types application/x-www-form-urlencoded multipart/form-data

Social Sharing

Social Sharing - Sharing

POST/sharing/broadcast
The broadcast call shares activity information directly with a provider. The information provided in the parameters is passed along to a provider to publish on their network. The broadcast call shares with one provider at a time, determined by the identifier or device_token that you use. Note: Not all providers support all sharing parameters. To see which providers support what features, refer to the Sharing Support by Provider page. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/sharing/direct
This API shares activity information directly with the specified recipients on a provider's network, instead of publishing it to everyone on the network. The direct call shares with one provider at a time, determined by the identifier or device_token you enter. Note: Not all providers support all sharing parameters. To see which providers support what features, refer to the Sharing Support by Provider page. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/get_share_count
Returns the number of a times a given URL has been shared. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/get_share_providers
Note: This API call works only with the current Sharing solution. It returns a list of email and sharing providers configured for the application. This call has no required parameters; it identifies the proper application by the realm prefacing the URL path. Accepted Content-types application/x-www-form-urlencoded multipart/form-data
POST/set_share_providers
Use set_share_providers to define the providers offered by Social Sharing. You can set both sharing and email providers. Note: This call overwrites the existing providers, if any. In addition to the providers listed in the share parameter, you can enter email as well. This signifies direct sharing through email. Accepted Content-types application/x-www-form-urlencoded multipart/form-data

Authentication

Authentication - OAuth

POST/oauth/auth_native
Use this call to create Social Login-type authorization for native mobile apps. This call necessarily refers to a flow. If you do not use the optional flow_name parameter, the call will use the default flow. See the default_flow_name and default_flow_version settings on the JavaScript Settings page. Note: This must be a POST request, and due to validation, cannot be passed as URL parameters. The POST needs to be formatted using body parameters instead. login_client The API client you use to make the /auth_native call must have the login_client setting. See Create an API Client for details on how to create a secure login client for your app. Merge Token If you have had a previous call to /oauth/auth_native fail with code 380, email_address_in_use, you can merge the two accounts by passing a merge_token parameter while authorizing as the existing user. So, if a user tries to log in with the wrong account, and you get an error like this, [sourcecode lang="html"] { "code": 380, "error": "invalid_argument", "stat": "error", "error_description": "a user already exists with that email address", "existing_provider": "facebook" }[/sourcecode] Then user should see an option to merge accounts. For which your code should resemble this: [sourcecode lang="html"] { "access_token": "badcafe" }[/sourcecode] Flow Name and Flow Version The locale, flow_name, and flow_version parameters are all related to each other, though flow_name and flow_version are not required. Use the locale parameter to set the user's location, language, and any special flow requirements you may have. You create the locales, so you also name them. The locale parameter uses the flow which you can define with the the flow_name and flow_version parameters. If you do not define these, the Registration application relies on the default_flow_name and default_flow_version fields.
POST/oauth/auth_native_traditional
Use this call to create a traditional username and password-type login authorization for native mobile apps. This call necessarily refers to a flow. If you do not use the optional flow_name parameter, the call will use the default flow. See the default_flow_name and default_flow_version settings on the JavaScript Settings page. Note: This must be a POST request, and due to validation, cannot be passed as URL parameters. The POST needs to be formatted using body parameters instead. Flow Name and Flow Version The locale, flow_name, and flow_version parameters are all related to each other, though flow_name and flow_version are not required. These parameters also interact with the default_flow_name and default_flow_version parameters.
POST/oauth/forgot_password_native
This call's behavior is determined primarily by your flow and the form parameter you pass in. This API call is the same as verify_email_native. We provided the separate endpoints for your convenience. Note:  This must be a POST request, and due to validation, cannot be passed as URL parameters. The POST needs to be formatted using body parameters instead. Flow Name and Flow Version The locale, flow_name, and flow_version parameters are all related to each other, though flow_name and flow_version are not required. These parameters also interact with the default_flow_name and default_flow_version parameters, which you can find on the JavaScript Settings page.
POST/oauth/link_account_native
This call links a new social provider identity to an existing user account so that the new identity can be used to sign into the user account. Note:  This must be a POST request, and due to validation, cannot be passed as URL parameters. The POST needs to be formatted using body parameters instead. Flow Name and Flow Version The locale, flow_name, and flow_version parameters are all related to each other, though flow_name and flow_version are not required. These parameters also interact with the default_flow_name and default_flow_version parameters, which you can find on the JavaScript Settings page.
POST/oauth/register_native
This is the second step in two-step registration. You must have previously called auth_native for this endpoint to work. This call necessarily refers to a flow. If you do not use the optional flow_name parameter, the call will use the default flow. See the default_flow_name and default_flow_version settings on the JavaScript Settings page. Note: This must be a POST request, and due to validation, cannot be passed as URL parameters. The POST needs to be formatted using body parameters instead. Flow Name and Flow Version The locale, flow_name, and flow_version parameters are all related to each other, though flow_name and flow_version are not required. These parameters also interact with the default_flow_name and default_flow_version parameters.
POST/oauth/register_native_traditional
This call creates a new user. This call necessarily refers to a flow. If you do not use the optional flow_name parameter, the call will use the default flow. See the default_flow_name and default_flow_version settings on the JavaScript Settings page. Note: This must be a POST request, and due to validation, cannot be passed as URL parameters. The POST needs to be formatted using body parameters instead. Flow Name and Flow Version The locale, flow_name, and flow_version parameters are all related to each other, though flow_name and flow_version are not required. These parameters also interact with the default_flow_name and default_flow_version parameters.
POST/oauth/token
Exchange an authorization code for an access_token. There are two ways to authenticate Registration API calls. All of the API calls may use a client_secret and client_id combination to validate API requests. Alternatively, some API calls may use Oauth authentication instead. These calls may use either method: entity entity.adopt entity.delete entity.replace entity.update In OAuth-style authentication, tokens are issued from a central authority. Depending on the type of access granted, you can use the returned token in place of the client_id and client_secret parameters. For more information for this method of authentication, refer to the Use OAuth Authentication topic.
POST/oauth/unlink_account_native
This endpoint is used to unlink a previously-linked social provider from a user's account. Once unlinked, the social provider cannot be used to sign into the user account.
POST/oauth/update_profile_native
This call is used to update a user profile generated via native authentication. It requires an access_token, and therefore it needs to be preceded by one of the native authentication endpoints that return the token such as /oauth/auth_native. Note: This must be a POST request, and due to validation, cannot be passed as URL parameters. The POST needs to be formatted using body parameters instead.
POST/oauth/verify_email_native
This call's behavior is determined primarily by your flow and the form parameter you pass in. This API call is the same as forgot_password_native. We provided the separate endpoints for your convenience. Note: This must be a POST request, and due to validation, cannot be passed as URL parameters. The POST needs to be formatted using body parameters instead. Flow Name and Flow Version The locale, flow_name, and flow_version parameters are all related to each other, though flow_name and flow_version are not required. These parameters also interact with the default_flow_name and default_flow_version parameters, which you can find on the JavaScript Settings page.

Authentication - Access Codes and Tokens

POST/access/getAccessToken
This API call retrieves an accessToken for signing in to an application.
POST/access/getAuthorizationCode
Get an authorization code that can be exchanged for an access_token and a refresh_token.
POST/access/getCreationToken
Gets a creation token which can be used to make API calls without the use of a client id and secret. Calls that use the creation token include:  entity.create, entity.update, entity, entityType.create, and entity.adopt. This is targeted for mobile developers who do not want to expose their credentials to untrusted (any) mobile devices.
POST/access/getVerificationCode
Gets a verification code that can later be used with useVerificationCode. The useVerificationCode call sets a time field in an entity to the current time. This is useful for recording timestamps for when an email address was verified, or similar purposes.
POST/access/useVerificationCode
Uses a verification code to set a time field to the current time. Any particular verification code can only be used once. This is often used for items like email verification.

API Client Configuration

API Client Configuration - Settings

POST/settings/delete
Delete a key from the settings for a particular client. Returns a Boolean indicating whether the key existed. This does not modify the application-wide default value for a key.
POST/settings/delete_default
Delete a key from the application-wide default settings. Returns a Boolean indicating whether the key existed. This does not modify any per-client settings.
POST/settings/get
Get the value associated with a key for a particular client_id. If the key has no value for that client, then return the key's default value for the application, or if the key has no default value, then return null.
POST/settings/get_default
Get the default value of a key for the current application. Returns the value of the key, or null if no such key exists.
POST/settings/get_multi
Look up multiple keys. Each value is retrieved, as in the settings/get command, by first looking at the client-specific setting, and then falling back to the application default setting.
POST/settings/items
Get all settings for a particular client, including those from the application-wide default settings. If a key is defined in both the client and application settings, only the client-specific value is returned. Returns a JSON object of all key-value pairs.
POST/settings/keys
Get all keys for a particular client, including those from the application-wide default settings. Returns an array of the keys.
POST/settings/set
Assign a key-value pair for a particular client_id. If the key does not exist, it will be created. If the key already exists, this call overwrites the existing value. Returns a Boolean that indicates whether the key already existed. true indicates the key has been overwritten. false indicates that a new key has been created. Note: You cannot use settings/set to modify the application-wide default settings.
POST/settings/set_default
Set the application-wide default value for a key. This will create a new key with a default value, if the key does not yet exist in the application. If the key does exist, the value will be overwritten. Returns a Boolean that indicates whether the key already existed. true indicates that the key has been overwritten, whereas false indicates that a new key has been created. Note: You cannot use settings/set_default to modify any client-specific settings.
POST/settings/set_multi
Assign multiple settings for a particular client_id. Returns a JSON object in which each key is mapped to a Boolean that indicates whether the key already existed. true indicates that a previous key did exist and has been overwritten, whereas false indicates that there was no previous key and a new key has been created. Does not modify application-wide settings.

API Client Configuration - Clients

POST/clients/add
Add a new client to Registration. Once created, your new client will have access to the API, and if applicable, the UI. Default clients have no permissions, so you need to configure them in the dashboard, unless you add permissions using the features parameter. The client_id and client_secret are generated by Janrain and included in the API response. This API call may only be made by the owner client, denoted by the 'owner' icon in the Janrain dashboard. Optionally, you may set the features for the client at the time of creation. The features that you can add are: owner — Complete admin access. access_issuer — Can issue access tokens for other clients. direct_read_access — Has read access to all records. direct_access — Has read and write access to all records. image_create — Allows the client to upload images to Janrain that are stored outside of entities, and and be viewed from a public URL. login_client — This client has permission to use login and registration based API endpoints. For more information on these features, see the Create an API Client topic.
POST/clients/clear_whitelist
Clear the IP whitelist for a target client, resetting it to the default value that allows all IP addresses. Only the 'owner' client may make this API call. The default whitelist is ["0.0.0.0/0"], which means that all IP addresses are allowed.
POST/clients/delete
Delete a client. Only the owner client may make this API call.
POST/clients/list
Get a list of the clients in your application, optionally filtered by client feature. Only the owner client can make this API call.
POST/clients/reset_secret
Generates a new client secret for a specified client id. The old client secret will be valid for a specified grace period. Allows customers who have a security concern to change the client_secret, avoiding the need to generate a new client/secret pair, and thus have to change permissions, access schemas, and hard-coded instances of the credentials. The grace period is provided to allow changeover before the new secret breaks existing code.
POST/clients/set_description
Change the description of a client. This can also be thought of as the name of the client. This API call may only be made by the owner client.
POST/clients/set_features
Change the features that a target client has by overwriting the old feature list. This API call may only be made by the 'owner' client. The owner client may not remove the 'owner' feature from itself. Note: You may assign more that one 'owner' client. The features that you can set with this call are: owner — Complete admin access. access_issuer — Can issue access tokens for other clients. direct_read_access — Has read access to all records. direct_access — Has read and write access to all records. image_create — Allows the client to upload images that are stored outside of entities, and and be viewed from a public URL. login_client — Creates a read-only client for logging users into your website, or application. This prevents malicious users from gaining access to your owner client id. See Create an API Client for more details. Note that clients with the direct_read_access and direct_access features are still subject to the access schemas. For example, if the client has a write access schema defined, then they will only be able to write to the "foo" attribute if it exists in the access schema and they have the direct_access feature. Also, the direct_access feature implies the direct_read_access feature.
POST/clients/set_whitelist
Change the IP whitelist for a target client, overwriting the previous whitelist. Only the 'owner' client may make this API call, marked by the "owner" icon in the Dashboard, in the API Clients section. If the owner client sets the whitelist for itself, the whitelist must allow access from the IP address making the call. All new clients begin with a default whitelist of ["0.0.0.0/0"], which means that all IP addresses are allowed.

Plugin API

Plugin API - Plugin

POST/plugin/lookup_rp
We provide the lookup_rp call to help developers integrate Social Login functionality into your plugin. The API provides the variables needed for Social Login interaction using only the API key. Using lookup_rp is also generally safer than using the equivalent API calls, because updates made to Janrain won't directly affect the plugin. Accepted Content-types application/x-www-form-urlencoded multipart/form-data

Legacy

Legacy - Webhooks 1.x

POST/webhooks/add
This is used to add and configure a webhook. Once this RESTful call is successfully made, the attribute targeted will return a notification every time a specified change occurs. Endpoint URL: https://{your-engage-domain.com}/api/v2/webhooks/add
POST/webhooks/delete
This deletes a webhook. Endpoint URL: https://{your-engage-domain.com}/api/v2/webhooks/delete
POST/webhooks/find
This returns the configuration of a specific webhook. Endpoint URL: https://{your-engage-domain.com}/api/v2/webhooks/find
POST/webhooks/list
Returns a list of all the configured webhooks associated with a User Registration integration. Endpoint URL: https://{your-engage-domain.com}/api/v2/webhooks/list
POST/webhooks/update
This updates an existing webhook. Values passed in the parameters overwrite the current configuration. Endpoint URL: https://{your-engage-domain.com}/api/v2/webhooks/update

Legacy - Versions

POST/versions/entity
This API is no longer supported and is not available to new applications. Retrieve a past value of single entity by primary key and timestamp. The example below shows how to retrieve the past value of an entity of type user by id and timestamp.
POST/versions/entityType
This API is no longer supported and is not available to new applications. Retrieve a past schema of an entityType by timestamp. Formatting the 'timestamp' parameter The Janrain servers interpret each of the following as the same dateTime value: 2003-01-02 6:15pm 2 Jan 03 18:15:00.00 01-02-03 6:15pm January 2, 2003 11:15am -0700 For more information on timestamps, please refer to the Timestamp section in the Attributes topic.