Accounts
An account holds the connection details and credentials of an external system: the Xurrent account your integration works with, an HTTP API, a database, an SFTP server, and so on. Packages do not contain hostnames, tokens or passwords. They reach external systems through an account, referenced by name.
Because packages refer to accounts by name, a package transferred from a test environment to production keeps working as long as an account with the same name exists there, pointing at the production system.
Account types
Accounts are configured in the Accounts tab. The account type determines which functions can use the account:
- Xurrent: the Xurrent REST and GraphQL functions, and auto-fetch.
- HTTP: the HTTP and REST functions.
- SOAP XML webservice: the SOAP functions.
- Microsoft Graph: the HTTP functions, authenticated against Microsoft 365.
- Amazon AWS (SDK): the AWS functions.
- MySQL: the database functions.
- Microsoft SQL Server: the database functions.
- SSH/SFTP: the SFTP functions.
- File repository: the file repository functions.
- Proxy: the proxy functions, see the Proxy section.
The authentication options depend on the account type. HTTP accounts, for example, support basic authentication, bearer tokens, OAuth 2.0, Microsoft Graph, NTLM, client certificates and custom headers or URL parameters.
The default account
Every trigger links a package to an account. That account is the default account
of the package execution: functions that take an optional account parameter use it when the parameter is omitted. To
work with several systems in one package, pass the name of another account explicitly.
Package code can inspect the default account with getAccountInfo.
Usage
The automator records how each account is used: the number of calls, the limit hits, the time spent waiting on rate limits and the errors. The usage is shown on the Usage tab of an account, see Account usage.