# Spidr Documentation > Documentation for Spidr Append .md to any documentation page URL to get its markdown version. ## Guides - [Spidr Client Reference Guide](https://docs.gospidr.com/docs/spidr-client-reference-guide.md): This guide provides an overview of Spidr's unified platform: a comprehensive API designed to simplify technical integration and orchestrate data for navigating the complexities of embedded finance. - [Getting Started with Spidr](https://docs.gospidr.com/docs/getting-started-with-spidr.md): The following guide outlines how to start integrating and testing with the Spidr API. It also provides an overview of each environment and prerequisites for access. - [Account and Card Statuses](https://docs.gospidr.com/docs/spidr-card-and-account-statuses.md): This page describes valid statuses and transitions for both Accounts and Cards within the Spidr ecosystem. - [Account And Card Features](https://docs.gospidr.com/docs/account-and-card-features.md): The tables below outline the permissible 'types' and 'values' for the [Edit Account Features](https://docs.gospidr.com/reference/patchv1accountideditaccountfeatures) endpoint. - [Linked Users and Linked Accounts](https://docs.gospidr.com/docs/secondary-accounts-and-shared-balances.md) - [Card Types](https://docs.gospidr.com/docs/card-products.md): Most product configurations with Spidr entail a card. Spidr supports three card types as detailed in the table below. - [Activating Cards](https://docs.gospidr.com/docs/activating-cards.md): This page describes the process for activating cards and protecting cards in transit. - [Setting a PIN](https://docs.gospidr.com/docs/setting-a-pin.md): This page describes the process for setting a PIN - [Replacing and Reissuing Cards](https://docs.gospidr.com/docs/loststolen-and-reissue.md): This page outlines the difference between reissuing and replacing cards and applicable scenarios for each. - [Mobile Wallet Push Provisioning: Integration Guide](https://docs.gospidr.com/docs/mobile-wallets.md): Enable an in-app **"Add to Apple Pay / Google Pay / Samsung Pay"** button, so a cardholder can add their card to a wallet with one tap. - [Physical Card Ordering and Emboss Statuses](https://docs.gospidr.com/docs/physical-card-ordering-and-emboss-statuses.md): This guide explains what your application can observe between ordering a physical card and your customer using it, and which signals to build your card-tracking screens on. - [ACH Accounts and ACH Transactions](https://docs.gospidr.com/docs/ach-accounts-and-transactions.md): This page describes the process for adding ACH accounts and creating ACH originations - [ACH Transaction Statuses](https://docs.gospidr.com/docs/ach-transaction-statuses.md): The following page describes the possible statuses of ACH transactions originated via the [Create ACH Transfer](https://docs.gospidr.com/reference/postv1transactioncreateachtransfer) endpoint. - [Transaction Types & Status Values](https://docs.gospidr.com/docs/transaction-and-activity-types.md) - [Spidr Webhooks](https://docs.gospidr.com/docs/webhook-doc-testing.md) - [Webhook Field Index](https://docs.gospidr.com/docs/webhook-field-index.md): The table below contains a comprehensive list of all fields that appear within Spidr webhooks, along with their description. - [Verifying Webhook Signatures](https://docs.gospidr.com/docs/webhook-signing-and-verification.md) - [RDFs](https://docs.gospidr.com/docs/rdfs.md) - [Spidr Error Codes](https://docs.gospidr.com/docs/spidr-errors.md) - [Round-Up Savings Guide](https://docs.gospidr.com/docs/round-up.md) - [State and Country Code Reference](https://docs.gospidr.com/docs/state-and-country-code-reference.md) - [Spidr ZTM Reference Guide](https://docs.gospidr.com/docs/ztm-reference-guide.md): This guide provides an overview of Spidr's "Zero Touch Monitoring" (ZTM) tool: our proprietary software designed to facilitate fraud and risk oversight at both the customer and transaction levels. Whether you're still in the process of selecting fraud vendors, or you're considering integrating ZTM into your system, feel free to reach out to a Spidr team member for more information and assistance. - [ZTM Integration Guide](https://docs.gospidr.com/docs/ztm-integration-guide.md) - [Linked Institutions](https://docs.gospidr.com/docs/linked-institutions-setup-guide.md) - [SST User Guide](https://docs.gospidr.com/docs/sst-user-guide.md) ## API Reference - [Create User](https://docs.gospidr.com/reference/postv1usercreate.md): Use the ```/user/create``` endpoint to create a new user. This is the first step in establishing a customer relationship with your program. --- πŸ“˜ **Note:** A user record is required before you can create an account. The user should bypass all onboarding checks enforced by your program before creating an account. --- **Things to Note:** - The 'user' is the foundation of all records within Spidr. A user record must exist before an account can be created (the only exception being [anonymous accounts](https://docs.gospidr.com/reference/postv1accountcreateanonymous#/)). - A user can be associated with one or more accounts (see [here](https://docs.gospidr.com/docs/spidr-client-reference-guide#user-vs-account) for example hierarchy). Users may also lack an account based on their onboarding status. - Creating a user first helps you maintain a record of all onboarding attempts and is essential for storing information for fraud prevention and "Know Your Customer" (KYC) processes. - Personally Identifiable Information (PII) is stored at the user level. - [Edit User](https://docs.gospidr.com/reference/patchv1userid.md): Use ```PATCH``` on ```/user``` to edit the user's personal information. This method allows you to update all Personally Identifiable Information (PII) associated with a user. For account-specific updates, please refer to [Edit Account](https://docs.gospidr.com/reference/patchv1accountid). The address tied to a user is the physical address where they reside; the shipping address is stored and managed at the account level. - [List Users](https://docs.gospidr.com/reference/getv1user.md): Use ```/user``` to retrieve a list of users associated with your program. This endpoint returns basic user information including the user id, email, first name, last name, and whether the user is archived. You can specify the number of records per page and fetch a specific page if needed. You can also filter and sort your list by multiple parameters. --- πŸ“˜ **Note:** When specifying filters, you cannot mix account-specific and user-specific identifiers. For example, you cannot filter by both Account Number and First Name. - [Get User Info](https://docs.gospidr.com/reference/getv1userid.md): Use ```GET``` on ```/user``` to retrieve all personal information about a user. This endpoint returns everything about a user _except_ account information. To return user and account information, please use [Get User and Accounts](https://docs.gospidr.com/reference/getv1useriduserandaccounts). - [Archive User](https://docs.gospidr.com/reference/patchv1useridarchiveuser.md): Use ```/archiveUser``` to archive a user. A user can only be archived if **all** their associated accounts are one of the following statuses: - Close_with_refund - Close_without_refund - Close_charged_off To fetch all associated accounts for a user, use [Get User and Accounts](https://docs.gospidr.com/reference/getv1useriduserandaccounts). --- ⚠️ **Warning:** This action cannot be undone. If a user is archived, they must reapply to open another account. - [Create Entity User](https://docs.gospidr.com/reference/postv1entitycreate.md): Use the ```/entity/create``` endpoint to create a new entity (business) user. This endpoint is specifically designed for onboarding business entities rather than individual users. --- πŸ“˜ **Note:** An entity user record is required before you can create a business account. The entity should pass all onboarding checks enforced by your program before creating an account. --- **Things to Note:** - Entity users are identified by their EIN (Employer Identification Number) rather than SSN/ITIN. - Entity users have different required fields than individual users, including entityName and entityDetails. - Beneficial owners can be linked to the entity. Each beneficial owner must be an existing individual (non-anonymous) user. - When beneficial owners are added, they are automatically linked to the entity with a 'beneficial_owner' linkage type. - Beneficial owners are validated to ensure they belong to the same company as the entity being created. - [List Entities](https://docs.gospidr.com/reference/getv1entity.md): Use the ```/entity``` endpoint to retrieve a paginated list of entity (business) users. You can filter by entity name, email, and other entity-specific fields. **Filterable Fields:** - `entityName` - The name of the entity/business - `email` - The entity's email address - `phoneNumber` - The entity's phone number - `isArchived` - Whether the entity is archived - `createdAt` - The date the entity was created - `clientUserId` - Your internal identifier for the entity - `_id` - The entity's unique identifier **Supported Operators:** - `eq` - Equals - `ne` - Not equals - `contains` - Contains (case-insensitive partial match) - `startsWith` - Starts with - `gt`, `gte`, `lt`, `lte` - Comparison operators (useful for dates) - [Retrieve Entity](https://docs.gospidr.com/reference/getv1entityid.md): Use ```/entity/:id``` (GET) to retrieve a single entity by its ID. This endpoint returns full entity details including entity-specific information. **Returned Fields:** - `id` - The entity's unique identifier - `entityName` - The legal name of the entity/business - `email` - The entity's email address - `phoneNumber` - The entity's phone number - `address` - The entity's physical address - `locale` - The entity's locale preference - `isArchived` - Whether the entity is archived - `dateArchived` - When the entity was archived (if applicable) - `archiveReason` - The reason for archiving (if applicable) - `cip` - CIP (Customer Identification Program) status and details - `clientUserId` - Your internal identifier for the entity - `createdAt` - When the entity was created - `idNumber` - The entity's EIN (masked) - `idType` - The type of ID (typically US_EIN for entities) - `linkedUsers` - Users linked to this entity (e.g., beneficial owners) - `entityDetails` - Additional entity information (website, categories, legal structure, beneficial owners, etc.) - [Edit Entity](https://docs.gospidr.com/reference/patchv1entityid.md): Use ```/entity/:id``` (PATCH) to update an existing entity's information. You can update the entity's name, contact information, address, and entity-specific details. --- πŸ“˜ **Note:** Beneficial owners cannot be modified through this endpoint. Use the dedicated beneficial owner endpoints to manage ownership information. --- **Editable Fields:** - `entityName` - The legal name of the entity/business - `email` - The entity's email address - `phoneNumber` - The entity's phone number - `address` - The entity's physical address - `clientUserId` - Your internal identifier for the entity - `locale` - The entity's locale preference - `entityDetails` - Additional entity information (website, categories, legal structure, etc.) **Things to Note:** - The entity's EIN/ID number cannot be changed after creation. - Beneficial owners are managed through separate endpoints. - Changes are tracked in the change history for audit purposes. - [Update Entity CIP Status](https://docs.gospidr.com/reference/patchv1entityidcipstatus.md): Use ```PATCH``` on ```/cipStatus``` to override an entity's CIP (Customer Identification Program) status. This endpoint is an **override, not a setter**: it only changes a status that your program's onboarding flow has already decided. --- ⚠️ **Warning:** Directly editing an entity's CIP status will override the CIP status set by the program. Only call this endpoint for an entity that already has a decided CIP status. --- **Preconditions** - The entity must have a **decided** CIP status of `pass` or `fail`. If `cip.status` is absent or `pend`, the request will return `400` because there is nothing to override yet. - When setting the status to `pass`, every non-archived beneficial owner with `cipRequired` set to true must already have a CIP status of `pass`, otherwise the request is rejected. --- πŸ“˜ **Note:** An entity's CIP status is produced by completing the business's KYB onboarding flow. Use this endpoint only to override an already-decided status, not to force an initial decision. --- **Error Codes** The codes below are not listed in evaluation order. | Error Code | HTTP Status | Description | | --- | --- | --- | | `CIP_NOT_YET_DETERMINED` | 400 | No CIP decision has been reached yet (the CIP status is absent or `pend`), so there is nothing to override. | | `BENEFICIAL_OWNERS_CIP_STATUS_NOT_PASS` | 400 | One or more required beneficial owners do not have a CIP status of `pass`, so the entity cannot be set to `pass`. | | `USER_NOTHING_TO_MODIFY` | 400 | The requested CIP status already matches the entity's current status; there is nothing to update. | | `ENTITY_NOT_FOUND` | 404 | No active entity with this id exists for your program. | - [Archive Entity](https://docs.gospidr.com/reference/patchv1entityidarchiveentity.md): Use ```/entity/:id/archiveEntity``` to archive an entity. An entity can only be archived if **all** their associated accounts are closed. --- πŸ“˜ **Note:** This action cannot be undone. If an entity is archived, they must reapply to open another account. --- **Things to Note:** - All accounts associated with the entity must be closed before archiving. - Beneficial owners linked to the entity will retain their linkage records, but the entity will be marked as archived. - If the entity is enrolled in watchlist screening, the watchlist program will be set to dormant. - [Edit Beneficial Owners](https://docs.gospidr.com/reference/patchv1entityidbeneficialowners.md): Use ```/entity/:id/beneficialOwners``` (PATCH) to manage beneficial owners for an entity. This endpoint supports adding new beneficial owners, editing existing ones, and archiving beneficial owners. **Actions:** Each item in the `beneficialOwners` array must specify an `action` type: - `add` - Add a new beneficial owner to the entity - `edit` - Update an existing beneficial owner's ownership percentage or prong - `archive` - Archive (remove) an existing beneficial owner **Add Action Requirements:** - `userId` - The ID of an existing individual (non-anonymous) user in the same company - `ownershipPercent` - Ownership percentage (0-100) - `prong` - The prong for beneficial ownership (ownership or control) - `cipRequired` - Whether CIP is required for this beneficial owner (defaults to true) **Edit Action Requirements:** - `userId` - The ID of the beneficial owner to edit - `ownershipPercent` (optional) - New ownership percentage - `prong` (optional) - New prong value **Archive Action Requirements:** - `userId` - The ID of the beneficial owner to archive **Things to Note:** - Beneficial owners must be existing individual (non-anonymous) users in the same company - When a beneficial owner is added, a linkage is created on their user record - When a beneficial owner is archived, their linkage is updated with an archive date - Multiple actions can be performed in a single request - [Get User and Accounts](https://docs.gospidr.com/reference/getv1useriduserandaccounts.md): Use ```/userAndAccounts``` to retrieve all information about a user, any other users linked to them, and all of their associated accounts. This endpoint is similar to the [Get Account and Cards](https://docs.gospidr.com/reference/getv1accountidaccountandcards) endpoint. - [Retrieve ID Number](https://docs.gospidr.com/reference/getv1useridretrieveidnumber.md): Use ```/retrieveIdNumber``` to retrieve a user's ID Number. Common ID numbers include SSN and ITIN; your program settings will determine the type of ID returned. To validate an ID Number instead of receiving the full number, use [Verify User's ID Number](https://docs.gospidr.com/reference/postv1useridconfirmidnumber). - [Retrieve ID Number History](https://docs.gospidr.com/reference/getv1useridretrieveidupdatehistory.md): Use ```/retrieveIdNumberHistory``` to retrieve a user's ID Number history. This endpoint returns a list of all updates to a user's ID Number and ID Type, and the date it was updated. - [Edit ID Number](https://docs.gospidr.com/reference/patchv1userideditidnumber.md): Use ```PATCH``` on ```/editIdNumber``` to edit the user's ID Number. ID Number refers to the primary identification method utilized by your program. Common ID Numbers include: - Social Security Number (SSN) - Passport Number - Driver's License Number To retrieve a full ID Number, use [Retrieve ID Number](https://docs.gospidr.com/reference/getv1useridretrieveidnumber) - [Verify User's ID Number](https://docs.gospidr.com/reference/postv1useridconfirmidnumber.md): Use ```/confirmIdNumber``` to validate that a partial ID Number, whether provided by the user or another source, matches the stored record. ID Number refers to the primary identification method utilized by your program. Common ID Numbers include: - Social Security Number (SSN) - Passport Number - Driver's License Number This endpoint allows you to securely validate whether a provided ID Number is valid without revealing or transmitting the full number. This is particularly useful in customer service scenarios for verifying a user's identity, which is why this functionality is also included in [SST](https://docs.gospidr.com/docs/sst-overview). The number of digits required to verify will be variable per your program settings. To retrieve a full ID Number, use [Retrieve ID Number](https://docs.gospidr.com/reference/getv1useridretrieveidnumber) - [Update User CIP Status](https://docs.gospidr.com/reference/patchv1useridcipstatus.md): Use ```PATCH``` on ```/cipStatus``` to override a user's CIP (Customer Identification Program) status. This endpoint is an **override, not a setter**: it only changes a status that your program's onboarding flow has already decided. Please note that a status of `pass` is required before an account can be created for the user. --- ⚠️ **Warning:** Directly editing a user's CIP status will override the CIP status set by the program. Only call this endpoint for a user who already has a decided CIP status. --- **Preconditions** - The user must have a **decided** CIP status of `pass` or `fail`. If `cip.status` is absent or `pend`, the request will return `400` because there is nothing to override yet. - The status can only be changed within **30 days** of the user's `cip.initialStatusDecisionDate`, returned by [Get User and Accounts](https://docs.gospidr.com/reference/getv1useriduserandaccounts). After that window the status is locked and can no longer be updated. --- πŸ“˜ **Note:** To move a sandbox user to a decided status, complete the Plaid sandbox session and wait for the risk decision to land, or approve the pending action in manual review. Do not use this endpoint to force an initial decision. --- **Error Codes** The codes below are not listed in evaluation order. | Error Code | HTTP Status | Description | | --- | --- | --- | | `NOT_ALLOWED_FOR_ANONYMOUS_USER` | 400 | The user is anonymous; this action is not allowed for anonymous users. | | `CIP_NOT_YET_DETERMINED` | 400 | No CIP decision has been reached yet (the CIP status is absent or `pend`), so there is nothing to override. | | `CIP_STATUS_NOT_ELIGIBLE_FOR_UPDATE` | 400 | The CIP status can no longer be updated (more than 30 days since `initialStatusDecisionDate`, or no initial decision date was recorded). | | `USER_NOTHING_TO_MODIFY` | 400 | The requested CIP status already matches the user's current status; there is nothing to update. | | `USER_NOT_FOUND` | 404 | No active user with this id exists for your program. | - [Create Account](https://docs.gospidr.com/reference/postv1accountcreate.md): Use the ```/account/create``` endpoint to create an account for a user. --- πŸ“˜ **Note:** Please note that a user record is required before you can create an account, see [here](https://docs.gospidr.com/reference/postv1usercreate). The user should pass all onboarding checks enforced by your program before an account is created. --- - An account establishes a relationship with the underlying processor and a financial product in your system. - The first account created for a user is treated as their primary account. - A user can have one or more accounts. Each account is tied to a single product. - Account balances can be shared between accounts. **Special Note for Digital-First products**: - If you create an account with a Digital-First product, physical transactions will be blocked by default to protect the card in transit. The digital version of the card is usable immediately (either online or via mobile wallet) upon account creation. - Once the account owner verifies ownership of the card, you can call the [Edit Account Features](https://docs.gospidr.com/reference/patchv1accountideditaccountfeatures) endpoint to lift this block. For more information please see [Card Types](https://docs.gospidr.com/docs/card-products). For guidance on card blocks, please see [Account and Card Features](https://docs.gospidr.com/docs/account-and-card-features). - [Create Anonymous Account](https://docs.gospidr.com/reference/postv1accountcreateanonymous.md): Use the ```/account/createAnonymous``` endpoint to create an anonymous account. You must have an anonymous product configured with Spidr to use this endpoint. --- πŸ“˜ **Note:** Please note that anonymous accounts **do not** require a user by definition. Anonymous accounts do not entail any KYC checks or ZTM integration for KYC. - [Get Account Info](https://docs.gospidr.com/reference/getv1accountid.md): Use ```GET``` on ```/account``` to retrieve details about a specific account. This method returns account metadata, account balance, an array of cards associated with the account, the account status and reason, an indicator of whether it's a primary or secondary account, and list of account features. For more information on account features see '[Account Features](https://docs.gospidr.com/docs/account-and-card-features)'. To edit account features see [here](https://docs.gospidr.com/reference/patchv1accountideditaccountfeatures). - [Edit Account](https://docs.gospidr.com/reference/patchv1accountid.md): Use ```PATCH``` on ```/account``` to edit the account's status or shipping information. You can use the statuses via this method to close an account, mark it as delinquent, return it to an active status, or suspend it. --- πŸ“˜ **Note:** You can edit a user's personal information via ```PATCH``` on ```/user``` [here](https://docs.gospidr.com/reference/patchv1userid). --- As a best practice, use the ```close_without_refund``` status when closing accounts for fraud or compliance-related reasons. Reserve the ```close_with_refund``` status for customers in good standing, as it will issue refunds for any remaining funds. Use ```close_with_refund``` even if the account balance is zero for those customers. **Things to Note:** - Closing an account will also close any associated cards. Please refer to '[Account and Card Statuses](https://docs.gospidr.com/docs/spidr-card-and-account-statuses)' for more info. - ```Close_with_refund```, ```Close_without_refund```, ```Close_charged_off```, and ```Close_paid_off``` are terminal statuses. That is, once an account is changed to one of these statuses it is permanently closed and cannot be reopened. The associated user will have to reapply to open another account in your system. - Shipping address updates will only apply to cards that have yet to be sent to your embosser. You will have to reconcile any address discrepancies with your card embossing partner for cards that have already been sent. - For **non-card-backed LOC** accounts (e.g. Standalone LOC products), by default all credit accounts for the user/entity will receive the same shipping address update. - [Get Account and Cards](https://docs.gospidr.com/reference/getv1accountidaccountandcards.md): Use ```/accountAndCards``` to get information about an account and all its associated cards. Detailed card information is provided through this endpoint, including: - Card emboss records and emboss status per card - Card metadata - Card status - PIN fail count and date This endpoint will also return a list of accounts linked to the account specified. For secured-credit groups, the list is role-aware: collateral and primary-cardholder views include all authorized-user accounts, while an authorized-user view includes only the collateral and primary-cardholder accounts. Secured-credit responses also include structural relationship metadata so consumers do not need to infer roles from primary-account links. For more info on account features, secondary accounts, and card/account statuses, see '[Accounts Overview](https://docs.gospidr.com/docs/accounts-overview).' - [Edit Account Features](https://docs.gospidr.com/reference/patchv1accountideditaccountfeatures.md): Use ```/editAccountFeatures``` to toggle account-level features for a given account. This endpoint allows you to enable account-specific attributes like 'early ACH access' or 'express shipping.' It also allows you to limit your customer's card and transaction behavior. For more info and value enumeration, please see [Account Features](https://docs.gospidr.com/docs/account-and-card-features). --- πŸ“˜ **Note:** Account Features affect *all cards* associated with the account (where applicable). For example, enabling 'Express Shipping' will cause all future cards to ship via express shipping until the account feature is turned off. - [Get Account Statement Data](https://docs.gospidr.com/reference/getv1accountidaccountstatementdata.md): Use ```GET``` on ```/account/statement``` to retrieve a json of transactions for the given account and month/year. This data can be used to generate a statement for your end users. --- πŸ“˜ **Note:** This endpoint should only be used for **debit products**. Unlike all other Spidr endpoints that use UTC, transactions and dates returned via this endpoint are listed using Arizona Standard Time (GMT -0700), also called Mountain Standard Time (MST). - [Download Statement PDF](https://docs.gospidr.com/reference/getv1accountiddownloadstatementpdf.md): Use ```GET``` on ```/account/download-statement-pdf``` to retrieve a URL for downloading the statement PDF for a given account and billing period. The URL is valid for 5 minutes after generation. --- πŸ“˜ **Note:** This endpoint should only be used for **credit products**. The download URL expires after 5 minutes. If the URL expires, you will need to call this endpoint again to generate a new download URL. - [Get Credit Summary](https://docs.gospidr.com/reference/getv1accountidcreditsummary.md): Use ```GET``` on ```/account/:id/creditSummary``` to retrieve the latest secured-credit billing summary. Authorized-user requests resolve to the primary cardholder's shared credit summary. A successful response refreshes the canonical credit details stored on the primary-cardholder credit account. - [Charge Off Account](https://docs.gospidr.com/reference/postv1accountidchargeoff.md): Use ```POST``` on ```/account/:id/chargeOff``` to charge off a secured-credit credit account. The account is closed with the ```close_charged_off``` status. This is a separate action from account closure and does not cascade to authorized-user accounts. - [Close Secured Credit Account](https://docs.gospidr.com/reference/postv1accountidclosesecuredcredit.md): Use ```POST``` on ```/account/:id/closeSecuredCredit``` to close a secured-credit group. The request may target any group member; the group is resolved from its anchor. The primary-cardholder credit account is closed with galileo modify-status type 13 / status C, which cascades to authorized-user accounts, and the collateral account is closed last. The request is rejected if the primary credit account carries an outstanding balance. - [Create ACH Account](https://docs.gospidr.com/reference/postv1achaccountcreate.md): Use the ```/achaccount/create``` endpoint to associate an external bank account with a given account. **Please note:** an ACH account must exist for a customer before they can initiate ACH pushes or pulls to external bank accounts. Use the [Create ACH Transfer](https://docs.gospidr.com/reference/postv1transactioncreateachtransfer) endpoint to originate an ACH transaction to move funds between a customer account and external bank account linked via this endpoint. A ```linkedInstitutionAccountId``` can be provided in lieu of bank account details if your user has linked an institution and account via the [Complete Linked Institution Session](https://docs.gospidr.com/reference/postv1linkedinstitutionsessioncomplete#) endpoint. ACH transaction history for a customer can be retrieved via the [List ACH Requests](https://docs.gospidr.com/reference/getv1transactionlistachrequests) endpoint. - [Get Linked ACH Accounts](https://docs.gospidr.com/reference/getv1achaccountlist.md): Use ```/achaccount/list``` to fetch details about all ACH accounts created via the [Create ACH Account](https://docs.gospidr.com/reference/postv1achaccountcreate) endpoint and linked to the given account. This endpoint is similar to [Get ACH Account Info](https://docs.gospidr.com/reference/getv1achaccountid), except that it returns an array of **all** ACH accounts currently linked to the account. --- πŸ“˜ **Note:** The total number of linked ACH accounts allowed will depend on your program setup and agreement with your partner bank. Most banks limit the number of ACH account linkages per account to manage risk. - [Get ACH Account Info](https://docs.gospidr.com/reference/getv1achaccountid.md): Use ```/GET``` on ```/achaccount``` to fetch details about an ACH account created via the [Create ACH Account](https://docs.gospidr.com/reference/postv1achaccountcreate) endpoint. - [Remove ACH Account](https://docs.gospidr.com/reference/deletev1achaccountid.md): Use ```DELETE``` on ```achaccount``` to remove an existing ACH account linkage created via [Create ACH Account](https://docs.gospidr.com/reference/postv1achaccountcreate). --- πŸ“˜ **Note:** Removing an ACH account will not affect any existing or pending ACH transactions for said account. To cancel a pending ACH origination created via [Create ACH Transfer](https://docs.gospidr.com/reference/postv1transactioncreateachtransfer), call the [Cancel ACH Transfer](https://docs.gospidr.com/reference/postv1transactioncancelachtransfer) endpoint. - [Get Card Info](https://docs.gospidr.com/reference/getv1cardcardid.md): Use ```GET``` on ```/card``` to retrieve all details about a certain card. This endpoint returns the card's status along with a list of emboss records. The card number returned by this endpoint is masked unless your program is PCI-compliant. For newly issued cards, the expiry date will be generated as part of the emboss process, which runs once per day. For more information on card and account statuses, please refer to [Account and Card Statuses](https://docs.gospidr.com/docs/spidr-card-and-account-statuses). - [Activate Card](https://docs.gospidr.com/reference/postv1cardcardidactivate.md): Use the ```/activate``` endpoint to activate a card associated with an account. --- πŸ“˜ **Note:** This endpoint should only be used to activate 'Physical-Only' cards and 'Digital-First' reissued cards. **Do not** use this endpoint for the initial Digital-First card associated with an account (upon account creation) OR for Digital-First replacement cards. See [Activating Cards](https://docs.gospidr.com/docs/activating-cards) for more information. --- ### Important things to note: - Only cards with an emboss status of 'sent_to_emboss' can be activated. - Do not use this endpoint to change a card's status, instead use the [Update Card Status](https://docs.gospidr.com/reference/patchv1cardcardidmodifystatus) endpoint. - After successfully calling this endpoint, the card's status will be updated to 'Active.' - Accounts should only be associated with one active card at a time. - [Update Card Status](https://docs.gospidr.com/reference/patchv1cardcardidmodifystatus.md): Use the ```modifyStatus``` status endpoint to update a card's status, including the ability to 'freeze' a card. Note that, as outlined in [Edit Account](https://docs.gospidr.com/reference/patchv1accountid), changing an account's status impacts all associated cards. Consequently, certain card status transitions are restricted based on the account's current status. For more information on account and card statuses, please refer to [Account and Card Statuses](https://docs.gospidr.com/docs/spidr-card-and-account-statuses). **Please note:** ```closed``` and ```closed_ls``` are terminal statuses. That is, once a card is changed to one of these statuses it is permanently closed and cannot be reactivated or used. - [Get PIN Change Token](https://docs.gospidr.com/reference/getv1cardcardidpinchangetoken.md): Use the ```/pinChangeToken``` endpoint to generate a token necessary to set or change a card's PIN. This token will be passed when calling the PIN set URL configured for your program. After calling the URL with this token, you will call [/commitPinChange](https://docs.gospidr.com/reference/postv1cardcardidcommitpinchange) to complete the PIN-setting process. For more information on setting a card's PIN, see [Setting a PIN](https://docs.gospidr.com/docs/setting-a-pin). --- πŸ“˜ **Note:** This endpoint can be used for first-time PIN-setting OR to update the PIN associated with a card. - [Change PIN](https://docs.gospidr.com/reference/postv1cardcardidcommitpinchange.md): Use the ```/commitPinChange``` endpoint to complete a PIN change that was staged via the [Get PIN Change Token](https://docs.gospidr.com/reference/getv1cardcardidpinchangetoken) endpoint and pin set URL configured for your program. For more information on setting a card's PIN, see [Setting a PIN](https://docs.gospidr.com/docs/setting-a-pin). Setting a PIN via this endpoint is the final step in the PIN-set procedure. --- πŸ“˜ **Note:** This endpoint can be used for first-time PIN-setting OR to update the PIN associated with a card. - [Reset Card PIN Fail Count](https://docs.gospidr.com/reference/postv1cardcardidresetpinfailcount.md): Use the ```resetPinFailCount``` to reset the PIN-fail count to 0 for a cardholder. Per your program config, cards that exceed that PIN-fail threshold will not be usable at locations that require a PIN. The number of PIN failures and the most recent fail date can be retrieved via [Get Card Info](https://docs.gospidr.com/reference/getv1cardcardid). - [Get Card Image URL](https://docs.gospidr.com/reference/getv1cardcardiddisplayurl.md): Use the ```/displayUrl``` endpoint to provide accounts with a Spidr-hosted card image URL. This endpoint returns a URL that provides secure access to a card image for display purposes in your app; it ensures that your system doesn't have to handle or expose PCI-sensitive data. To further protect sensitive data, this URL is dynamically generated by Spidr and has an expiry attached. Use of this endpoint requires coordination with Spidr to set up a specific card configuration for your program. This endpoint is primarily used by programs who are not required to be PCI compliant. - [Provision Mobile Wallet](https://docs.gospidr.com/reference/postv1cardcardidmobilewalletprovision.md): Use the ```provisionMobileWallet``` endpoint to push-provision a virtual card to a mobile wallet. This endpoint can only be used if your program has the required configuration for manual provisioning. 'Push provisioning' obviates the need for your cardholder to manually enter card information; you can call this endpoint instead to have the card provisioned. This provides a more seamless user experience with less errors. --- πŸ“˜ **Note:** Please work with Spidr to ensure that your program is correctly configured to support mobile wallets. - [Reissue Card](https://docs.gospidr.com/reference/postv1cardcardidreissue.md): Use the ```reissue``` endpoint to generate a new version of an existing card. This newly generated version retains the same PAN and Card ID (CAD). The card receives a new expiry date and CVV, and a new emboss record is created -- viewable via the ```embossedCards``` object when using [Get Card Info](https://docs.gospidr.com/docs/loststolen-and-reissue). Cards are usually reissued when the physical card is damaged or when a card is about to expire (if your program does not have an auto-reissue configuration for expired cards). After successfully calling this endpoint, the old card will be usable until the reissued card is activated. The newly created card will have a status of ```sent_to_emboss``` under the ```embossedCards``` object once it is sent to the embosser (use [Get Card Info](https://docs.gospidr.com/reference/getv1cardcardid) to check the status). Cards with this status are not activated and are thus protected in transit -- this also applies to Digital-First reissues. Once your customer verifies receipt of the new card, it can be activated via [Activate Card](https://docs.gospidr.com/reference/postv1cardcardidactivate) (see [Activating Cards](https://docs.gospidr.com/docs/activating-cards)) Activating the card will update the status under ```embossedCards``` to ```card_activated```, enabling it for use. For all other cases, please use the [Replace Card](https://docs.gospidr.com/reference/postv1cardcardidreplace) endpoint. For more information on reissuing vs. replacing a card, please see [Replacing and Reissuing Cards](https://docs.gospidr.com/docs/loststolen-and-reissue). --- πŸ“˜ **Note:** The new CVV and expiry are generated by the daily emboss process. Call [Get Card Info](https://docs.gospidr.com/reference/getv1cardcardid) to retrieve the new expiry value after the emboss process has run. - [Replace Card](https://docs.gospidr.com/reference/postv1cardcardidreplace.md): Use the ```replace``` endpoint to generate a net-new card for an account. You can use this endpoint to replace a card that has been lost or stolen. This endpoint generates a card with a new PAN, CVV, expiry, and creates a new emboss record. To reissue a card (keep the same PAN but generate a new CVV/expiry), please refer to [Reissue Card](https://docs.gospidr.com/reference/postv1cardcardidreissue). For more information on reissuing vs. replacing a card, please see [Replacing and Reissuing Cards](https://docs.gospidr.com/docs/loststolen-and-reissue). This endpoint sets the old card's status to ```closed_ls``` once successfully called. The ```cardExpiryDate``` and ```cardNumber``` returned by this endpoint are the new values; you do not have to wait for the emboss process to run. Your program must be PCI-compliant to receive the full PAN, otherwise it will be masked. Once your customer receives the card, you can call [Activate Card](https://docs.gospidr.com/reference/postv1cardcardidactivate) to activate it. ### :information_source: Special Note for Digital-First Cards Since Digital-First cards are active upon creation, successfully calling this endpoint will automatically block physical transactions to protect the newly created card in transit. **Note: this will overwrite any existing blocks on the card that were set via [Edit Account Features](https://docs.gospidr.com/reference/patchv1accountideditaccountfeatures)**. Digital and mobile wallet transactions will still be permitted while this block is in place. Once a customer has confirmed receipt of the physical card, remove this block by calling the [Edit Account Features](https://docs.gospidr.com/reference/patchv1accountideditaccountfeatures) endpoint. For more information, see [Activating Cards](https://docs.gospidr.com/docs/activating-cards). - [Get Transactions](https://docs.gospidr.com/reference/getv1transactiongettransactions.md): Use the ```/getTransactions``` endpoint to retrieve a complete list of posted transactions for an account and auths affecting balances. This endpoint returns a simpler set of data than the [Get All Transactions](https://docs.gospidr.com/reference/getv1transactiongetalltranshistory) endpoint and is more suitable for displaying to customers. For a full list of transactions, including backouts, denied transactions, AVS-only requests, and tokenization requests, use the [Get All Transactions](https://docs.gospidr.com/reference/getv1transactiongetalltranshistory) endpoint. - [Get All Transaction History](https://docs.gospidr.com/reference/getv1transactiongetalltranshistory.md): Use the ```/getAllTransHistory``` endpoint to retrieve a complete list of all transactions for an account. The ```balanceAfterTransaction``` field reflects the account balance after the transaction processed. The deprecated ```calculatedBalance``` field is currently returned as an alias for compatibility. This endpoint will also return auths, backouts, denied transactions, AVS-only requests, and tokenization requests. Since this endpoint may return a large number of records, please use the ```page``` and ```recordCnt``` parameters to control the amount of data fetched. - [Create A2A Transfer](https://docs.gospidr.com/reference/postv1transactioncreatea2atransfer.md): Use the ```/createA2ATransfer``` endpoint to transfer funds between two accounts within your program. The accounts can belong to the same customer or different customers. ### Things to note: - The receiving account must have a status of 'Active' to receive funds. - Fees can automatically be assessed on this transfer per your configuration/setup with Spidr. - Do not use this endpoint to transfer funds between an ACH account or external account. Use [Create ACH Transfer](https://docs.gospidr.com/reference/postv1transactioncreateachtransfer) instead. - Please note that the ```message``` parameter is what is displayed to the recipient, the ```senderMessage``` is displayed to the sender. If only ```message``` is provided, both the sender and receiver will see the same message. --- πŸ“˜ **Note:** ```Message``` and ```senderMessage``` do not accept international charactersβ€”only letters, numbers, spaces, and punctuation. --- ### Result of calling Create A2A Transfer: When the Create Account Transfer endpoint has been successfully called: - The specified amount is debited from the sending account. This transaction appears as an adjustment on the sending account. - The specified amount is credited to the receiving account. This transaction appears as a payment on the receiving account. - If configured, a fee is assessed to the sending account. This transaction appears as a fee on the sending account. - [Create Payment](https://docs.gospidr.com/reference/postv1transactioncreatepayment.md): Use the ```/createPayment``` endpoint to move funds into an account. Successfully calling this endpoint will credit the target account. As with [Create Fee](https://docs.gospidr.com/reference/postv1transactioncreatefee) and [Create Adjustment](https://docs.gospidr.com/reference/postv1transactioncreateadjustment), Spidr will work with your program to configure 'payment types' and the underlying funds movement. --- πŸ“˜ **Note:** This endpoint will respect any load or velocity limits per your program configuration. Spidr will work with you to set these values as part of your program setup. - [Create ACH Transfer](https://docs.gospidr.com/reference/postv1transactioncreateachtransfer.md): Use the ```/createAchTransfer``` endpoint to originate an ACH transaction to move funds between a customer account and external bank account linked via [Create ACH Account](https://docs.gospidr.com/reference/postv1achaccountcreate). The originator of this transaction is your customer/bank and the recipient is the holder of the external account. If the associated ACH account was created via a ```linkedInstitutionAccountId```, balance checks are automatically performed to ensure sufficient funds for ACH pulls (contingent on your product's configuration). The ACH transfer created via this endpoint can either be a push (credit) or pull (debit) to the recipient account. The optional ```companyEntryDescription``` field is accepted for all ACH transfers and identifies the ACH purpose shown on the receiver's bank statement. Galileo added support for this field in Production on March 20, 2026. From March 20 through June 29, 2026, Galileo applies the PSG-approved default if no value is provided. Beginning June 30, 2026, Galileo-backed ACH originations require either a request value or a configured product-level default; missing values are rejected before the vendor call. Spidr resolves the value after vendor selection and forwards the field only to vendor APIs that currently support it. To view a list of ACH transfers originated by an account, use the [List ACH Requests](https://docs.gospidr.com/reference/getv1transactionlistachrequests) endpoint. To cancel an ACH transfer, use the [Cancel ACH Transfer](https://docs.gospidr.com/reference/postv1transactioncancelachtransfer) endpoint. For more information on ACH accounts and transactions, please see [ACH Accounts and Transactions](https://docs.gospidr.com/docs/ach-accounts-and-transactions). - [Cancel ACH Transfer](https://docs.gospidr.com/reference/postv1transactioncancelachtransfer.md): Use the ```/cancelAchTransfer``` endpoint to cancel an ACH transfer that was initiated via the [Create ACH Transfer](https://docs.gospidr.com/reference/postv1transactioncreateachtransfer) endpoint. **Please note:** Only ACH transactions in a status of 'N' (queued for transfer) may be cancelled. To retrieve the status of an ACH transaction, call the [List ACH Requests](https://docs.gospidr.com/reference/getv1transactionlistachrequests) endpoint. - [List ACH Requests](https://docs.gospidr.com/reference/getv1transactionlistachrequests.md): Use the ```/listAchRequests``` endpoint to retrieve a list of all ACH transfers originated by a specific account. --- πŸ“˜ **Note:** Please note that this endpoint only returns outgoing ACH transfers initiated by [Create ACH Transfer](https://docs.gospidr.com/reference/postv1transactioncreateachtransfer). --- To view incoming ACH transfers, use the [Get All Transaction History](https://docs.gospidr.com/reference/getv1transactiongetalltranshistory) endpoint. - [Create Fee](https://docs.gospidr.com/reference/postv1transactioncreatefee.md): Use the ```/createFee``` endpoint to assess a fee to the specified account. The fee amount will be deducted from the account balance after a successful call. **Please note:** account balances will be checked before a fee is created. If the account does not have sufficient funds, the fee will not be created. As part of your program setup, you'll define a list of 'fee types' and corresponding money movement. You can then assess fees via this endpoint when needed. --- πŸ“˜ **Note:** Spidr will work with your program to configure fee types, automatic fees, and the underlying funds movement. --- To reverse a fee, see [Reverse Fee](https://docs.gospidr.com/reference/postv1transactionreversefee). To see a list of fees assessed for an account see [List Fees](https://docs.gospidr.com/reference/getv1transactionlistfees). - [List Fees](https://docs.gospidr.com/reference/getv1transactionlistfees.md): Use the ```/listFees``` endpoint to retrieve a list of fees assessed for the given account. The fees returned via this endpoint were created via [Create Fee](https://docs.gospidr.com/reference/postv1transactioncreatefee). - [Reverse Fee](https://docs.gospidr.com/reference/postv1transactionreversefee.md): Use the ```/reverseFee``` endpoint to reverse a fee that was created via [Create Fee](https://docs.gospidr.com/reference/postv1transactioncreatefee). Successfully calling this endpoint will create a transaction that adjusts the account balance in the opposite direction of the original fee. To retrieve a list of fees for an account, call [List Fees](https://docs.gospidr.com/reference/getv1transactionlistfees). - [Create Adjustment](https://docs.gospidr.com/reference/postv1transactioncreateadjustment.md): Use the ```/createAdjustment``` endpoint to move funds into or out of a specific account. Adjustments are immediately processed and reflected on the account balance. Adjustments can be used to reimburse customers, reconcile ledgers, and more. Each adjustment has a 'type' that delineates the type of money movement involved. To reverse an adjustment, see [Reverse Adjustment](https://docs.gospidr.com/reference/postv1transactionreverseadjustment). --- πŸ“˜ **Note:** Spidr will work with your program to configure adjustment types and the underlying funds movement. - [Reverse Adjustment](https://docs.gospidr.com/reference/postv1transactionreverseadjustment.md): Use the ```/reverseAdjustment``` endpoint to reverse an adjustment that was created via [Create Adjustment](https://docs.gospidr.com/reference/postv1transactioncreateadjustment). Successfully calling this endpoint will create a transaction that adjusts the account balance in the opposite direction of the original adjustment. - [Simulate Card Authorization](https://docs.gospidr.com/reference/postv1transactionsimulatecardauth.md): Use the ```/simulateCardAuth``` endpoint to simulate a card authorization in non-production environments. This endpoint creates but does not settle a card authorization for the account. --- πŸ“˜ **Note:** This endpoint is only available in non-production environments (local, development, sandbox, cv). Calls to this endpoint in production will return an error. --- ### Requirements: - The account must be active - For debit accounts, sufficient balance is required - Card blocks must be set to 'none' on the account ### Result: When successfully called, this endpoint returns an `authId` that can be used with [Simulate Card Settle](https://docs.gospidr.com/reference/postv1transactionsimulatecardsettle) to complete the transaction. ### Choosing the simulation path (`useAttachedCardNetwork`): Some accounts have a card network (Galileo) attached on top of a different primary system of record β€” for example, a LoanPro-backed line of credit with an attached Galileo card. For those accounts there are two distinct paths that can produce a transaction, and this flag controls which one the simulation exercises: - **Card network path** β€” the simulation is run against the attached card network (Galileo). This mirrors what happens in production when a real card swipe is authorized by the network and then forwarded to the primary system. - **Primary path** β€” the simulation is run directly against the account's primary vendor (e.g., LoanPro for an LMS-backed account), bypassing the card network. Useful for testing the system-of-record's behavior in isolation. **Behavior by value:** - **Omitted (default)** β€” runs on the attached card network when one is present on the account; otherwise runs on the account's primary vendor. For native Galileo accounts (where Galileo is also the primary vendor), this is always Galileo. - **`true`** β€” forces the attached card network path. Returns a `400 ATTACHED_CARD_NETWORK_NOT_FOUND` error if the account has no attached card network. - **`false`** β€” forces the account's primary path, even if a card network is attached. For a LoanPro-backed account this routes the simulation to the LMS side. For native Galileo accounts (no separate primary vendor), all three values resolve to the same Galileo simulation. - [Simulate Card Settlement](https://docs.gospidr.com/reference/postv1transactionsimulatecardsettle.md): Use the ```/simulateCardSettle``` endpoint to settle a simulated card authorization that was created via [Simulate Card Auth](https://docs.gospidr.com/reference/postv1transactionsimulatecardauth). --- πŸ“˜ **Note:** This endpoint is only available in non-production environments (local, development, sandbox, cv). Calls to this endpoint in production will return an error. --- ### Requirements: - The `authId` must be from a valid pending authorization - The account must be active ### Result: When successfully called, the authorization is settled and the account balance is updated accordingly. ### Choosing the simulation path (`useAttachedCardNetwork`): Some accounts have a card network (Galileo) attached on top of a different primary system of record β€” for example, a LoanPro-backed line of credit with an attached Galileo card. For those accounts there are two distinct paths that can produce a transaction, and this flag controls which one the simulation exercises: - **Card network path** β€” the simulation is run against the attached card network (Galileo). This mirrors what happens in production when a real card swipe is authorized by the network and then forwarded to the primary system. - **Primary path** β€” the simulation is run directly against the account's primary vendor (e.g., LoanPro for an LMS-backed account), bypassing the card network. Useful for testing the system-of-record's behavior in isolation. **Behavior by value:** - **Omitted (default)** β€” runs on the attached card network when one is present on the account; otherwise runs on the account's primary vendor. For native Galileo accounts (where Galileo is also the primary vendor), this is always Galileo. - **`true`** β€” forces the attached card network path. Returns a `400 ATTACHED_CARD_NETWORK_NOT_FOUND` error if the account has no attached card network. - **`false`** β€” forces the account's primary path, even if a card network is attached. For a LoanPro-backed account this routes the simulation to the LMS side. For native Galileo accounts (no separate primary vendor), all three values resolve to the same Galileo simulation. **Important:** the value passed here must match the value used on the originating [Simulate Card Auth](https://docs.gospidr.com/reference/postv1transactionsimulatecardauth) call. Settling on a different path than the auth was created on will fail to find the pending authorization. - [Create Transaction (BYOP)](https://docs.gospidr.com/reference/postv1transactioncreatetransaction.md): Use the ```/createTransaction``` endpoint to manually create a transaction for a BYOP (Bring Your Own Processor) account. This endpoint allows you to directly insert transaction records into the system. **Note:** This endpoint is only available for accounts using the BYOP vendor type. Attempts to use this endpoint with non-BYOP accounts will result in an error. - [Get Product Info](https://docs.gospidr.com/reference/getv1productid.md): Use ```GET``` on ```/product``` to retrieve details about the specified product you've configured with Spidr. This endpoint returns product metadata along with a list of configured fees, payments, and adjustment types. - [Create Group](https://docs.gospidr.com/reference/postv1groupcreate.md): Create a root group or a child group. Omit parentGroupId for a root group. - [List groups](https://docs.gospidr.com/reference/getv1group.md): List groups for the company. Optionally filter by parentGroupId or rootGroupId. - [Get group by ID](https://docs.gospidr.com/reference/getv1groupid.md): Retrieve a single group by its ID. - [Update group](https://docs.gospidr.com/reference/patchv1groupid.md): Update a group's name or description. Parent cannot be changed. - [Delete group](https://docs.gospidr.com/reference/deletev1groupid.md): Delete a group. Fails if the group has children or linked accounts. - [Get group hierarchy](https://docs.gospidr.com/reference/getv1groupidhierarchy.md): Retrieve a group and its nested children as a tree. Optionally limit depth. - [Assign accounts to group](https://docs.gospidr.com/reference/postv1groupidassignaccounts.md): Assign one or more accounts to this group. - [Remove accounts from group](https://docs.gospidr.com/reference/postv1groupidremoveaccounts.md): Remove one or more accounts from this group. Only accounts currently in this group are unassigned. - [Create Round-Up Enrollment](https://docs.gospidr.com/reference/postv1roundupcreate.md): Use ```/v1/roundup/create``` to create a round-up enrollment. The enrollment defines how round-ups are calculated for a user's tracked transactions, the cadence on which accumulated round-ups are swept, and the funding and receiving accounts used to move the money. At least one tracking, funding, and receiving account is required. - [List Round-Up Enrollments](https://docs.gospidr.com/reference/getv1rounduplist.md): Use ```/v1/roundup/list``` to retrieve a paginated, filterable, and sortable list of round-up enrollment configurations. - [Get Round-Up Enrollment](https://docs.gospidr.com/reference/getv1roundupid.md): Use ```/v1/roundup/:id``` to retrieve a single round-up enrollment configuration by its ID. - [Update Round-Up Enrollment](https://docs.gospidr.com/reference/patchv1roundupid.md): Use ```/v1/roundup/:id``` (PATCH) to update the configuration of an existing round-up enrollment. Any subset of the configuration fields may be supplied; omitted fields are left unchanged. Use the update status endpoint to pause, resume, or close an enrollment. - [Update Round-Up Enrollment Status](https://docs.gospidr.com/reference/postv1roundupidupdatestatus.md): Use ```/v1/roundup/:id/updateStatus``` to pause, resume, or close a round-up enrollment by requesting a new status (`active`, `paused`, or `closed`). - [List Round-Up Sweep Transfers](https://docs.gospidr.com/reference/getv1roundupidlistsweeptransfers.md): Use ```/v1/roundup/:id/listSweepTransfers``` to retrieve a paginated, filterable, and sortable list of sweep transfer records for a round-up enrollment. Each record shows how a cadence period's round-up amount was calculated and the resulting funding and receiving transfers. - [Simulate Round-Up Sweep](https://docs.gospidr.com/reference/postv1roundupidsimulatesweep.md): Use ```/v1/roundup/:id/simulateSweep``` to queue an early execution of the enrollment's current cadence period in a non-production environment. The normal asynchronous sweep worker performs aggregation, cadence caps, minimum checks, sufficient-funds validation, funding, receiving deposits, and lifecycle updates. Repeated requests in a successfully completed cadence period return the existing sweep; safe skipped or pre-transfer failed outcomes can be queued for reevaluation. Poll ```/v1/roundup/:id/listSweepTransfers``` and correlate by sweepKey. - [Ping Unified API](https://docs.gospidr.com/reference/getv1otherping.md): Use ```GET``` on ```/ping``` to test your connection to the Unified API. This endpoint is useful for verifying that your API key is valid and that you can successfully connect to the API. API keys can be generated in the Spidr Dev Portal. Reach out to a Spidr contact for dev portal access. - [Search Biller Directory](https://docs.gospidr.com/reference/postv1billpaysearchbillerdirectory.md): Use ```/billpay/searchBillerDirectory``` to search the RPPS biller directory for electronic billers. Returns matching billers with their RPPS biller IDs, which can then be used with the [Add Electronic Biller](https://docs.gospidr.com/reference/postv1billpayaddelectronicbiller) endpoint to link a biller to an account. - [Get Billers](https://docs.gospidr.com/reference/getv1billpaygetbillers.md): Use ```/billpay/getBillers``` to retrieve all billers (both electronic and paper) currently linked to an account. Each biller includes its ID, type, name, address, and account number. - [Add Electronic Biller](https://docs.gospidr.com/reference/postv1billpayaddelectronicbiller.md): Use ```/billpay/addElectronicBiller``` to add an electronic (RPPS) biller to an account. The ```rppsBillerId``` must be obtained from the [Search Biller Directory](https://docs.gospidr.com/reference/postv1billpaysearchbillerdirectory) endpoint. The account must be active to add a biller. - [Add Paper Biller](https://docs.gospidr.com/reference/postv1billpayaddpaperbiller.md): Use ```/billpay/addPaperBiller``` to add a paper (check) biller to an account. Paper billers require full payee address information. The account must be active to add a biller. - [Modify Electronic Biller](https://docs.gospidr.com/reference/patchv1billpaymodifyelectronicbiller.md): Use ```/billpay/modifyElectronicBiller``` to modify an existing electronic (RPPS) biller linked to an account. You can update the payment frequency, scheduled dates, and default amount. - [Modify Paper Biller](https://docs.gospidr.com/reference/postv1billpaymodifypaperbiller.md): Use ```/billpay/modifyPaperBiller``` to modify an existing paper (check) biller linked to an account. You can update the payment frequency, scheduled dates, default amount, and address details. - [Remove Biller](https://docs.gospidr.com/reference/postv1billpayremovebiller.md): Use ```/billpay/removeBiller``` to remove a biller (electronic or paper) from an account. This will not cancel any pending payments for this biller. - [Create Bill Payment](https://docs.gospidr.com/reference/postv1billpaycreatepayment.md): Use ```/billpay/createPayment``` to create a bill payment for a biller linked to an account. Payments can be one-time or scheduled (weekly, monthly, quarterly, yearly). The biller must already be linked to the account via the add biller endpoints. - [Cancel Bill Payment](https://docs.gospidr.com/reference/postv1billpaycancelpayment.md): Use ```/billpay/cancelPayment``` to cancel a pending bill payment. Only payments that have not yet been processed can be canceled. - [Get Scheduled Bill Payments](https://docs.gospidr.com/reference/getv1billpaygetscheduledpayments.md): Use ```/billpay/getScheduledPayments``` to retrieve all scheduled and upcoming bill payments for an account. - [Get Bill Payment History](https://docs.gospidr.com/reference/getv1billpaygetpaymenthistory.md): Use ```/billpay/getPaymentHistory``` to retrieve bill payment history for an account within a date range. - [Create ZTM Session](https://docs.gospidr.com/reference/postv1sessioncreate.md): Use the ```/session/create``` endpoint to generate a ZTM session. Spidr **does not** enforce session expiration. We recommend setting a session expiration of no more than 30 minutes. Sessions are typically user-based. However ```userId``` is optional and a session can be generated without being attached to a user. This is necessary when the user record does not yet exist, such as when running ZTM checks on the [Create User](https://docs.gospidr.com/reference/postv1usercreate) endpoint. Best practice is to always use ```userId``` to generate a session when possible. If you are using the Sardine SDK, please initialize the SDK with the session returned. --- πŸ“˜ **Note:** Please note that a session key is required for ZTM to perform customer and device checks (if your program is using Sardine). --- - [Retry Identity Verification](https://docs.gospidr.com/reference/postv1useridvretry.md): Use the ```/user/idv/retry endpoint``` to retry identity verification (IDV) for a user. This endpoint allows you to trigger a new identity verification session against the specified provider. You must provide one of the following: - A ```provider``` **AND** a ```providerIdvSessionId``` OR - An ```idvSessionId``` β€” which is the Spidr-specific session ID. Use ```retryScope``` to choose how much of the verification to re-run: - ```failed``` β€” resume at the step the user failed, keeping the steps they already passed. Whether a session can be resumed is the provider's decision, not ours: a session whose failing step was a screening or a risk check is refused, and the provider may refuse others it cannot resume. Retry with ```all``` if that happens. - ```all``` β€” re-run the whole verification from the start. This is the default. Which individual steps each scope runs is determined by the IDV template configured for your product, not by the request. - [Post Manual Review Decision](https://docs.gospidr.com/reference/postv1useridvmanualreview.md): Use the ```/user/idv/manualReview``` endpoint to post a manual review decision for a user's identity verification (IDV) session. This endpoint allows you to set the 'manual review' status of an IDV session to either "passed" or "failed" based on your manual review. 'Manual review' must be configured for your product to use this endpoint. The result of the manual review will update the risk of the IDV session accordingly and is typically the last step before an overall approve or decline decision is made for the corresponding ```user_create``` action. The request completes the full decision: the decision is recorded, and the follow-up processing β€” the IDV session and action risk update, the needs-decision notification, and the CIP status update when the review produces a final decision β€” runs before the response is returned. A ```200``` means the decision and all of that were persisted successfully. One notification is best-effort and sits outside that guarantee: when the review causes the user's CIP status to change, this endpoint also triggers a separate ```cipStatusUpdated``` webhook. A ```200``` means the CIP status itself was updated, but does not guarantee that webhook was delivered β€” a delivery failure there is logged and does not fail the request, and cannot be repaired by resubmitting. If your integration depends on that notification arriving, poll or reconcile the user's CIP status directly rather than relying on the webhook alone. Because the decision is recorded first, an error response can be returned for a decision that was in fact saved. When that happens, resubmit the **same** ```idvSessionId``` and ```status``` to finish the outstanding processing β€” the original reviewer and decision timestamp are preserved, and the decision is not recorded twice. Each resubmission must use a new ```x-client-request-id```, since a repeated request ID is rejected as a duplicate. Resubmitting a **different** ```status``` is rejected: this endpoint cannot be used to change a decision that has already been made. If the session is later returned to manual review (for example after a verification retry), it is treated as a new review and a fresh decision is recorded normally. - [Ad Hoc User Checks](https://docs.gospidr.com/reference/postv1userother.md): Use the ```/user/other``` endpoint to perform ad hoc checks on users interacting with your platform. This endpoint is useful for checking user actions that do not pertain to the Spidr API such as: logging in/out, resetting passwords, 2FA or step-up authentication, etc. Please pass in a ```flowName``` to describe the type of user action. You can also pass in a ```daysSinceLastAddressChange``` to indicate the number of days since the last address change for a user or account. - [Create IDV Session Note](https://docs.gospidr.com/reference/postv1useridvnotes.md): Create a note for an IDV session - [Post Ad Hoc Feedback](https://docs.gospidr.com/reference/postv1useradhocfeedback.md): Use the ```/user/ad-hoc-feedback``` endpoint to post feedback on fraud-related actions/decisions taken **outside** the ZTM API (via [Ad Hoc User Checks](https://docs.gospidr.com/reference/postv1userother)). Posting this feedback helps train the ZTM model to better detect fraud. This endpoint can also be used to add users to Spidr's block list. - [Run Ad Hoc Identity Verification](https://docs.gospidr.com/reference/postv1useridvadhoc.md): Use the ```/user/idv/adhoc``` endpoint to run identity verification (IDV) ad hoc for an existing user, outside of user creation. You provide the ```userId```, the Spidr ```idvTemplateId``` to run, and the ```productId``` the verification is intended for (the template must be enabled on that product). The endpoint creates the IDV session and returns immediately. When the selected template uses Plaid's hosted flow, the response includes a ```shareableUrl``` the user visits to complete verification. The result arrives asynchronously: once the session completes and a decision is made, the passed session is recorded on the user and the user's CIP status is updated to pass or fail accordingly. A subsequent ```/account/create``` against the product can then reuse the passing session. - [Create Watchlist Screening Enrollment](https://docs.gospidr.com/reference/postv1amlwatchlistscreeningcreate.md): Use the ```/aml/watchlist-screening/create``` endpoint to create a new watchlist screening enrollment for a user. This endpoint allows you to enroll a user in watchlist screening monitoring by providing a ```userId```. The system will validate the user's eligibility and create the appropriate screening enrollment with the configured vendor. Please note that your product must support watchlist screening to use this endpoint. Once a user is enrolled, you can fetch and manage their watchlist details via the other watchlist endpoints. Enrollment also ensures that the user is monitored for any future watchlist hits according to your product's settings. - [Retrieve Watchlist Screening Info](https://docs.gospidr.com/reference/getv1amlwatchlistscreeningwatchlistscreeningid.md): Use the ```/aml/watchlist-screening``` endpoint to retrieve watchlist screening information for a user by providing the ```watchlistScreeningId``` - [Update Watchlist Screening](https://docs.gospidr.com/reference/patchv1amlwatchlistscreeningwatchlistscreeningid.md): Use ```PATCH``` on the ```/aml/watchlist-screening``` endpoint to update the overall status and reason for a watchlist screening. This endpoint allows you to manually update the status of a watchlist screening record and provide a reason for the update. - [Update Watchlist Screening Hits](https://docs.gospidr.com/reference/postv1amlwatchlistscreeningwatchlistscreeningidhitupdate.md): Use the ```/aml/watchlist-screening/hit-update``` endpoint to update individual watchlist screening hits. This endpoint allows you to confirm or dismiss specific hits within a watchlist screening by providing arrays of hit IDs and a comment explaining the review decision. - [Update Watchlist Screening Criteria](https://docs.gospidr.com/reference/patchv1amlwatchlistscreeningwatchlistscreeningidcriteriaupdate.md): Use the ```/aml/watchlist-screening/criteria-update``` endpoint to update the criteria for a watchlist screening. 'Criteria' refers to a particular user's personal information. When a user updates their personal details (such as name, date of birth, or address), you can use this endpoint to ensure the data is checked against the corresponding screening for your program. You can update the criteria for a watchlist screening by providing a ```watchlistScreeningId``` and a list of updated fields via the ```searchCriteria``` object. - [Post Decision](https://docs.gospidr.com/reference/postv1actiondecision.md): Use the ```/action/decision``` endpoint to post decisions on actions that were scored by ZTM. Decisions can only be posted to actions with a ```pending``` status. Approving an action typically lets it proceed to completion (if no failures are encountered), while declining an action typically halts the action from proceeding further. Please check with a Spidr contact if you have questions about your ZTM configuration and how decisions impact your flows. - [Create Linked Institution Session](https://docs.gospidr.com/reference/postv1linkedinstitutionsessioncreate.md): Use the ```linked-institution/session/create``` endpoint to create a session for linking external financial institutions through various providers. This session can be used to initiate the linking process and manage institutions with the underlying providers. You must supply both the provider being used and the list of services you require for the session. If the user has an existing linked institution, you can provide the ```linkedInstitutionId``` to reuse that institution for the session. Creating a session is the first step in connecting an external institution (and external accounts) to a user. After creating a session and presenting either a hosted URL or SDK experience to the user, you will need to complete the linking process by calling the [Complete Linked Institution Session](https://docs.gospidr.com/reference/postv1linkedinstitutionsessioncomplete) endpoint once the user has finished the provider flow. - [Complete Linked Institution Session](https://docs.gospidr.com/reference/postv1linkedinstitutionsessioncomplete.md): Use the ```linked-institution/session/complete``` endpoint to complete a session for linking external financial institutions through various providers. This endpoint finalizes the linking process after the user has finished the provider's flow (either via a hosted URL or SDK experience). Pass in the ```linkedInstitutionSessionId``` returned from the [Create Linked Institution Session](https://docs.gospidr.com/reference/postv1linkedinstitutionsessioncreate#/) endpoint. If you provided a hosted URL experience to the user, you must pass in the ```linkedInstitutionSessionId```. If you provided an SDK experience, please pass in the ```publicToken``` (under the ```providerOptions``` object) received from the provider after the user finishes the linking process (Plaid only). This endpoint will return the linked institutions created or updated during the session, along with a list of accounts for each institution. You can use the ```linkedInstitutionId``` returned in the response to further manage or interact with the linked institution. You can also use the ```linkedInstitutionAccountId``` to perform balance checks via [Check Linked Institution Account Balance](https://docs.gospidr.com/reference/postv1linkedinstitutionaccountbalancecheck#/) or create an ACH account via [Create ACH Account](https://docs.gospidr.com/reference/postv1achaccountcreate#/). - [Fetch Linked Institutions and Accounts](https://docs.gospidr.com/reference/getv1linkedinstitutionlist.md): Use the ```linked-institution/list``` endpoint to fetch all linked institutions and their associated accounts for a specific user. By providing the ```userId```, you can retrieve a comprehensive list of linked institutions that the user has connected through various providers. - [Remove Linked Institution](https://docs.gospidr.com/reference/deletev1linkedinstitutionlinkedinstitutionid.md): Use ```DELETE``` on the ```/linked-institution``` endpoint to remove a linked institution from a user. This action is irreversible and will permanently delete the linked institution (and any underlying linked institution accounts) from the user. - [Refresh Linked Institution and Accounts](https://docs.gospidr.com/reference/postv1linkedinstitutionlinkedinstitutionidrefresh.md): Use the ```linked-institution/refresh``` endpoint to refresh the data of a linked institution. This endpoint will re-fetch the latest information and account data from the linked institution, ensuring that you have the most up-to-date data available. - [Check Linked Institution Account Balance](https://docs.gospidr.com/reference/postv1linkedinstitutionaccountbalancecheck.md): Use the ```linked-institution/account/balance-check``` endpoint to check the balance of a specific linked institution account. This endpoint allows you to verify if the account has sufficient funds for a requested amount. - [Fetch Linked Institution Transactions](https://docs.gospidr.com/reference/getv1linkedinstitutionlinkedinstitutionidtransactions.md): Use the ```linked-institution/:linkedInstitutionId/transactions``` endpoint to fetch transactions from a linked institution. This endpoint retrieves transaction data from the underlying provider (e.g., Plaid) and returns paginated results. You can optionally filter by specific accounts using ```linkedInstitutionAccountIds```, and specify a date range using ```startDate``` and ```endDate```. If no date range is provided, transactions from the last 30 days will be returned. Transactions are returned in reverse chronological order (most recent first). - [Simulate Plaid Link (sandbox only)](https://docs.gospidr.com/reference/postv1linkedinstitutionsessionsimulatelink.md): Simulates a user completing the Plaid Link flow by generating a sandbox public token. This endpoint is for **sandbox/non-production environments only**. Use this endpoint to test the linked institution flow without requiring a user to go through the Plaid Link UI. **Flow:** 1. Call `session/create` to get a `linkedInstitutionSessionId` 2. Call this endpoint (`session/simulate-link`) to get a `publicToken` 3. Call `session/complete` with the `publicToken` **Note:** This endpoint will fail in production environments or when configured with a non-sandbox Plaid URL. - [Search Institutions](https://docs.gospidr.com/reference/postv1linkedinstitutionsearch.md): Use the ```linked-institution/search``` endpoint to search for financial institutions by name through a provider, in order to power an institution picker / search UI. Supply the ```provider```, the ```productId```, and the ```vendorServices``` you intend to use the institution for; results are filtered to institutions that support those services. Each result includes the ```providerId``` (unique institution identifier for the provider, useful for deduping), ```institutionName```, an optional ```institutionLogo```, and the ```supportedServices``` the institution supports. The raw provider payload is nested under ```providerDetails```. No provider credentials are exposed. - [Get Institution By Id](https://docs.gospidr.com/reference/postv1linkedinstitutiongetbyid.md): Use the ```linked-institution/get-by-id``` endpoint to look up a single financial institution by its provider-specific ```providerId``` (for example, a Plaid ```institution_id```). Supply the ```provider``` and the ```productId```. The response includes the ```providerId```, ```institutionName```, an optional ```institutionLogo```, and the ```supportedServices``` the institution supports, with the raw provider payload nested under ```providerDetails```. No provider credentials are exposed. - [Inject synthetic transactions (sandbox only)](https://docs.gospidr.com/reference/postv1linkedinstitutionlinkedinstitutionidsimulatetransactions.md): Injects synthetic transactions into a **sandbox-linked** institution via Plaid's `sandbox/transactions/create`, then (by default) enqueues a transaction sync so they flow through the real ingestion pipeline β€” transformer, Spidr category mapping, and round-up processing β€” exactly like organic transactions. This endpoint is for **sandbox/non-production environments only**. **Flow:** 1. Link an institution with `session/create` β†’ `session/simulate-link` (**with `dynamicTransactions: true`** β€” Plaid only materializes created transactions on `user_transactions_dynamic` items; on the default canned user they are accepted but never appear) β†’ `session/complete` 2. Call this endpoint with up to 10 transactions 3. The enqueued sync ingests them; they appear in `GET :linkedInstitutionId/transactions` with Spidr categories **Category control:** Plaid derives `personal_finance_category` from the `description`, so pick merchant-like descriptions ("Starbucks" β†’ Food & Dining/Coffee Shops, "Uber" β†’ Transportation/Rideshare & Taxi, "Netflix.com" β†’ Entertainment, "Shell Oil" β†’ Transportation/Gas & Fuel). Exact category assignment is Plaid's call β€” assert on the mapped Spidr category after sync rather than assuming. **Note:** This endpoint will fail in production environments or when configured with a non-sandbox Plaid URL.