Service Types

Service Types lists the configuration fields for all service types available in Services Administration. Each type determines which credentials and settings are required to connect to an external system. Some types also support optional Mutual TLS and SOAP Digital Signature settings.

Authentication services support two modes: Standard uses a named authentication method, and Custom uses a configured authenticator.

Authentication (Standard)

Standard Authentication uses a named authentication method built into the platform. Each type corresponds to a specific protocol or third-party service and provides a fixed set of configuration fields.

OAuth2 JWT Bearer Grant, OAuth2 JWT Client Credential Grant Extended, and OAuth2 Password Grant call the token endpoint for a new token every time the service is called. To cache tokens between calls, use OAuth2 Client Credentials Grant with Enable Token Persistence enabled.

Amazon S3

AWS S3 (Simple Storage Service) is Amazon's scalable object storage service. Use this type when a service reads from or writes to S3 buckets. Requires an AWS access key ID and with the appropriate read or write permissions on the target bucket.

Field	Description
Access Key ID	The identifier for an AWS access key that has read or write permissions on the target S3 bucket.
Secret Access Key	The secret paired with the Access Key ID. Together they authenticate requests to AWS S3.
Region	The AWS region where the target S3 bucket is hosted, for example `us-east-1`. Must match the bucket's actual region. See S3 Express One Zone Regions for a full list.

Azure Blob Storage

Azure Blob Storage is Microsoft's cloud object storage service for unstructured data. Use this type when a service connects to a Blob Storage container. Requires a connection string from the Azure portal with the appropriate access level.

Field	Description
Connection String	The connection string from the Azure portal that grants access to the Blob Storage account. Find it under Access keys in the storage account settings.

Basic Auth

Basic Authentication (Basic Auth) is a standard HTTP authentication scheme. The client sends a Base64-encoded username and password in the Authorization header of every request. Use this type when the target API requires username and password credentials. Because credentials are encoded, not encrypted, use Basic Auth only over HTTPS.

Field	Description
Username	The username sent in the `Authorization: Basic` header of every request.
Password	The password paired with the username.

Supports Mutual TLS.

Bearer Token

Bearer Token authentication sends a static token in the Authorization: Bearer header of every request. The token grants access to the API without additional credential exchange. Use this type when the target API issues long-lived tokens rather than short-lived OAuth grants. Obtain the token from the API provider.

Field	Description
Bearer Token	The static token sent in the `Authorization: Bearer` header of every request. Obtain this token from the API provider.

Supports Mutual TLS.

Canada Post

Canada Post AddressComplete is a postal and address validation API. Use this type when connecting a service to Canada Post for shipping calculations, label generation, or address autocomplete. Requires an API key from Canada Post.

Field	Description
API Key	The API key provided by Canada Post that authenticates requests to their API.

Custom SOAP Header

Custom SOAP Header authentication adds a custom value to the SOAP security header of every outbound request. Use this type when a SOAP API requires a proprietary token or credential format that does not conform to standard WS-Security profiles. The expected header format and content depend on the target API.

Field	Description
SOAP Header	The value added to the SOAP security header of every outbound request. The required format and content depend on the target API.

Supports SOAP Digital Signature and Mutual TLS.

Google Places

Google Places is a Google Maps Platform API that provides location search, address autocomplete, and place details. Use this type when a service connects to the Places API for address validation or location data. Requires a Google API key with the Places API enabled.

Field	Description
API Key	The API key from the Google Cloud Console that authorizes requests to the Places API.

HMAC

HMAC (Hash-based Message Authentication Code) is defined in RFC 2104. It uses a cryptographic hash function and a shared secret key to verify the integrity and authenticity of a request. It proves that a request was signed by a party holding the secret key and has not been altered in transit. Use this type when the target API requires request signing with a shared secret. See HMAC Concepts for more detail.

This service type requires server-side execution. Direct browser or external calls will fail.

Field	Description
HMAC Private Key (Armored)	The private key used to sign outgoing requests. Must be in armored (PEM-encoded) format.

Hyperscience

Hyperscience is an intelligent document processing platform that uses machine learning to extract and classify data from documents. Use this type when a service submits documents to Hyperscience or retrieves extraction results. Requires an API key from the Hyperscience platform.

Field	Description
API Key	The API key from the Hyperscience platform that authenticates requests.

Supports Mutual TLS.

No Authentication

No Authentication connects to endpoints that require no credentials. Use this type for internal services, publicly accessible APIs, or any endpoint where the network layer controls access. No configuration fields are required.

No configuration fields required. Supports SOAP Digital Signature and Mutual TLS.

