The Argyle API is built on RESTful principles. It returns JSON encoded-responses and accepts JSON payloads. This data is only available through HTTPS to ensure the security of the data being transferred.
You can view all the latest updates to the Argyle API—including any new data fields added—in the API Changelog
The Argyle API should only be invoked from your own server-side applications in order to protect your credentials from being revealed on the client-side.
The Argyle API uses HTTP Basic Auth. The username is api_key_id and the password is api_key_secret.
api_key_id and api_key_secret can be retrieved via the Argyle Console.
If invalid credentials are provided, a 401 Unauthorized response code will be returned with the corresponding JSON body.
Different credentials are to be used for different environments. If credentials for the wrong environment are used, a 401 Unauthorized response code will be returned with the corresponding JSON body.
The API should only be invoked from your own server-side applications in order to protect your credentials from being revealed on the client-side.
Argyle API operates in two separate environments: production and sandbox.
The sandbox environment returns mock data and is designed for testing the basic functionality of the API. The production environment lets retrieve data from real accounts connected via Argyle Link.
The Sandbox environment operates only with a set of sandbox credentials provided here and in the Link Emulator.
You can link the sandbox accounts through Argyle Console via the Emulator tab or through your own instance of Argyle Link. In order to connect sandbox accounts via Argyle Link, you have to set the apiHost to point to the sandbox API endpoint. You can find more information on how to configure Link here.
Within the Sandbox environment, Argyle provides two slightly different data sets:
When running in a Sandbox environment, you can connect work accounts with the provided sandbox credentials only.
Make sure to select the appropriate credential items. For example, Walmart requires username and password, while Uber requires email and password.
Follow these best practices to secure your API keys:
In case of an error, an appropriate HTTP response code is sent. The JSON object in the response body will contain a single key detail
that will have a description of an error.
Error code | Description |
---|---|
200 - OK | Everything worked as expected. |
201 - Created | Resource has been created. |
204 - No Content | Operation has been accepted and no content in response has been sent. |
400 - Bad Request | The request was unacceptable, often due to missing required parameter. |
401 - Unauthorized | No valid API key provided. |
402 - Request Failed | The parameters were valid but the request failed. |
403 - Forbidden | The API key doesn't have permissions to perform the request. |
404 - Not Found | The requested resource doesn't exist. |
409 - Conflict | Arguments in the request are in conflict with the server state. |
429 - Too Many Requests | Too many requests hit the API too quickly. We recommend an exponential backoff of your requests. |
500, 502, 503, 504 - Server Errors | Something went wrong on Argyle's end. (These are rare.) |
If there is a field validation problem in a POST request, the response JSON object will contain all of the fields and their corresponding validation errors.
Sometimes in the API call response, you will see null
as the returned value for a given field. This might happen for one of two reasons:
All top-level API resources have support for bulk fetches via "list" API methods. For instance, you can list payouts, list documents, etc.
Each of the responses will have next
and previous
page URLs provided for easier querying of the next and previous results pages. You can use the limit
parameter to define the number of results on a page.
When retrieving resources in bulk, make sure to follow the next
and previous
page URLs to avoid retrieving the same resource multiple times and eliminate redundant calls. Following the URLs means no two requests can happen in parallel — this is by design as it helps to avoid 429 rate limiting responses and retrieving the data can be done in a much more efficient stream-like manner.
In case you want to achieve more throughput, try utilizing concurrency by fetching data from multiple users in parallel.
The Argyle API employs a number of safeguards against bursts of incoming traffic to help maximize its stability. If you send many requests in quick succession you may see error responses that show up as status code 429
(Too Many Requests). In this case, you need to put that request back into a queue to retry with an exponential backoff
The Argyle API allows a rate of 50 RPS (requests per second).
Running a large volume of closely-spaced requests can lead to rate limiting. Often this can occur as part of an analytical or a migration operation.
You should limit the number of concurrent requests that are in-flight at once. Limiting the number of users that are being processed at once will make sure that users are synchronized fully before starting to process another user.
When fetching data from multiple services or multiple instances of the same service, try to avoid repeating the same queries. This can be done with a caching layer between your program and Argyle API. Argyle doesn't do HTTP caching to ensure the data being retrieved is up-to-date.
Webhooks provide means for Argyle to communicate to your servers when specific events happen: like when an account was successfully connected, new payouts were added, etc.
To start receiving webhooks, you need to build a web application, with a publicly accessible URL. Use that URL to create a webhook subscription.
After subscribing to a webhook, you will get a POST request with the event payload, that will contain information about the event that has been triggered.
For more information, please refer to the Webhooks Guide and the Webhooks Reference.
An array of Argyle's webhook event types (e.g., ["activities.added"])
. Refer to the webhooks reference for a full list of available event types.
Configuration options of the webhook. Refer to the webhooks reference to learn more about available configuration parameters.
Creates a new webhook.
POST /webhooks
An array of Argyle webhook event types. Specify ['*']
to subscribe to all webhook events.
Configuration options of the webhook. Refer to the webhooks reference to learn more about available configuration parameters.
The webhook object created.
Link items are companies and platforms that a user can select in Argyle Link when they are connecting to their work account. The full list of Link items can be found here.
Link items were previously referred to as data partners, which have been deprecated.
Provides information on the health of a particular Link item. The healthy
value indicates successful account connections. When Argyle’s data partners are experiencing issues and connections are not successful or partially degraded, the value will be issues
. In this case, the status_details
field can be used to provide additional information about the Link item’s status.
Possible values: healthy
, issues
.
Contains information about pay distribution bank account update capabilities of a given Link item. Please refer to the Pay Distribution Guide for more information.
Denotes the level of granularity of the pay distribution percentage for bank accounts. This way you can define the percentage of the pay distribution with up to the 4 decimal places.
Possible values: 100
, 10
, 1
, 0.1
, 0.01
, 0.001
, 0.0001
.
Lists string enum values that indicate what types of actions are required by the Link item to make any newly added allocations active for bank accounts.
If no action is required, then an empty list is returned.
Possible values: microdeposit_verification
.
Lists all Link items supported by Argyle.
GET /link-items
An object with a results property that contains an array of Link item objects.
Search for Link items supported by Argyle.
GET /search/link-items
An object with a results property that contains an array of Link item objects.
User objects represent distinct users that have connected their work accounts via Argyle Link.
You can list all users or retrieve a user by ID that you have saved in your database when one of the Argyle Link callbacks was invoked.
Time at which the user was created. Timestamps follow the ISO 8601 standard.
A list of names of employers that the user has connected to via Argyle Link. This list might be different from data_providers_connected
, which can include payroll platforms (for example, MyADP). The connections might be active or previously connected employers, which are no longer active (for example, due to a user switching jobs).
This field is populated after the initial scan is completed and the account is connected successfully, so there is a short (a few seconds) delay before you can see the list. Use the employments webhook to know when this data is available on the platform.
A list of the IDs of Link items that the user has connected. The connections might be active or previously connected Link items, which are no longer active (for example, due to a user switching jobs). This field is populated immediately after user creation.
Create a new user. No payload is required for this request.
When creating a user, you have the option to attach external metadata to that user using the external_metadata
object. This object can be used to attach any external information, such as a customer group identifier. Imagine you have consumer banking and personal lending customers. You can identify customers in these groups by adding a customer group to the external_metadata
object.
If the external_metadata
object is specified in the POST request, the API saves that information, but only returns the id
and token
fields.
Metadata can also be updated with a PATCH request.
POST /users
Returns the new user's id
and an associated user token
.
Retrieve the external_metadata
object associated to a user.
GET /users/:id
Returns the metadata of the specified user.
Update external metadata for an already existing user.
PATCH /users/:id
Returns the user object with the updated external metadata.
Deletes a user and all accounts associated with that user. In turn, all other resources—profiles, vehicles, documents, etc.—are deleted as well.
Use this endpoint to delete all information about a user. If you want to delete a single account of a given user, please refer to the delete an account section.
DELETE /users/:id
On successful user deletion, responds with a 204
status and an empty response body.
User tokens are temporary access keys that ensure Argyle Link user's permissions are scoped to the specified user's data.
User tokens are JWT tokens that contain an expiry date. Refer to the Argyle Link guide for more details.
To create a user token, send a POST
request with the request body containing a JSON object with the following format: {"user": "user-id"}
.
POST /user-tokens
The user token enclosed in a JSON object: {"access": "user-token"}
.
Account objects represent data partner accounts that your users connect to via Argyle Link.
You can query accounts by account
ID or user
ID that you might have obtained through one of the Argyle Link callbacks.
Accounts that have never successfully connected will be removed within 30 days.
ID of the Link item (i.e. company or platform), that the user selected when connecting their account via Argyle Link. This value will oftentimes be human-readable.
link_item
supersedes the now deprecated data_partner
field.
Denotes the source of the account's employment records provided in the Argyle API. Source
value will be the same as link_item
when a company has an in-house solution for managing employment data:
link_item
="uber"
source
="uber"
Or it can be different when a company is utilizing a third-party payroll platform:
link_item
="homedepot"
source
="workday"
Time at which the account was connected. Timestamps follow the ISO 8601 standard.
Time at which the account was updated. Timestamps follow the ISO 8601 standard.
To check an account’s current status
, you can call GET /accounts/:id
and check all relevant details within the accounts.connection
object in the response.
Represents the status of the link between Argyle and the work platform. Possible values:
connecting
– a connection to the Link item is being established. This status only occurs when a user submits their credentials through Argyle Link for a new account or for an existing account.
connected
– account is linked with the Link item. Please note, that this does not mean the data pull has finished. Use the availability
field to check if data has been synced.
error
– the connection to the Link item is not currently live. Argyle is not able to pull data for the account. See connection.error_code
below for details.
Provides information on why the connection failed when connection.status
is error
.
Possible values: account_disabled
, account_inaccessible
, account_incomplete
, auth_required
, expired_credentials
, invalid_account_type
, invalid_auth
, invalid_credentials
, invalid_mfa
, login_attempts_exceeded
, mfa_attempts_exceeded
, mfa_exhausted
, mfa_not_configured
, mfa_timeout
, service_unavailable
, system_error
, tos_required
, trial_period_expired
, unsupported_auth_type
, unsupported_mfa_method
.
Each error_code
has a corresponding error_message
(see below).
Provides additional information on why the connection error occurred. Each error_message
corresponds to a particular error_code
(see above). The list below is formatted as:
error_code
- error_message
Possible values:
account_disabled
- this user's employment account appears to be suspended or disabled.
account_inaccessible
- this user's account is not currently accessible. Our team has been notified and is investigating.
account_incomplete
- this user's employment account is not yet active.
auth_required
- this user's connection has expired and requires re-authentication.
expired_credentials
- this user provided credentials which are out of date (i.e., a password reset is required).
invalid_account_type
- this user provided credentials for the wrong account type (e.g., a passenger account rather than a driver account, or an admin account rather than an employee account).
invalid_auth
- this user's account login was unsuccessful, either due to invalid credentials or unsuccessful multi-factor authentication.
invalid_credentials
- this user provided invalid credentials.
invalid_mfa
- this user did not provide the correct multi-factor authentication response.
login_attempts_exceeded
- this user provided invalid credentials too many times, causing them to be temporarily unable to attempt further logins.
mfa_attempts_exceeded
- this user failed multi-factor authentication too many times, causing them to be unable to attempt further logins until multi-factor authentication method is reset.
mfa_exhausted
- this user failed multi-factor authentication too many times, requiring them to re-authenticate.
mfa_not_configured
- this user has not configured multi-factor authentication for their employment account, restricting access to the user's employment data.
mfa_timeout
- this user did not complete multi-factor authentication.
service_unavailable
- the platform this user is attempting to connect to is currently unavailable. See the Coverage page in Console for additional information.
system_error
- Argyle encountered a problem connecting to this account. Our team has been notified and is investigating.
tos_required
- this user has not accepted the Terms of Service presented by their payroll provider, preventing access to their employment account.
trial_period_expired
- this user's employment account is in a trial account, and is currently disabled because the trial period has expired.
unsupported_auth_type
- this user tried to log in using single sign-on (e.g., Google, Facebook), which Argyle does not currently support.
unsupported_mfa_method
- this user's employment account uses a multi-factor authentication method that Argyle does not currently support.
Timestamp denoting the last time connection status was updated. Timestamps follow the ISO 8601 standard.
Denotes the point in the process of the pay distribution update process. Possible values:
idle
- pay distribution update process has not been initiated.
awaiting_confirmation
- waiting for the user to confirm updated pay distribution.
awaiting_connection
- waiting to establish connection to the user's employment account.
scanning
- scanning existing pay allocations prior to update process.
updating
- updating the user's pay distribution.
success
- pay distribution update successful.
error
– pay distribution update unsuccessful. See the pay_distribution.error_code
below for details.
Provides information on why the pay distribution update was unsuccessful when pay_distribution.status
is error
.
Possible values: confirmation_timeout
, incompatible_config
, invalid_mfa
, mfa_exhausted
, mfa_not_configured
, mfa_timeout
, missing_allocation_type
, not_supported
, not_supported_by_employer
, rejected_bank_account
, rejected_routing_number
, service_unavailable
, system_error
, unsupported_allocation_type
, unsupported_bank_accounts
, unsupported_mfa_method
, waiting_period
.
Each error_code
has a corresponding error_message
(see below).
Provides additional information on why the pay distribution update error occurred. Each error_message
corresponds to a particular error_code
(see above). The list below is formatted as:
error_code
- error_message
Possible values:
confirmation_timeout
- this user did not finish setting up their new pay distribution.
incompatible_config
- the pay allocation details that have been submitted are not supported by this user's employment account.
invalid_mfa
- this user did not provide the correct multi-factor authentication response.
mfa_exhausted
- this user failed multi-factor authentication too many times, requiring them to re-authenticate.
mfa_not_configured
- this user has not configured multi-factor authentication for their employment account, restricting access to the user's employment data.
mfa_timeout
- this user did not complete multi-factor authentication.
missing_allocation_type
- one or more of this account's pay allocations is missing a type (percent/amount/remainder), causing Argyle to be unable to update the user's pay distribution information.
not_supported
- this user's employment account does not support updating pay distribution information.
not_supported_by_employer
- this user's employment account does not support changes to pay distribution information. This may be because the employer has disabled users from editing this information.
rejected_bank_account
- the provided bank account cannot be used for pay distribution update. Please provide a different bank account.
rejected_routing_number
- the provided routing number is considered invalid by this user's employment account.
service_unavailable
- this user's employment platform is experiencing downtime and is currently unable to process updates to pay allocations.
system_error
- Argyle encountered a problem when reading or updating pay distribution information. Our team has been notified and is investigating.
unsupported_allocation_type
- one or more of this account's pay allocations is not currently supported, causing Argyle to be unable to update the user's pay distribution information. Supported allocation types are percent, amount and remainder.
unsupported_bank_accounts
- this user's employment account includes pay allocations to bank account types that Argyle does not yet support, like HSAs.
unsupported_mfa_method
- this user's employment account uses a multi-factor authentication method that Argyle does not currently support.
waiting_period
- pay distribution update is temporarily unavailable. This can happen when an employer requires a waiting period after recent pay distribution updates or after initial account creation.
Timestamp denoting the last time pay distribution was updated. Timestamps follow the ISO 8601 standard.
The availability
object shows the synchronization status
and the updated_at
fields for each data resource (e.g., documents, vehicles, payouts, etc.) within the account. Event data resources (e.g. payouts, activities) have additional information pertaining to event count and availability timeframe.
pay_allocations
availability will only be present if your Argyle account has pay distribution updating enabled. Additionally, if pay distribution updating is enabled, but the pay allocation resource is not available within the Link item platform, then pay_allocations
will be null
.
For more information on data synchronization, please refer to Gradual Data Delivery.
Denotes the status of the data scan. Possible values:
in_progress
- initial data pull is in progress.
synced
- data is synced as of the time indicated in the updated_at
field.
sync_failed
- data pull failed. Please refer to connection.error_code
to troubleshoot potential problems.
Timestamp of the last data scan. Timestamps follow the ISO 8601 standard.
Denotes the end point of the time interval, for which the events (e.g. activities, payouts) are available. Timestamps follow the ISO 8601 standard.
During the first scan of an account, the value of this field will change with each scanning iteration until the availability.status
becomes synced
.
Denotes the start point of the time interval, for which the events (e.g. activities, payouts) are available. Timestamps follow the ISO 8601 standard.
During the first scan of an account, the value of this field will change with each scanning iteration until the availability.status
becomes synced
.
List all accounts that your customers have connected through Argyle.
GET /accounts
An object with a results
property that contains an array of up to limit
account objects.
Deletes an account and all resources associated with that account: profiles, vehicles, documents, incomes etc.
DELETE /accounts/:id
On successful account deletion, responds with a 204
status and an empty response body.
Argyle introduced forms
to surface questions and prompts to users and capture their inputs in various scenarios such as:
In either of these situations, users will be given the option to fill out an Argyle form. Forms may include free-text fields, drop-down selections or document upload prompts. The Link Customizer can be used to configure certain aspects of the Argyle forms to better meet your needs and your customers' expectations.
As the form framework evolves, additional field types and enhanced levels of customization will be made available.
If the document upload flow is enabled in the Link Customizer, the uploaded documents will be returned as a form object with the data fields described below. Refer to the Document Upload guide for more details.
If the document upload flow is disabled in the Link Customizer and the user clicks the Can't find your employer? button in Link, then they will be asked to submit their employer name and select the associated payroll platform (if available). The answers to these questions will be returned as a form
object with the data fields described below
The questionnaire is enabled by default in Link. It can be disabled via the Link Customizer.
Retrieve all forms associated with an account.
GET /forms/:account
An object with a results property that contains an array of all the form objects associated with the provided account ID.
User invites represent the invitations sent to a user's email or phone. You can customize parts of the text message, email, and landing page by utilizing the /user-invite-templates endpoint.
Denotes the time when the invitation was sent out. This field is updated if you resend an invite.
Sends out an invite to a user's email and/or phone. If both email
and phone_number
are provided, then both an email and a text message will be sent. If only one of them is provided, then only the corresponding action will be executed.
POST /user-invites
Allows you to customize Argyle Link UI that your users will see when they connect their employment accounts. Check here how to customize the Link and obtain the customization_id
through Link Customizer.
Allows you to configure your pay distribution. See all available parameters in the Pay Distribution configuration section.
Deprecated in favor of customization_id
.
Use this parameter to limit the number of Link items that your users can connect to. Provide an array of Link item IDs you want Argyle Link to display in the company selection screen. The order in which you list the IDs will define the order in which they are displayed in the UI.
If you provide a single Link item ID, the company selection screen will be skipped and the user will be navigated directly to the Link item login screen.
Deprecated in favor of customization_id
.
When set to true
, only Link items that support pay distribution will be shown. For more information on changing pay distributions, please refer to the Pay Distribution Guide.
If a payDistributionConfig
is provided, then only the Link items that match the parameters in the config will be shown. For example, if the payDistributionConfig
allows only amount allocations and a Link item supports percent allocations only, then that Link item will not be shown.
If no payDistributionConfig
is provided then all Link items that have some pay distribution support (amount and/or percent) will be shown.
The default value is false
.
Returns the user invite object with status
= invited
.
When using the /user-invites endpoint, the invite template allows you to customize the following elements:
The call-to-action button label on the landing page to initiate Argyle Link.
Creates a new invite template with the provided attributes.
The following placeholders can be used in the text contents. They will be replaced by the following values:
[Company]
- corresponds to the company
attribute in the user invite template object.[Name]
- corresponds to the full_name
attribute in the user invite object.[Link]
- shortened link to accept the invitation.[Sender]
- corresponds to the sender attribute in the user invite template object.POST /user-invite-templates
The call-to-action button label on the landing page to initiate Argyle Link.
The response will show all your provided template attributes and a unique template ID.
Returns the list of existing templates.
GET /user-invite-templates
An object with a results
property that contains an array of up to limit
user invite template objects.
Profile objects contain information related to the identity of the user: name, address, contact details, etc. The data in a profile is tied to a particular data partner account that the user has connected to via Argyle Link.
Phone number. Value is returned in the E.164 international phone number format.
Date of birth. Timestamps follow the ISO 8601 standard.
In some rare cases, the Link item platform will obfuscate the birth year and the returned value will be formatted with having a dash instead of the year number: --01-20
.
Two-letter country code returned in the ISO 3166-1 alpha-2 format.
Deprecated in favor of employments.hire_datetime
.
An array of dates when the user was hired with respect to this particular profile. Timestamps follow the ISO 8601 standard.
Deprecated in favor of employments.termination_datetime
.
Date of the termination event. Timestamps follow the ISO 8601 standard.
Lists profile objects.
GET /profiles
An object with a results
property that contains an array of up to limit
profile objects.
Employment objects contain information related to the employment information of the user: employment status and type, hire and termination dates, etc. The data in an employment object is tied to a particular data partner account that the user has connected to via Argyle Link.
The date when the user was hired by the employer
. Timestamps follow the ISO 8601 standard.
The date when the user's employment was terminated by the employer
. Timestamps follow the ISO 8601 standard.
Lists employment objects.
GET /employments
An object with a results
property that contains an array of up to limit
employment objects.
Payout objects contain aggregate payouts data.
Timestamp representing the payout execution date. Timestamps follow the ISO 8601 standard.
The start date of the work period for which the payout was executed. Timestamps follow the ISO 8601 standard.
The end date of the work period for which the payout was executed. Timestamps follow the ISO 8601 standard.
Currency of the payout (e.g., EUR, USD). Currencies follow the ISO 4217 format.
Two-letter country code returned in the ISO 3166-1 alpha-2 format.
The location of the filing status will correspond to filing_status.type
.
For filing_status.type
= federal
, a null
value will be returned.
For filing_status.type
= state
, the value could be the name a state name ("Virginia"), state code ("VA"), or similar
For filing_status.type
= local
, the value could be a city name ("New Orleans"), an area code (for example, "395"), or similar.
Lists all payouts ordered by payout_date
, from newest to oldest.
GET /payouts
The timestamp the payouts should be retrieved from. The following formats are accepted:
2019-01-01
2019-01-01T07:30:00Z
2019-01-01T07:30:00+02:00
If an exact time is not provided, the value will be set to 00:00:00+00:00
– midnight in UTC.
An object with a results
property that contains an array of up to limit
payouts objects.
Document objects contain information related to a user's identifying documents associated with a particular data partner account.
The expiration date of the document. Timestamps follow the ISO 8601 standard.
Lists all documents.
GET /documents
An object with a results
property that contains an array of up to limit
document objects.
Report objects contains information related to the various reports generated for users, which includes Verification of Income and Employment (VOIE) reports. The reports are generated on request based on the data received from payroll platforms.
Generates a report, including of type
= VOIE
for a selected user
.
POST /reports/generate
Returns a report object if a valid user was provided.
An activity is a single unit of work performed by a user at a company.
An activity object may represent a single task, as a shift, a job, or a batch of tasks depending on the company.
ID of the Link item (i.e. company or platform), that the user selected when connecting their account via Argyle Link. This value will oftentimes be human-readable.
link_item
supersedes the now deprecated data_partner
field.
The number of tasks performed. Will contain 1 if the activity object represents a single job (e.g. a shift or trip). Will be 2 or more if the object represents an aggregate of tasks performed between start_datetime and end_datetime. It will contain null if the number of tasks performed is not known. This will be the case for companies that only provide aggregate data.
Timestamp representing the start of the activity. Timestamps follow the ISO 8601 standard.
Timestamp representing the end of the activity. Timestamps follow the ISO 8601 standard.
The various timestamps of events inside of the activity. E.g.,* *shift_start
, shift_end
, break_start
, break_end
, task_start
, task_end
, pickup_at
, dropoff_at
, request_at
, cancelled_at
.
The formatting of all_timestamps
can vary depending on the data partner. See all_datetimes
below for values formatted according to the ISO 8601 standard.
Same attributes as in all_timestamps
but all timestamps are converted to the ISO 8601 standard.
The timezone of the activity. A list of possible time zone values is maintained at the IANA Time Zone Database.
The reason for specific earning. Not all earnings are due to activities. Some are just bonuses after the fact, some are incentives to work on peak hours, etc. Possible values:
offer
- not yet completed earning, but a promise to get money when work is completed.work
- earning for completed work.incentive
- incentive to work odd hours, etc.adjustment
- additional earning after the work (for example, to meet minimum wage).other
- any other value that doesn't fit in the above (for example, might be a work-related product purchase provided to the user by the company that is subtracted from the user's earnings).Currency the income was received in (e.g. USD, EUR). Currencies follow the ISO 4217 format.
Total amount received for this activity by a user: the sum of pay, tips, and bonus.
List all activities ordered by start_date
. Filter them by date range, account, or user ID. Either account
or user
is required to list activities.
GET /activities
The timestamp the activities should be retrieved from. The following subset of the ISO 8601 standard formats are accepted:
YYYY-MM-DD
YYYY-MM-DDThh:mm:ssZ
YYYY-MM-DDThh:mm:ssZ±hh:mm
If an exact time is not provided, the value will be set to 00:00:00+00:00
– midnight in UTC.
The timestamp the activities should be retrieved to. The formatting follows the same subset of the ISO 8601 standard as in from_start_date
.
An object with a results
property that contains an array of up to limit
activities objects.
Vehicle objects contain vehicle information related to a particular data partner account.
Lists all vehicles.
GET /vehicles
An object with a results
property that contains an array of up to limit
vehicle objects.
Reputation objects contain information related to the performance metrics of the user within a particular account.
A normalized average rating for all activities performed. Will contain a value between 0 and 5.
This value is only available as an average for the user. Activity level ratings are very rarely exposed in Link item platforms and are thus unavailable.
Lists all reputation objects which are registered in Argyle.
GET /reputations
An object with a results
property that contains an array of up to limit
reputation objects.
The Finances endpoint has been deprecated as of June 10, 2021.
Finance objects contain data about a user's finances.
Lists all finance objects which are registered in Argyle.
GET /finances
An object with a results
property that contains an array of up to limit
finance objects.
A pay distribution can have one or more pay allocation objects, which contain information like bank account details, card details, allocation type, and allocation values. Please refer to the Pay Distribution Guide for more information.
Argyle retrieves data a user has access to in their payroll portal. Some employers and payroll platforms can fully or partially obfuscate pay distribution information (e.g. account or routing number). In these cases, Argyle is only able to return the obfuscated values.
Argyle does not store full card.card_number
details.
If a pay allocation is for a linked payout card, then the bank_account
object returns with all its fields (routing_number
, account_number
, and account_type
) set to null
.
Shows details for the payment card used in the pay allocation.
Argyle is PCI DSS Level 2 compliant. Learn more about security and compliance at Argyle here.
The fields within card
are populated when you have configured card pay allocation and your user has linked card details. Until then, the card
object appears in pay-allocations
, but all fields (card_number
, card_name
, and is_platform_card
) return null
.
Platform card numbers are not usually exposed in the platform. When a card number is not exposed, a fully-obfuscated card number is returned.
Account status in the employment record source.
An active
status signifies that a pay allocation is active in the payroll platform and money will be deposited to it during a payout.
An inactive
status signifies that a pay allocation is not active in the payroll platform and money will not be deposited to it during a payout.
A pending
status signifies that the pay allocation was changed in Argyle Link, but is not yet propagated within the company or payroll (Link item) platform.
A needs_confirmation
status signifies that a microdeposit verification is required.
Possible values: active
, inactive
, pending
, needs_confirmation
.
Allocation fields do not apply to payout cards. If a pay allocation is for a linked payout card, then allocation_type
and allocation_value
will return null
.
Retrieves a pay allocation object with the supplied ID.
GET /pay-allocations/:id
Retrieves a pay allocation object if a valid identifier was provided.
This field shows the available actions for the retrieved pay allocation. Currently, the only possible action is microdeposit verification when actions
contains the deposit
value.
List all pay allocation objects.
GET /pay-allocations
An object with a results
property that contains an array of up to limit
pay allocation objects.
Removes a pay allocation object with the supplied ID. Learn more about removing pay allocations here.
Removing a pay allocation will change the remaining allocations within an account. Please familiarize yourself with and follow the post-removal procedure.
POST /pay-allocations/:id/remove
Removes a pay allocation object if a valid identifier was provided.
Use this endpoint to submit a microdeposit verification value.
POST /v1/pay-allocations/:id/activate
Removes a pay allocation object if a valid identifier was provided.
Argyle Link will initiate a pay distribution change process if a pay distribution configuration is provided. Pay distribution configuration describes the desired outcome of that change. Please refer to the Pay Distribution Guide for more information.
The object that contains bank account information for a pay allocation. This object is optional, but you must implement either the bank_account
or card
option in your pd_config
.
If you choose to implement the bank_account
object, you must configure:
bank_account.routing_number
bank_account_.account_number
bank_account.account_type
The allocation type that will be presented to the user by default. Not all employment accounts support both formats. If you select a default that is not supported by the user's employment account, the user will still be able to enter an allocation using the supported format as long as a default value for that format is provided.
Possible values: percent
, amount
.
The default percent value that will be displayed to the user during the pay distribution update process.
percent_allocation.value
is required if percent_allocation
is used in the configuration.
If no percent_allocation
is provided, the user will not be able to enter a percent-based allocation.
The default amount value that will be displayed to the user during the pay distribution update process.
amount_allocation.value
is required if amount_allocation
is used in the configuration.
If no amount_allocation
is provided, the user will not be able to enter an amount-based allocation
If set to true
, users will see a Pay Distribution screen with a single allocation to which their entire net pay is assigned. All previous allocations will be marked as “removed” and will not be visible on the Pay Distribution screen. The user must confirm the change in order to proceed with the action.
Default value is false
.
Setting entire_allocation
to true
has implications on other pay distribution config parameters:
entire_allocation
is set to true
, amount_allocation
and percent_allocation
values cannot be set. default_allocation_type
can still be provided to decide if the suggested pay distribution screen will contain a single amount allocation (i.e., remainder) or a single percent allocation (100%).allow_editing
is ignored because requiring a single allocation should not allow any modifications. No matter what value is set, there will be no Edit button in Link’s suggested pay distribution screen.Card's country of issue in ISO 3166-1 alpha-2 format.
To start the pay distribution update process in Link you must initialize it with the payDistributionConfig
parameter set to an encrypted version of your pay distribution configuration.
The encryption is necessary to ensure your bank account details are never exposed on the front-end. Your full routing and account numbers always appear encrypted on the end user's device.
To encrypt your pay distribution config make a POST
request into pay-distribution-configs/encrypt
with your pay distribution config in the payload.
POST /pay-distribution-configs/encrypt
Returns an encrypted version of the pay distribution config.