To make calls against your Replicon instance, you'll need to authenticate or authorize access to the instance.
If you access the reference pages using most links in this user guide, you'll automatically be prompted to log in to Replicon before being sent to the reference page, and the swimlane of the reference page should automatically update to match that of your instance.
However, if, when testing, you want to:
you should authorize access using token-based authentication.
To generate a token:
You will be prompted to log into your Replicon instance before you can access this page. This way, the reference page will be automatically authenticated for use with your instance.
You must have an Administrator permission set assigned to use this operation.
"description": "Token for testing export app",
You can update the login name in the identity parameter; when you use the token, you'll have access to all data the user you submitted has access to.
You must use a unique string in the unitOfWorkId field each time you generate a new token; the API will always return the same result the ID was originally associated with. So, if you don't update the ID, each new call will return the same token.
A successful request will return a token. The token shouldn’t expire, unless you included the Lifetime fields when generating it.
Be sure to keep your token secure, as it allows access to your Replicon data.
You'll need to enter the token on each reference page you want to test from.
When using token-based authentication, note that:
To authorize a page using a token:
Now, when you carry out test operations, the curl data should be usable, and access should be limited by the user associated with the token.
If you want to make calls programmatically, you’ll first need to authenticate using token-based Bearer authentication. Refer to the following for examples of how to format this type of authentication:
The swimlane in URL must be correct to authenticate
Each Replicon instance is hosted on a particular swimlane (sometimes called an endpoint). In the URL https://X.replicon.com/services/, X represents the swimlane, which could be NA2, NA4, EU1, etc, making the URL read https://na3.replicon.com/services/ or similar.
The swimlane assigned to an instance may change from time to time, and the API can only be accessed from your instance’s swimlane.
So, it’s a good idea to include a check in your code, and generate the web service URL dynamically each time you perform a call. And, if you’re having authentication errors, check that you’re accessing the services from the correct swimlane.
You should always include application context with each call
When making a programmatic call, we recommend you reference the purpose of the call in the X-Replicon-Application field of the header. And, each time you make a call of this type, that you include this same context in the X-Replicon-Application field. Maintaining this practice helps with troubleshooting.
For example, if the goal of a call is to add, retain, or remove user profiles, to keep them sync with Replicon, you could include this statement in the header:
You'd include this same context any time you add or update users.
If you see an error like this: All access checks failed to authorize operation '<name of operation>' : At least one of the following permissions are required: ‘<name of permission>’, you’re missing permissions required to perform the operation in question.
For any operation carried out using services, you’ll need the same permissions and products you need to carry out that operation manually within the app. For information on assigning products and permissions, select the links.
We don’t support basic authentication since it doesn’t work with certain features, such as multifactor authentication.