OAuth2 Grant Types

Unqork supports four OAuth2 grant types. Use the table below to choose the one the target API requires.

Grant Type	Use When	Token Caching
Client Credentials Grant	Server-to-server calls with no end-user involved. The most common choice for API integrations.	Supported (Enable Token Persistence)
JWT Bearer Grant	The target API requires a signed JWT assertion built from a key Creators supply directly.	Not supported
JWT Client Credential Grant Extended	The target API requires both a client credential JWT and an encrypted user authorization header.	Not supported
Password Grant	The target API requires authenticating with a resource owner's username and password. Most modern APIs do not support this type.	Not supported

OAuth2 Client Credentials Grant

The OAuth 2.0 Client Credentials grant type is designed for machine-to-machine integrations where no end-user is involved. The client authenticates directly with the authorization server using its own credentials and receives an access token. Use this type for server-to-server API calls. This is the most common OAuth2 grant type for API integrations and the only OAuth2 type that supports token caching.

Field	Required	Description
URL	Yes	The token endpoint URL provided by the authorization server. Unqork sends client credentials here to obtain an access token.
Client ID	Yes	The client ID assigned by the authorization server that identifies this integration.
Client Secret	Yes	The secret paired with the Client ID. Treat it as a password.
Scope	No	One or more space-separated scopes that define what the access token is authorized to do. Leave blank if the API does not require scopes.
Send Client ID/Secret in Body instead of Header	—	When checked, this setting sends the Client ID and Client Secret in the request body instead of the `Authorization` header. Some authorization servers require this format.
Perform Authentication Only	—	When checked, this setting stops the service after obtaining the access token and returns the token directly in the response. Use when another service or workflow step needs the token value.
Enable Token Persistence	—	When checked, this setting caches the access token until it expires, reducing calls to the token endpoint. When the token expires, Unqork retrieves a new one automatically.

OAuth2 Client Credentials Grant is the only OAuth2 type that supports Enable Token Persistence.

Supports Mutual TLS.

OAuth2 JWT Bearer Grant

The JWT Bearer grant type (RFC 7523) lets a client obtain an access token by presenting a signed JSON Web Token (JWT) assertion instead of a client secret. The JWT is built from claims and a signing key that Creators configure directly. Use this type when the target API requires a signed JWT assertion and does not support Client Credentials Grant. No end-user session is involved. Token persistence is not supported. A new token is requested on every service call.

This grant type calls the token endpoint for a new token each time the service is called. Token persistence is not supported.

Field	Required	Description
Access Token URL	Yes	The token endpoint URL provided by the authorization server. Unqork sends the signed JWT here to obtain an access token.
Issuer	Yes	The `iss` claim in the JWT payload, typically set to the Client ID assigned by the authorization server.
Subject	Yes	The `sub` claim in the JWT payload identifying the principal for whom the token is requested.
Audience	Yes	The `aud` claim in the JWT payload identifying the authorization server or resource the token targets.
Scope(s) to Access	Yes	The scopes the access token must include, separated by spaces (for example, `read:data write:records`).
Token Expires In (Seconds)	No	How long the signed JWT assertion is valid, in seconds. Defaults to 3600 (60 minutes). The authorization server might enforce a shorter maximum.
Signing Algorithm	Yes	The algorithm used to sign the JWT assertion. The authorization server determines which algorithms it accepts. Common values include `RS256` (RSA with SHA-256) and `HS256` (HMAC with SHA-256). See supported algorithms for the full list.
Shared/Private Key	Yes	The private key or shared secret used to sign the JWT assertion. The format depends on the signing algorithm.
Perform Authentication Only	—	When checked, this setting stops the service after obtaining the access token and returns the token directly in the response. Use when another service or workflow step needs the token value.

Supports Mutual TLS.

OAuth2 JWT Client Credential Grant Extended

This grant type is a specialized extension that combines a client credential JWT with an encrypted user authorization header. Use this type when the target API requires both components for authentication. This is a proprietary pattern found in certain enterprise API platforms. Token persistence is not supported.

This grant type calls the token endpoint for a new token each time the service is called. Token persistence is not supported.

Field	Description
Access Token URL	The token endpoint URL provided by the authorization server.
Client ID	The client ID assigned by the authorization server that identifies this integration.
Module ID	The resource identifier used by the authorization server.
Secret Key for User Authorization JWT Signing	The secret key used to sign user authorization JWTs sent with each request.
Encryption Key for User Authorization Header	The key used to encrypt the user authorization header.
Certificate Pem	The client certificate in PEM format, used for mutual authentication with the authorization server.
Private Key Pem	The private key in PEM format paired with the client certificate.

