- Getting started
- Notifications
- Troubleshooting
- Connector Builder
- ActiveCampaign
- Active Directory - Preview
- Adobe Acrobat Sign
- Adobe PDF Services
- Amazon Bedrock
- Amazon Connect
- Amazon Polly
- Amazon SES
- Amazon Transcribe
- Amazon Web Services
- Anthropic Claude
- Asana
- AWeber
- Azure AI Document Intelligence
- Azure Maps
- BambooHR
- Box
- Brevo
- Calendly
- Campaign Monitor
- Cisco Webex Teams
- Citrix ShareFile
- Clearbit
- Confluence Cloud
- Constant Contact
- Coupa
- Customer.io
- Datadog
- Deputy
- Discord
- DocuSign
- Drip
- Dropbox
- Egnyte
- Eventbrite
- Exchangerates
- Exchange Server - Preview
- Expensify
- Facebook
- Freshbooks
- Freshdesk
- Freshsales - Preview
- Freshservice
- GetResponse
- GitHub
- Gmail
- Google Cloud Platform
- Google Docs
- Google Drive
- Google Maps
- Google Sheets
- Google Speech-to-Text
- Google Text-to-Speech
- Google Tasks - Preview
- Google Vertex
- Google Vision - Preview
- Google Workspace - Preview
- GoToWebinar
- Greenhouse
- HTTP Webhook - Preview
- Hubspot CRM
- HubSpot Marketing
- HyperV - Preview
- iContact
- Insightly CRM
- Intercom
- Jira
- Keap
- Klaviyo
- LinkedIn
- Mail - Preview
- Mailchimp
- Mailgun
- Mailjet
- MailerLite
- Marketo
- Microsoft 365
- Microsoft Azure
- Microsoft Azure Active Directory
- Microsoft Azure OpenAI
- Microsoft Dynamics 365 CRM
- Microsoft OneDrive & Sharepoint
- Microsoft Outlook 365
- Microsoft Sentiment
- Microsoft Teams
- Microsoft Translator
- Microsoft Vision
- Miro
- Okta
- OpenAI
- Oracle Eloqua
- Oracle NetSuite
- PagerDuty
- PayPal
- PDFMonkey
- Pinecone
- Pipedrive
- QuickBooksOnline
- Quip
- Salesforce
- Salesforce Marketing Cloud
- SAP BAPI - Preview
- SAP Concur
- SendGrid
- ServiceNow
- Shopify
- Slack
- SmartRecruiters
- Smartsheet
- Stripe
- Sugar Enterprise
- Sugar Professional
- Sugar Sell
- Sugar Serve
- System Center - Preview
- TangoCard
- Todoist
- Trello
- Twilio
- X (formerly Twitter)
- Xero
- watsonx.ai
- WhatsApp Business
- WooCommerce
- Workable
- Workday
- YouTube
- Zendesk
- Zoho Campaigns
- Zoho Desk
- Zoho Mail
- ZoomInfo
Configuring the authentication
One of the big pillars for creating a connector is identifying and correctly integrating its authentication setup. If done correctly, once the connector is published to the Integration Service catalog, users can create connections to it just like with any other connector within the catalog.
All connectors reuse the authentication framework so that the full authentication flow and connection management can be handled in a unified approach.
The end-result of authentication is that any subsequent request within this connector uses the result of the authentication process for every API call. For example, a Bearer token is sent in the headers on every API call:
Connector Builder supports the following industry standards through simple configuration rather than extensive coding:
- OAuth 2.0 Authorization code
- OAuth 2.0 Authorization code with PKCE
- OAuth 2.0 Client credentials
- Basic
- API key
- Personal Access Token (PAT)
- Custom
- No authentication
Since Connector Builder ties into the Integration Service framework, defining your authentication setup is now a matter of configuration rather than a complex process. This means that the framework deals with token exchanges, refreshes, and any other such tasks. Connector Builder defaults to OAuth 2.0 Authorization code, since this is the most common vendor approach to handle authentication.
The authentication page is made out of three components:
-
The Authentication type, which drives how the authentication framework reflects with additional validation for PKCE, full token exchange (for OAuth), etc. In addition, it also reconfigures the table with properties underneath so that the required properties are outlined.
- The properties table can be modified with custom parameters and/or editing existing ones. Depending on the Authentication type selection in the drop-down menu, some fields might be mandatory and specified in red.
Note: Changing these properties within this table or the Authentication type invalidates the connection you might have already created within Connector Builder. There is only one connection during design time, and it needs to be set up and tested against the latest authentication configuration.If you update your authentication settings, existing connections will fail. You must create a new connection and update your processes to use the new connection.
- The Authentication screen is automatically generated based off the configuration you provided. What you see during configuration
within Connector Builder is exactly the end-result that users of your activity package will see.
Disregarding the Authentication type, the loaded properties table identifies two items:
- What the user sees within the authentication screen.
- How authentication is handled by the authentication framework.
- Every line item in the table represents a property that can or can not be overwritten by the user. To present a given field on screen, it needs to be flagged as Ask the user - Yes.
- Every line item has a Name and a Display name. The Name is what the vendor is expecting for the technical setup and the latter is of importance on how to ask this input from the user on the authentication screen.
- Every line item holds an action menu which allows editing the property into far more detail. This is where you can state that a given property needs to be sent as a header. See more examples in the API Key section.
In the Authentication tab, you configure the authentication type for your connector. The following options are supported:
- OAuth 2.0 Authorization code
- OAuth 2.0 Authorization code with PKCE
- OAuth 2.0 Client credentials
- Basic
- API key
- Personal Access Token (PAT)
- Custom
- No authentication
When setting up the authentication, you are configuring how anybody using your connector needs to authenticate. This is you while you are building the connector, but could also be others that end up using your creation.
Overview
OAuth 2.0 authorization code is one of the most commonly used authentication protocols.
Authentication fields
URL fields such as Authorization URL and Token URL do not inherit the base URL from the connector and require the entire URL. This allows for use cases where a provider uses a different base URL for authentication than that of the rest of the API.
Required fields
Field | Description |
---|---|
Client ID | Provider-generated application identifier. |
Client secret | Provider-generated application secret key. |
Authorization URL | URL that redirects the user to complete the authentication process. Returns a authorization code. |
Token URL | URL that UiPath uses to exchange the authorization code for a token. |
Additional fields
Field | Description |
---|---|
Scope | Add necessary scopes for a connector with a
space separating each scope (i.e., read
write openid ).
|
Refresh token URL | URL needed to generate a new access token if a refresh token is also returned. This is often the same URL that is used for Token URL. |
Token Revoke URL | URL needed to revoke the access token. |
Refresh interval | How long the access token is valid. The default value is 3600 seconds or 60 minutes. |
Connection name | The name of the connection in UiPath once authentication is completed. |
Basic Header | Indicates whether the client ID and secret
are sent as a Base64-encoded value in the
Authorization header. Boolean
value (true/false); default is true.
|
How it works
Once all the field values are added or configured for the connector, UiPath® automatically guides you through the necessary steps to complete the authentication flow. UiPath supports the protocol and, if provided with a Refresh token URI, automatically regenerates access tokens in the background as needed. This keeps the connection alive and functional for as long as the underlying refresh token is valid.
Post-authorization request format
After the initial configuration is complete and a connection is made, all requests made for that connector have the authorization header automatically included in the request.curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {yourToken}'
curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer {yourToken}'
Overview
OAuth 2.0 authentication code with PKCE (Proof Key for Code Exchange) is a common authentication protocol that is leveraged largely by single page applications, applications that cannot securely store a Client Secret or applications that cannot ensure secure retrieval of an authorization code.
Authentication fields
URL fields such as Authorization URL and Token URL do not inherit the base URL from the connector and require the entire URL. This allows for use cases where a provider uses a different base URL for authentication than that of the rest of the API.
Required fields
Field | Description |
---|---|
Client ID | Provider-generated application identifier. |
Client secret | Provider-generated application secret key. |
Authorization URL | URL that redirects the user to complete the authentication process. Returns a authorization code. |
Token URL | URL that UiPath uses to exchange the authorization code for a token. |
Additional fields
Field | Description |
---|---|
Scope | Add necessary scopes for a connector with a space separating
each scope (i.e., read write openid ).
|
Refresh token URL | URL needed to generate a new access token if a refresh token is also returned. This is often the same URL that is used for Token URL. |
OAuth2 PKCE Code Challenge Method | The method used to generate the challenge. Can be either
S256 or plain
(recommended: S256 ).
|
Token Revoke URL | URL needed to revoke the access token. |
Refresh interval | How long the access token is valid. The default value is 3600 seconds or 60 minutes. |
Connection name | The name of the connection in UiPath once authentication is completed. |
Basic Header | Indicates whether the client ID and secret are sent as a
Base64-encoded value in the Authorization
header. Boolean value (true/false); default is true.
|
How it works
Once all the field values are added or configured for the connector, UiPath® automatically you through the necessary steps to complete the authentication flow. UiPath supports the protocol and, if provided with a Refresh token URI, automatically regenerates access tokens in the background as needed. This keeps the connection alive and functional for as long as the underlying refresh token is valid.
UiPath supplies the challenge string necessary for PKCE based authorization, only the OAuth2 PKCE Code Challenge Method is required.
Post-authorization request format
curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json'
--header 'Authorization: Bearer {yourToken}',
curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json'
--header 'Authorization: Bearer {yourToken}',
Overview
OAuth 2.0 client credentials is a method for returning an access token granting access to protected resources using application specific credentials which grant the permission necessary. Client credentials are often used for machine-to-machine (M2M) applications and are not usually representative of user permissions.
Authentication fields
URL fields such as Token URL do not inherit the base URL from the connector and require the entire URL. This allows for use cases where a provider uses a different base URL for authentication than that of the rest of the API.
Required fields
Field | Description |
---|---|
Client ID | Provider-generated application identifier. |
Client secret | Provider-generated application secret key. |
Token URL | URL used to retrieve the access token. |
Additional fields
Field | Description |
---|---|
Scope | Add necessary scopes for a connector with a space separating each scope (i.e., read write openid ).
|
Refresh interval | How long the access token is valid. The default value is 3600 seconds or 60 minutes. |
Connection name | The name of the connection in UiPath once authentication is completed. |
Basic Header | Indicates whether the client ID and secret are sent as a Base64-encoded value in the Authorization header. Boolean value (true/false); default is true.
|
How it works
Once all the field values are added or configured for the connector UiPath® generates an authorization request, passing through the necessary credentials to generate an access token. Since OAuth 2.0 client credentials is meant for M2M applications, you only see the initial UiPath authorization page and will have no further redirects.
Once a successful authorization flow is detected, UiPath maintains the connection as long as the provided credentials are valid.
Post-authorization request format
curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json'
--header 'Authorization: Bearer {yourToken}',
curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json'
--header 'Authorization: Bearer {yourToken}',
Overview
Basic
. The username and
password, which can be modified, are used in all connector requests as the value for
the Authorization header.
Authentication fields
Field | Description |
---|---|
Username | The first value in the two-part colon delineated and
Base64-encoded Authorization header value.
|
Password | The second value in the two-part colon delineated and
Base64-encoded Authorization header value.
|
Connection name | The name of the connection in UiPath once authentication is completed. |
How it works
Basic
to generate an Authorization
header
value (e.g. Authorization: Basic base64(username:password)
). This
header value is passed into each request as a means of authentication.
Post-authorization request format
curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json'
--header 'Authorization: Basic base64(username:password)'
curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json'
--header 'Authorization: Basic base64(username:password)'
Overview
'X-Acess-Token: <provider_api_key>'
header that is passed into connector requests.
Authentication fields
Field | Description |
---|---|
API key | The API key generated from the API provider to be used as the value for the X-Access-Token header on all connector requests.
|
Connection mame | The name of the connection in UiPath once authentication is completed |
How it works
When you use the provider-generated API key value for the API Key parameter in Settings- Authentication, every request made for that connector includes anX-Access-Token
header with the API key provided as the header value.
Post-authorization request format
X-Access-Token
header automatically included in the request.curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json'
--header 'X-Access-Token: {yourtoken}'
curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json'
--header 'X-Access-Token: {yourtoken}'
Overview
Authorization:
{access_token}
header pattern for authenticating requests. The PAT
authentication method allows you to provide the necessary access token and applies
the headers previously listed but does not maintain the access token if it expires
at any point.
Authentication fields
Field | Description |
---|---|
Personal access token | The provider-generated access token to be used as a value in
the Authorization header field on all connector
requests. Field defaults to prefix the token with
Bearer to accommodate the common bearer
authentication pattern.
|
Connection name | The name of the connection in UiPath once authentication is completed. |
How it works
Personal Access
Token parameter in Settings- Authentication, every request made for that
connector includes an X-Access-Token
header with the Personal
access token provided as the header value.
Post-authorization request format
Authorization
header automatically
included in the
request.curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json'
--header 'Authorization: {personal_access_token}'
curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json'
--header 'Authorization: {personal_access_token}'
Overview
Custom authentication should be used when the vendor configuration does not follow any of the standards but does require authentication details to be exchanged and sent on every request.
Authentication fields
Authorization
parameter as an example field but can be customized to match the authentication
patterns of the API provider.
Any parameters added to the authentication from Custom authentication apply to the connector's requests.
How it works
Parameters added to the authentication section are automatically included in any connector requests.
The No authentication option provides a quick selection from the listing and deletes all properties from the authentication configuration table.
How to use it
Use this option if the vendor application you are connecting to is available without having to sign in. This can be an online public service or an API that is exposed internally within the company. It requires no headers to be sent on any requests identifying who is making the API call.
curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json'
curl --request GET \
--url https://{baseUrl}/{resource} \
--header 'Accept: application/json' \
--header 'Content-Type: application/json'