Token-based authentication is stateless, which means that neither the server nor the session stores any information about the user. The token is sent on every request, helping to prevent cross-site request forgery attacks. For added security the token expires after a set amount of time.
You can build integrations with apps that use HTTP even if the connection is not already provided by Celigo integrator.io.
Before creating the connection, review your app’s API guide. It should provide the information you need, such as the kind of authentication that the app requires and its URI.
Contents
- A. Set up an HTTP connection
- B. Provide general HTTP connection settings
- C. Edit token auth settings
- D. Edit common HTTP settings (optional)
- E. Save, test, and authorize
A. Set up an HTTP connection
Start establishing the universal, or generic, HTTP connection in either of the following ways:
- Select Connections from the Resources menu.
- Next, click + Create connection at the top right. In the resulting Create source panel, select HTTP from the Application list, under the Universal connectors group.
- While working in a new or existing integration, you can add an application to a flow simply by clicking Add source or Add destination/lookup. From the Application list, under Universal connectors, select HTTP.
- After the HTTP Application is added, click the Connection setting’s + button to proceed.
B. Provide general HTTP connection settings
Name (required): Provide a clear and distinguishable name. Throughout integrator.io imports and exports, you will have the option to choose this new connection, and a unique identifier will prove helpful later when selecting among a list of connections that you’ve created.
Application (required, non-editable): A reminder of the app you’re editing.
Mode (required): Select one of the following options:
- Cloud to connect to a publicly accessible server application
- On-premise to connect to a server that is publicly inaccessible and has integrator.io agent installed on it
Agent (required, if On-premise selected for Mode; otherwise not displayed): Select an agent from the list. To connect to an on-premise application, integrator.io requires that an agent be installed on a networked computer. An agent is a small application that allows you to connect to data behind your firewall. When installing an agent, you will specify a unique access token, which then populates the Agent drop-down list. The installed agents connect to integrator.io and establish a reverse SSH tunnel, allowing secure communication without the need to whitelist integrator.io IP addresses in your firewall settings. A single agent can be used by multiple different connections.
C. Edit token auth settings
Continuing in the Create connection panel, select Token for the Auth type. The settings then become specific to token auth:
Token (required): Enter your API token. Multiple layers of protection are in place, including AES 256 encryption, to keep your connection’s token safe. When editing this form later, you must enter this value again; it is stored only when the connection is saved and never displayed as text.
Send token via (required): Select the location where your API expects to find the authentication token:
- HTTP body: The API requires the token to be embedded in the body structure of your HTTP request. In such cases, place the token in your body template using the handlebars placeholder {{connection.http.auth.token.token}}.
- HTTP header: Allows you to specify the header name and authentication scheme to use when constructing the HTTP request.
- URL parameter: The authentication token is located in the URL. Specify the query string parameter name that holds the token value.
Header name (required, enabled when Send token via is set to HTTP header): Enter the header field name that contains the token, if the API expects a field other than Authorization.
Header scheme (optional): Select an HTTP authorization header scheme value. For example, Bearer would be the scheme value for Authorization: Bearer my_secret_api_token.
Parameter name (required, enabled when Send token via is set to URL parameter): Specify the name of the URL parameter that holds the API token value. For example, if you enter myAPITokenURLParam, then all HTTP requests will be sent in the format ?myAPITokenURLParam=<token>.
Override HTTP status code for auth errors (optional): Provide an alternate status code if the HTTP status code for auth errors returned by this app is not the standard 401. For example, for an API that returns a generic 400 status code, enter 400 and then specify the field in the HTTP response body that indicates auth errors.
Path to auth error field in HTTP response body (optional): If the API returns a field that contains auth errors in the HTTP response body, enter the JSON path to that field. For example, when an API returns the field errorMessage with the value Auth failed, then enter errorMessage as the path.
Auth error values (optional): If you supplied a fail path above, enter the exact values that the API will return to indicate auth errors. Separate multiple values with commas.
Configure token refresh (optional): Check this box if your token expires after a period of time. Then, configure the additional options that appear.
Configure token refresh
Refresh token (required): Enter a token that can serve as a refresh expired auth token. You can place this token in the body, headers or URL simply by referencing it with the handlebars placeholder {{connection.http.auth.token.refreshToken}}. Multiple layers of protection, including AES 256 encryption, are in place to keep your token safe. When editing this connection, you must re-enter this value each time; it is stored only when the connection is saved and never displayed as text.
HTTP method (required): If the service you’re connecting to supports token request/refresh, select the HTTP method to use in the token call. When you select POST, the setting HTTP request body is revealed, below.
Relative URI (optional): If the service you’re connecting to supports requests to obtain or refresh existing tokens, enter the URL (relative to the base URI) to use in the request token call. Click the handlebars (
) button to open the Advanced field editor and create or edit a template. Note that handlebars placeholders, such as {{connection.http.encrypted.password}}, may be used to reference any connection fields. Typically, a username/password or refresh token is required in the request, which you can store in the encrypted field or, if not sensitive, the unencrypted field.
Note: If the API you are connecting to uses a completely different URL to obtain or refresh existing tokens (instead of a relative URL), enter the full absolute URL including the HTTP prefix: http(s)://fullTokenRefreshURL.
Configure HTTP headers (optional): In some cases, it may be necessary to include custom HTTP headers with your token refresh requests. You can reference dynamic path field names for the connection using handlebars {{placeholders}}. See Configure the path to token field in the HTTP response header.
Override media type (optional): When the HTTP request requires a different media type than what is configured on the connection, select an alternate value.
HTTP request body (optional, enabled when HTTP method is POST): If the service you’re connecting to supports requests to obtain or refresh existing tokens, enter the body to use in the request token call. Click the handlebars () button to open the Advanced field editor and create or edit a template. You may also use handlebars placeholders to reference any connection fields. Typically, a username/password or refresh token would be passed in the request. You can store these values in the encrypted field or, if not sensitive, the unencrypted field. For example, {{connection.http.encrypted.password}}.
Path to token field in HTTP response body (optional): If the service you’re connecting to supports requests to obtain or refresh tokens, enter the path contained in the HTTP response where the new token can be extracted. If no value is found at this path, then the token request is considered a failure.
D. Edit common HTTP settings (optional)
Additional HTTP settings are found in the other sections in the Create connection pane (optional sections are collapsed by default):
- Application details (contains the required settings Base URI and Media type)
- Nonstandard API rate limiter
- How to test this connection?
- Advanced
For complete documentation of these settings, see Fundamentals of HTTP connections.
E. Save, test, and authorize
Once you have configured the HTTP connection, you have a few options for continuing:
- Save – click this button to test the connection, commit the new connection so that it will be available to all integrations for your account
- Save & close – click to test and save the connection and exit the Create connection pane
- Close – click to exit without saving any new changes
- Test connection – click this button to verify that your new connection is free of errors
When you test or save the connection, it is verified before continuing. If the connection fails, double-check the provided settings and test again.
Comments
8 comments
The option to send the token in the body of the HTTP call is not well documented. How does one get the token entered into the body of the HTTP call? There's some help in the contextual help but it's not correct. I'm just had coding the token in the HTTP body for now.
Hey there! Me again! I'm working on another SOAP project with a key in the request body of the export. Again, I'm trying to use a Token in the body of the request for authorization and it's not working. The documentation appears to be wrong. Can we get an answer to my request for two years ago??
David Gollom: I'm not sure what the award for patience and persistence is, but I do know they don't give them out in this lifetime. "Thanks?"
An eagle-eyed product manager looked at the article (since corrected) for us and found that the path was wrong. It should be {{connection.http.auth.token.token}} when you select Send token via: HTTP body.
Thanks Stephen! You know what's funny? I saw my original question and didn't realize it was me at first! I forgot I'd even looked at this article a couple of years ago. Thanks for getting it fixed!
Hi Stephen, I work with a number of APIs which use either API keys or basic authentication to fetch a token which is then passed into the request. I am struggling to see how this is configured in Celigo. In Postman I use a pre-request script which can do this and then use parameters in postman to set the token. Can you explain how the same is achieved in Celigo please? I.e. I need to make an HTTP request to fetch a token which is then used to pass into the api calls
Hi, Ray Wootton. I know I've run across similar questions, and the answer is either eluding me or becoming too complex as I scan support queries for different API behavior. Before I suggest talking to support, would any of these solved community posts (with example settings and a bit of back-and-forth troubleshooting) help?
Hi Stephen Brandt, many thanks for this and apologies I have taken so long to get back to you. Struggled to get this working 8 months ago, so just parked it as plenty of other work to get on with, but revisited last night and began to understand the methods used in the last link in your post. Trial and error has helped me poke around the UI to understand some of the commentary a bit better, so onwards and upwards.
Your memory is better than mine. ;)
Thanks for following up, Ray Wootton! I suspect that your question has already helped other customers in the same situation.
Please sign in to leave a comment.