OAuth2 Password Grant

The OAuth 2.0 Password Grant type authenticates by submitting a resource owner's username and password directly to the authorization server. This grant type is considered legacy and most modern OAuth2 APIs do not support it. Use this type only when the target API explicitly requires it. Prefer Client Credentials Grant for service-to-service calls. Token persistence is not supported.

This grant type calls the token endpoint for a new token each time the service is called. Token persistence is not supported.

Field	Required	Description
Access Token URL	Yes	The token endpoint URL provided by the authorization server. Unqork sends credentials here to obtain an access token.
Client ID	Yes	The client ID assigned by the authorization server that identifies this integration.
Client Secret	Yes	The secret paired with the Client ID. Treat it as a password.
Scope	No	One or more space-separated scopes that define what the access token is authorized to do. Leave blank if the API does not require scopes.
Username	Yes	The username of the account whose credentials are used to authenticate. Belongs to the end-user or service account, not the OAuth2 client.
Password	Yes	The password for the account identified by the Username field.
Send Client ID/Secret in Body instead of Header	—	When checked, this setting sends the Client ID and Client Secret in the request body instead of the `Authorization` header. Some authorization servers require this format.
Send Authentication Body as application/json	—	When checked, this setting sends the authentication body as JSON instead of `application/x-www-form-urlencoded`. Uncommon.
Perform Authentication Only	—	When checked, this setting stops the service after obtaining the access token and returns the token directly in the response. Use when another service or workflow step needs the token value.

Supports Mutual TLS.

OpenID Connect (OIDC)

OpenID Connect is an identity layer built on top of OAuth 2.0 that lets services verify an end-user's identity through an external identity provider. Use this type when a service integrates with an identity provider for end-user authentication flows. OIDC service configuration is handled through the authentication flow; no standard credential fields are required here.

No standard configuration fields. OIDC service configuration is handled through the authentication flow.

Supports Mutual TLS.

Plaid

Plaid is a financial data platform that connects applications to end-users' bank accounts, transaction history, and financial identity. Use this type when a service connects to Plaid to retrieve account data or verify identity. Requires a Client ID and Client Secret from the Plaid Dashboard.

Field	Description
Client ID	The client ID from the Plaid Dashboard that identifies this application.
Public Key	The public key from the Plaid Dashboard used to initialize Plaid Link.
Client Secret	The secret key from the Plaid Dashboard paired with the Client ID. Treat it as a password.
Environment	The Plaid environment that determines which data the integration accesses. Options include: Sandbox, Development, or Production.

Twilio

Twilio is a cloud communications platform that provides APIs for SMS, voice, email, and other messaging channels. Use this type when a service triggers outbound Twilio communications or processes inbound webhooks. Requires an Account SID and Auth Token from the Twilio Console.

Field	Description
Account SID	The Account SID from the Twilio Console that identifies the Twilio account.
Auth Token	The Auth Token from the Twilio Console paired with the Account SID. Treat it as a password.
Number	The Twilio phone number used as the sender for outgoing messages or calls.
Express Domain	The Unqork Express domain that Twilio uses as the callback URL for webhooks and status updates.

WSSE Username Token Profile

The WS-Security UsernameToken Profile is a SOAP security standard that adds an authenticated username and password to the SOAP message header. Use this type when a SOAP API requires WS-Security authentication. Common with older enterprise SOAP services.

Field	Description
Username	The username included in the WS-Security UsernameToken header.
Password	The password paired with the WSSE username. Unqork includes it in the UsernameToken security header.

Supports SOAP Digital Signature and Mutual TLS.

Authentication (Custom)

Custom Authentication is an advanced feature with limited availability. Not all Unqork environments support configured authenticators. Contact the platform team to confirm availability and to configure an authenticator before selecting this type.

Custom Authentication uses a configured authenticator. Select an authenticator from the drop-down; the configuration fields are determined by the selected authenticator. See the authenticator's documentation for field details.

FTP

FTP (File Transfer Protocol) and SFTP (SSH File Transfer Protocol) service types let Creators connect to file transfer servers for reading or writing files. FTP transmits data without encryption. SFTP encrypts the connection using SSH and is the recommended choice for any environment where data privacy is required.

FTP

FTP is an insecure protocol that transmits credentials in plain text. Use SFTP instead whenever possible.

Field	Required	Description
Host	Yes	The hostname or IP address of the FTP server.
Port	No	The FTP server port. Defaults to `21` if left blank.
Username	No	The username for the FTP account.
Password	No	The password for the FTP account.

SFTP

Field	Required	Description
Host	Yes	The hostname or address of the SFTP server.
Username	Yes	The username used to authenticate with the SFTP server.
Password	No	The password for the SFTP account. Leave blank if using SSH key authentication.
SSH Private Key (.pem)	No	The private key used for SSH key authentication. Must be in PEM format. Leave blank if using password authentication.
Private Key Passphrase	No	The passphrase that decrypts the SSH private key, if the key is encrypted. Leave blank for unencrypted keys.

Considerations

SFTP services configured in Services Administration only support specific private key formats.

Supported

PKCS#1 encrypted (-----BEGIN RSA PRIVATE KEY----- with Proc-Type: 4,ENCRYPTED)
PKCS#1 unencrypted (-----BEGIN RSA PRIVATE KEY-----)
OpenSSH encrypted (-----BEGIN OPENSSH PRIVATE KEY-----)
OpenSSH unencrypted (-----BEGIN OPENSSH PRIVATE KEY-----)

Unsupported

PKCS#8 encrypted (-----BEGIN ENCRYPTED PRIVATE KEY-----)
PKCS#8 unencrypted (-----BEGIN PRIVATE KEY-----)

Encryption

GPG (GNU Privacy Guard) service types let Creators encrypt outbound data or decrypt inbound data using asymmetric key pairs. Encryption uses the recipient's public key; decryption uses a private key held by the receiving party. Both types require server-side execution.

Encryption (GPG)

This service type requires server-side execution. Direct browser or external calls will fail.

Field	Description
GPG Public Key (Armored)	The recipient's GPG public key, in ASCII-armored PEM format. Unqork uses this key to encrypt outbound data.

Decryption (GPG)

This service type requires server-side execution. Direct browser or external calls will fail.

Field	Description
GPG Private Key (Armored)	The GPG private key, in ASCII-armored PEM format, used to decrypt inbound data.

Mutual TLS

Mutual TLS (mTLS) extends standard TLS by requiring both the client and server to authenticate with certificates. Where standard TLS only verifies the server's identity, mTLS verifies both parties. It is appropriate for service-to-service communication where strict authentication is required. Mutual TLS is available on most Standard Authentication types. See Mutual TLS Concepts for more detail.

Field		Description
Enable Mutual TLS		When checked, this setting enables mutual TLS for the service.
↳	Certificates	The certificate to use for mutual TLS authentication. Manage certificates in Certificate Management. Visible when Enable Mutual TLS is checked.
↳	Do Not Follow Redirect	When checked, this setting prevents the service from following HTTP redirects. Visible when Enable Mutual TLS is checked.

SOAP Digital Signature

SOAP Digital Signature adds a cryptographic signature to outbound SOAP requests. The signature verifies that the request content has not been altered in transit and confirms the identity of the sender. It is used when integrating with SOAP APIs that require request signing for security. SOAP Digital Signature is available on No Authentication, WSSE Username Token Profile, and Custom SOAP Header service types. See SOAP Digital Signature Concepts for more detail.

Field		Description
Enable SOAP Digital Signature		When checked, this setting enables digital signing for SOAP requests.
↳	PFX or PKCS12 Encoded Private Key and Certificate Chain	The private key and certificate chain in PFX or PKCS12 format, hex encoded. Optional. Visible when Enable SOAP Digital Signature is checked.
	PFX Passphrase	The passphrase for the PFX file. Optional. Visible when Enable SOAP Digital Signature is checked.
	Signing Algorithm	The XML digital signature signing algorithm URI. Optional. Visible when Enable SOAP Digital Signature is checked.
	Digest Algorithm	The XML digital signature digest algorithm URI. Optional. Visible when Enable SOAP Digital Signature is checked.
	Canonicalization Algorithm	The XML canonicalization algorithm URI. Optional. Visible when Enable SOAP Digital Signature is checked.

Changelog

Date	Change
2026-09-04	Editorial pass: replaced bare "user" with "end-user" throughout; fixed "may" to "might" (uncertainty) in Token Expires In field; split long HMAC and SOAP Digital Signature intro sentences; split participial bridge in Mutual TLS section; removed POV violation in Custom Authentication callout.
2026-09-03	Converted Mutual TLS and SOAP Digital Signature tables to DocsHierarchyTable to show parent-child setting relationships; expanded prose for all auth types; added section-level orienting prose for FTP and Encryption sections; added external links; added OAuth2 comparison table; added Custom Authentication availability note.
—	Initial publication.