Skip to main content

Dwolla

Dwolla is a fintech platform providing an API for ACH bank transfers, real-time payments, and payment automation. Organizations programmatically manage customers, funding sources, and money movement — standard ACH, Same Day ACH, and real-time rails — through one unified API. It's used by fintechs, lenders, insurers, and marketplaces to automate high-volume payments and mass disbursements.

Dwolla icon

Power end-to-end data operations for your Dwolla API with Nexla. Our bi-directional Dwolla connector is purpose-built for Dwolla, making it simple to ingest data, sync it across systems, and deliver it anywhere — all with no coding required. Nexla turns API-sourced data into ready-to-use, reusable data products and makes it easy to send data to Dwolla or any other destination. With comprehensive monitoring, lineage tracking, and access controls, Nexla keeps your Dwolla workflows fast, secure, and fully governed.

Features

Type: API

SourceDestination

  • Seamless API Integration: Connect to any endpoint as source or destination without coding, with automatic data product creation
  • Visual Composition & Chaining: Build complex integrations using visual templates, chain API calls, and compose workflows with data validation and filtering
  • API Proxy: Expose curated slices of your data securely with a secure and customizable API proxy that validates and transforms data on the fly
  • Request optimization with intelligent batching, retry, and caching to minimize API calls and costs

Prerequisites

Dwolla uses OAuth 2.0 with the Client Credentials flow for server-to-server API authentication. In this flow, your application exchanges its Client ID and Client Secret for a short-lived access token, which Nexla uses to make authenticated requests to the Dwolla API on your behalf.

Before creating a Dwolla credential in Nexla, you must register a Dwolla application and obtain your Client ID and Client Secret. Follow the steps below to complete this setup.

Register a Dwolla Application and Obtain Credentials

  1. Sign in to your Dwolla account at the Dwolla Dashboard. If you are setting up a sandbox integration for testing, sign in to the Dwolla Sandbox Dashboard instead.

  2. Navigate to Applications in the left-hand sidebar of the Dashboard.

  3. Click Create Application (or select your existing application if one has already been created). The Sandbox environment automatically provides a pre-created application when you register.

  4. Give your application a descriptive name that helps identify its purpose (for example, "Nexla Integration").

  5. Once the application is created or selected, you will see the Client ID (sometimes labeled "App Key") and Client Secret (sometimes labeled "App Secret") for the application. Copy both values and store them securely—you will need them when creating the Dwolla credential in Nexla.

Important

Your Client Secret is sensitive and should be kept confidential. Do not share it publicly or store it in version control. Dwolla access tokens are short-lived (valid for 1 hour); Nexla automatically handles token renewal using your stored client credentials.

Choose Your API Environment

Dwolla provides two API environments:

  • Sandbox (https://api-sandbox.dwolla.com): A risk-free testing environment that mirrors production behavior. Use this environment to develop and test your integration before going live.

  • Production (https://api.dwolla.com): The live environment for real money movement. Use this environment only after your integration has been validated in Sandbox.

Your Client ID and Client Secret are environment-specific. The credentials obtained from the Sandbox Dashboard are only valid against the Sandbox API, and production credentials are only valid against the Production API. For additional details about Dwolla API environments, refer to the Dwolla Developer Documentation.

Authenticate

Credentials required

Server-to-server OAuth2 authentication using client credentials flow. Dwolla issues access tokens for secure API access.

FieldRequiredSecretDescription
Client IDYesNoA unique public identifier assigned to your application
Client SecretYesYesA confidential password provided alongside the client ID
Base URLYesNoDwolla API environment endpoint (sandbox or production). Allowed values: Sandbox; Production

Create a credential in Nexla

  1. After selecting the data source/destination type, click the Add Credential tile to open the Add New Credential overlay.

  2. Enter a name for the credential in the Credential Name field and a short, meaningful description in the Credential Description field.

    Nexla connects to the Dwolla API using the OAuth 2.0 Client Credentials flow. This is a server-to-server authentication method in which Nexla exchanges your application's Client ID and Client Secret for a Bearer access token, which is then used to authenticate all subsequent API requests.

  3. Enter your Dwolla application's Client ID in the Client ID field. This is the unique public identifier assigned to your application and can be found on the Applications page of your Dwolla Dashboard.

  4. Enter your Dwolla application's Client Secret in the Client Secret field. This is the confidential password associated with your Client ID. This value is masked after entry and stored securely by Nexla.

    Your Client Secret should be treated as a password. Dwolla issues this value when your application is created. If you have lost your Client Secret, you can regenerate it from the Applications page of your Dwolla Dashboard—note that this will invalidate the previous secret.

  5. Select the Dwolla API environment that this credential should connect to from the Base URL field:

    • Sandbox (https://api-sandbox.dwolla.com): Select this option for development and testing.
    • Production (https://api.dwolla.com): Select this option for live production workflows.

    The default value is the Sandbox URL. Ensure you select the environment that matches the credentials you obtained from the Dwolla Dashboard.

  6. Click the Save button at the bottom of the overlay. The newly added credential will now appear in a tile on the Authenticate screen during data source/destination creation and can be selected for use with a new data source or destination.

Use as a data source

To create a new data flow, navigate to the Integrate section, and click the New Data Flow button. Select the Dwolla connector tile, then select the credential that will be used to connect to the Dwolla instance, and click Next; or, create a new Dwolla credential for use in this flow.

Endpoint templates

Nexla provides pre-built templates that can be used to rapidly configure data sources to ingest data from common Dwolla endpoints. Select the endpoint from which this source will fetch data from the Endpoint pulldown menu. Available endpoint templates are listed in the expandable boxes below. Click on an endpoint to see more information about it and how to configure your data source for this endpoint.

Retrieve account details

Retrieves detailed information for a specific Dwolla account by its account ID. Use this endpoint to fetch account-level data such as name and account status for a known Dwolla account.

  • Enter the Dwolla Account ID in the Account ID field. This is the unique identifier for the Dwolla account you want to retrieve. You can find account IDs in the Dwolla Dashboard under your account overview, or by listing accounts programmatically via the Dwolla API.

  • This endpoint returns a single account record and does not paginate. No additional pagination settings are required.

For complete details on the account object returned by this endpoint, refer to the Dwolla Accounts API reference.

List and search account transfers

Retrieves a paginated list of transfers for a specific Dwolla account, with optional filtering by date range, amount range, status, and correlation ID. Use this endpoint to pull transfer history for reporting, reconciliation, or auditing purposes.

  • Enter the Dwolla Account ID in the Account ID field. This is the unique identifier for the account whose transfers you want to retrieve.
  • Optionally, apply one or more filters to narrow the results:

    • Search: Enter a search term to filter transfers by customer name or other searchable attributes.
    • Start Amount: Enter the minimum transfer amount (in USD) to include in results.
    • End Amount: Enter the maximum transfer amount (in USD) to include in results.
    • Start Date: Enter the earliest transfer creation date to include, in yyyy-MM-dd format (for example, 2024-01-01).
    • End Date: Enter the latest transfer creation date to include, in yyyy-MM-dd format.
    • Status: Filter by transfer status. Valid values include pending, processed, failed, and cancelled.
    • Correlation ID: Enter a correlation ID to retrieve only transfers that were tagged with that ID at creation time. Correlation IDs are optional identifiers your application can attach to transfers for internal tracking.
  • This endpoint uses offset-based pagination and will automatically retrieve additional pages of results as needed. The default page size is 25 records.

For complete details on transfer filtering parameters and the transfer object structure, refer to the Dwolla Transfers API reference.

List funding sources for an account

Retrieves a list of all funding sources (bank accounts) associated with a specific Dwolla account. Use this endpoint to get a complete view of the bank accounts linked to an account for payment operations, auditing, or customer service purposes.

  • Enter the Dwolla Account ID in the Account ID field. This is the unique identifier for the account whose funding sources you want to list.
  • Optionally, set the Removed parameter to control whether removed funding sources are included in the response:

    • Set to false (the default) to return only active funding sources.
    • Set to true to include funding sources that have been removed.
  • This endpoint uses offset-based pagination and will automatically retrieve additional pages as needed.

For complete details on the funding source object returned by this endpoint, refer to the Dwolla Funding Sources API reference.

List and search customers

Retrieves a paginated list of customers in your Dwolla account, with optional filtering by search term and status. Use this endpoint to sync customer records into your data pipeline for analytics, compliance, or CRM integrations.

  • Optionally, apply one or more of the following filters:

    • Search: Enter a search term to filter customers by name, email, or business name.
    • Status: Filter by customer status. Common values include unverified, verified, suspended, and deactivated.
  • This endpoint uses offset-based pagination (default page size: 25) and will automatically retrieve additional pages as needed.

Customers in Dwolla represent end users (individuals or businesses) who participate in payment flows. The status field reflects their identity verification state. For complete details, refer to the Dwolla Customers API reference.

Retrieve a customer

Retrieves detailed profile information for a specific Dwolla customer by their customer ID. Use this endpoint when you need to fetch the full record for a single known customer.

  • Enter the Dwolla Customer ID in the Customer ID field. Customer IDs can be obtained from the "List and search customers" endpoint or from the Dwolla Dashboard.
  • This endpoint returns a single customer record and does not paginate.

For complete details on the customer object, refer to the Dwolla Customers API reference.

List documents for customer

Returns a list of identity verification documents that have been uploaded for a specific customer. Use this endpoint to monitor document upload status as part of customer KYC (Know Your Customer) verification workflows.

  • Enter the Dwolla Customer ID in the Customer ID field. This is the unique identifier for the customer whose documents you want to list.
  • This endpoint returns all documents for the specified customer and does not paginate.

Documents are required for verifying certain customer types in Dwolla (for example, personal verified customers and business verified customers). For complete details, refer to the Dwolla Documents API reference.

List documents for beneficial owner

Returns a list of identity verification documents uploaded for a specific beneficial owner. Use this endpoint in compliance workflows for business customers that require beneficial ownership certification.

  • Enter the Dwolla Beneficial Owner ID in the Owner ID field. This is the unique identifier for the beneficial owner record. Beneficial owner IDs can be retrieved from the Dwolla API after listing beneficial owners for a business customer.
  • This endpoint returns all documents for the specified beneficial owner and does not paginate.

Beneficial ownership documentation is required for business verified customers as part of Dwolla's regulatory compliance requirements. For complete details, refer to the Dwolla Documents API reference.

List available exchange connections

Returns a list of available open banking exchange connections for a specific customer. Exchange connections represent bank account verification integrations through Dwolla's open banking partners (such as Plaid or MX), enabling instant account verification.

  • Enter the Dwolla Customer ID in the Customer ID field. This is the unique identifier for the customer whose exchange connections you want to list.
  • This endpoint returns all exchange connections for the specified customer and does not paginate.

For complete details on exchange connections, refer to the Dwolla Exchanges API reference.

List exchange partners

Returns a list of all available open banking exchange partners supported by your Dwolla integration. Use this endpoint to discover which open banking providers (such as Plaid, MX, or Finicity) are available for account verification in your environment.

  • No parameters are required for this endpoint. It returns all exchange partners available to your Dwolla account.
  • This endpoint returns a flat list and does not paginate.

For complete details on exchange partners, refer to the Dwolla Exchanges API reference.

List exchanges for a customer

Returns a list of open banking exchanges associated with a specific customer. An exchange represents an active bank account verification session linked to a customer through a specific exchange partner.

  • Enter the Dwolla Customer ID in the Customer ID field. This is the unique identifier for the customer whose exchanges you want to list.
  • This endpoint returns all exchanges for the specified customer and does not paginate.

For complete details on customer exchanges, refer to the Dwolla Exchanges API reference.

List exchanges for an account

Returns a list of all open banking exchanges associated with the authenticated Dwolla account. Use this endpoint to get a high-level view of all exchange integrations active across your platform.

  • No parameters are required. This endpoint returns all exchanges for the authenticated account and does not paginate.

For complete details, refer to the Dwolla Exchanges API reference.

Retrieve a funding source

Retrieves the full details for a specific funding source (bank account) by its ID. Use this endpoint when you need to fetch the complete record for a known funding source, such as account name, type, status, and bank details.

  • Enter the Dwolla Funding Source ID in the Funding Source ID field. Funding source IDs can be obtained from the "List funding sources for an account" endpoint or from the Dwolla Dashboard.
  • This endpoint returns a single record and does not paginate.

For complete details on the funding source object, refer to the Dwolla Funding Sources API reference.

Retrieve funding source balance

Retrieves the current balance for a specific Dwolla Balance funding source. This endpoint applies to Dwolla Balance funding sources (digital wallet accounts held on the Dwolla platform), not to external bank accounts.

  • Enter the Dwolla Funding Source ID in the Funding Source ID field. This must be the ID of a Dwolla Balance funding source. You can identify balance funding sources by their type: balance attribute when listing funding sources.
  • This endpoint returns a single balance record and does not paginate.

For complete details on the balance response, refer to the Dwolla Funding Sources API reference.

Retrieve VAN account and routing numbers

Retrieves the virtual account number (VAN) and routing number for a specific funding source. Dwolla can provision virtual account and routing numbers for Dwolla Balance funding sources, enabling external parties to send ACH transfers directly to a Dwolla Balance.

  • Enter the Dwolla Funding Source ID in the Funding Source ID field. This must be a funding source that has been provisioned with VAN/routing numbers.
  • This endpoint returns a single record and does not paginate.

For complete details on VAN provisioning and the ACH routing response, refer to the Dwolla Funding Sources API reference.

Retrieve KBA Questions

Retrieves the knowledge-based authentication (KBA) questions for an active KBA session. KBA is one of the identity verification methods Dwolla uses for verifying personal customers. This endpoint returns the set of questions that the customer must answer to complete KBA verification.

  • Enter the KBA Session ID in the KBA ID field. This ID is returned when a KBA session is initiated via the "Initiate a KBA Session" endpoint. KBA sessions are time-sensitive and must be completed promptly after initiation.
  • This endpoint returns a single set of KBA questions and does not paginate.

For complete details on KBA sessions and question formats, refer to the Dwolla KBA API reference.

Retrieve a Mass Payment

Retrieves details about a specific mass payment by its ID. Mass payments in Dwolla allow you to disburse funds to many recipients simultaneously with a single API request. Use this endpoint to check the status and details of a previously initiated mass payment.

  • Enter the Mass Payment ID in the Mass Payment ID field. This ID is returned when a mass payment is created via the Dwolla API. It can also be found in the Dwolla Dashboard under the Mass Payments section.
  • This endpoint returns a single mass payment record and does not paginate.

For complete details on the mass payment object and status values, refer to the Dwolla Mass Payments API reference.

Retrieve a Transfer

Retrieves detailed information about a specific transfer by its ID. Use this endpoint to check the status, amount, funding sources, and other details of a single known transfer.

  • Enter the Transfer ID in the Transfer ID field. Transfer IDs are returned when a transfer is initiated and can also be retrieved by listing transfers for an account or customer.
  • This endpoint returns a single transfer record and does not paginate.

Transfer statuses include pending, processed, failed, and cancelled. For complete details on the transfer object, refer to the Dwolla Transfers API reference.

List Customer Transfers

Returns a paginated list of transfers for a specified customer. Use this endpoint to retrieve all transfer history for a single customer, with optional filtering by correlation ID. This is useful for customer-level reconciliation, reporting, and customer service workflows.

  • Enter the Dwolla Customer ID in the Customer ID field. This is the unique identifier for the customer whose transfers you want to list.
  • Optionally, enter a Correlation ID to filter results to only transfers that were tagged with that identifier at creation time. Correlation IDs are optional customer-defined tags that can be attached to transfers for internal tracking and reconciliation.
  • This endpoint uses cursor-based pagination (following the next link in responses) and will automatically retrieve additional pages as needed.

For complete details on the customer transfers endpoint and response structure, refer to the Dwolla Customers API reference.

Once the selected endpoint template has been configured, click the Test button to the right of the endpoint selection menu to retrieve a sample of the data that will be fetched. Sample data will be displayed in the Endpoint Test Result panel on the right, allowing you to verify that the source is configured correctly before saving.

Manual configuration

Dwolla data sources can also be manually configured to ingest data from any valid Dwolla API endpoint, including endpoints not covered by the pre-built templates, chained API calls, or custom request parameters. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, endpoint URL, date/time and lookup macros, path to data, metadata, and request headers.

Dwolla endpoint URLs use the base https://api-sandbox.dwolla.com (Sandbox) or https://api.dwolla.com (Production); all endpoints require HTTPS. Nexla automatically includes Bearer token authentication, so the Authorization header does not need to be set manually — an optional Accept header (e.g., Accept:application/vnd.dwolla.v1.hal+json) can be used to control the response content type. Most list endpoints return records nested under _embedded in HAL format, so set Path to Data to $._embedded.{resource-type}[*] (for example, $._embedded.customers[*], $._embedded.transfers[*], or $._embedded.funding-sources[*]); for single-resource endpoints, use $. Set Path to Metadata to $._links or $.total to preserve pagination links or record counts alongside each record. Dwolla date parameters (such as startDate/endDate on the transfers endpoint) use the yyyy-MM-dd format for Date/Time macros.

Once all of the relevant settings have been configured, click the Create button in the upper right corner of the screen to save and create the new Dwolla data source. Nexla will now begin ingesting data from the configured endpoint and will organize any data that it finds into one or more Nexsets.

Use as a destination

Click the + icon on the Nexset that will be sent to the Dwolla destination, and select the Send to Destination option from the menu. Select the Dwolla connector from the list of available destination connectors, then select the credential that will be used to connect to the Dwolla account, and click Next; or, create a new Dwolla credential for use in this flow.

Endpoint templates

Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common Dwolla API endpoints. Select the endpoint to which data will be sent from the Endpoint pulldown menu. Then, click on the template in the list below to expand it, and follow the instructions to configure additional endpoint settings.

Create a funding source for an account

Creates a new funding source (bank account) linked to an existing Dwolla account. Use this endpoint to programmatically add bank accounts to your Dwolla account for use in payment operations. This is typically used when onboarding new bank accounts for ACH transfers.

  • Ensure the Nexset data contains the required fields for creating a funding source. At minimum, the Dwolla API requires the routing number, account number, bank account type (checking or savings), and a name for the funding source.
  • This endpoint sends a POST request to /funding-sources with the funding source details as a JSON payload. Nexla will send each record in the Nexset as a separate API call.

For complete details on required and optional fields for creating a funding source, refer to the Dwolla Funding Sources API reference.

Certify beneficial ownership

Certifies the beneficial ownership status for a business customer. This is a required compliance step for business verified customers in Dwolla. Use this endpoint after beneficial owner records have been created and verified to complete the business verification process.

  • The endpoint URL includes a Customer ID path parameter. Ensure the Nexset data contains the Customer ID for the business customer whose beneficial ownership is being certified. The Customer ID is used to construct the destination URL in the format:

    • {'/customers/{id}/beneficial-ownership'}
  • The request body should contain the certification status. Dwolla expects a JSON body with a status field set to certified to complete certification.

Beneficial ownership certification is required for business verified customers under U.S. FinCEN regulations. This step must be completed before the customer can initiate transfers. For complete details, refer to the Dwolla Customers API reference.

Create a client token

Creates a short-lived client token for secure client-side interactions with the Dwolla API. Client tokens are used by Dwolla's Drop-in Components and JavaScript library to perform sensitive operations (such as collecting bank account information) directly from the end user's browser without exposing your server-side credentials.

  • Ensure the Nexset data contains the required fields for generating a client token. Dwolla requires an action field specifying the permitted client-side operation (for example, customer.create or customer.update), and optionally a _links object identifying the customer the token applies to.
  • This endpoint sends a POST request to /client-tokens. Client tokens are single-use and expire after a short duration.

Client tokens are intended for use with Dwolla's front-end components and JavaScript library. For complete details on supported actions and request payload structure, refer to the Dwolla Client Tokens API reference.

Create a customer

Creates a new customer record in Dwolla. Customers represent the end users (individuals or businesses) who participate in payment workflows on your platform. Use this endpoint to programmatically onboard new customers as part of your user registration or onboarding flow.

  • The required fields vary depending on the type of customer being created:

    • Unverified customers: Require only firstName, lastName, and email. Unverified customers have lower transfer limits.
    • Verified personal customers: Require additional identity fields including address1, city, state, postalCode, dateOfBirth, and ssn (last 4 digits or full SSN depending on verification needs).
    • Verified business customers: Require business-specific fields including businessName, businessType, ein, and controller information.
  • Ensure the Nexset records include all required fields for the target customer type before sending to this destination.

Dwolla enforces uniqueness on email addresses for customers. Attempting to create a customer with an email already in use will return an error. For complete details on customer types and required fields, refer to the Dwolla Customers API reference.

Update a customer

Updates profile information for an existing Dwolla customer. Use this endpoint to modify customer data such as contact information, or to upgrade a customer from unverified to verified status by providing additional identity verification information.

  • The endpoint URL includes a Customer ID path parameter. Ensure the Nexset data contains the Customer ID of the customer to be updated. The Customer ID is used to construct the destination URL in the format:

    • {'/customers/{id}'}
  • Include only the fields that need to be updated in the request body. The Dwolla API uses a POST method for customer updates (not PATCH), and accepts partial updates.

Updating a customer to a verified status requires providing complete identity information. The available fields and requirements depend on the customer's current status. For complete details, refer to the Dwolla Customers API reference.

Update or remove a funding source

Updates the name of an existing funding source or marks a funding source as removed. Use this endpoint to rename a bank account associated with a Dwolla account, or to deactivate a funding source that is no longer needed.

  • The endpoint URL includes a Funding Source ID path parameter. Ensure the Nexset data contains the Funding Source ID of the funding source to be updated or removed. The Funding Source ID is used to construct the destination URL in the format:

    • {'/funding-sources/{id}'}
  • To update the funding source name, include a name field in the request body with the new name.

  • To remove (deactivate) the funding source, include "removed": true in the request body. Removed funding sources cannot be used for new transfers but their history is preserved.

Removing a funding source is a permanent action that cannot be reversed. For complete details, refer to the Dwolla Funding Sources API reference.

Initiate a KBA Session

Initiates a knowledge-based authentication (KBA) session for a customer as part of the identity verification process. KBA presents the customer with multiple-choice questions derived from credit bureau data to verify their identity without requiring document uploads.

  • The endpoint URL includes a Customer ID path parameter. Ensure the Nexset data contains the Customer ID of the customer for whom the KBA session is being initiated. The Customer ID is used to construct the destination URL in the format:

    • {'/customers/{id}/kba'}
  • No additional fields are required in the request body for initiating a KBA session. The response will contain a KBA session ID and the set of questions for the customer to answer.

KBA sessions are time-sensitive and must be completed promptly. The KBA session ID returned by this endpoint is used with the "Retrieve KBA Questions" and "Verify KBA Questions" endpoints to complete the verification. For complete details, refer to the Dwolla KBA API reference.

Verify KBA Questions

Verifies a customer's answers to KBA questions to complete their identity verification. This is the final step in the KBA verification flow, after a KBA session has been initiated and questions have been retrieved and presented to the customer.

  • The endpoint URL includes a KBA ID path parameter. Ensure the Nexset data contains the KBA ID from the initiated KBA session. The KBA ID is used to construct the destination URL in the format:

    • {'/kba/{kbaId}'}
  • The request body must contain the customer's answers to the KBA questions in the format specified by Dwolla. Each answer is associated with a question ID and the selected answer ID.

A customer has a limited number of attempts to pass KBA verification. Failure to pass within the allowed attempts will result in the customer requiring an alternative verification method. For complete details, refer to the Dwolla KBA API reference.

Initiate a Transfer

Initiates a money transfer between two Dwolla funding sources. This is the core payment operation in Dwolla, enabling ACH bank-to-bank transfers between customers. Use this endpoint to programmatically send or collect funds as part of your payment workflows.

  • The Nexset records must contain the required fields for initiating a transfer:

    • _links.source.href: The URL of the source funding source (the account being debited). Example: https://api.dwolla.com/funding-sources/{source-id}.
    • _links.destination.href: The URL of the destination funding source (the account being credited). Example: https://api.dwolla.com/funding-sources/{destination-id}.
    • amount.value: The transfer amount as a string (for example, "10.00").
    • amount.currency: The currency code (must be "USD" for Dwolla).
  • Optionally, include a correlationId field to tag the transfer with an internal reference identifier for tracking and reconciliation.
  • For Same Day ACH transfers, include "achDetails": {""{""}"clearingCode"": ""SD""}" in the request body.

Transfers in Dwolla are asynchronous. After initiation, the transfer will move through processing states (pendingprocessed or failed). Use webhooks or the "Retrieve a Transfer" endpoint to monitor transfer status. For complete details, refer to the Dwolla Transfers API reference.

Cancel a Transfer

Cancels a pending transfer before it has been processed. Use this endpoint when a transfer needs to be voided after initiation but before it clears. Only transfers in a pending status can be cancelled.

  • The endpoint URL includes a Transfer ID path parameter. Ensure the Nexset data contains the Transfer ID of the transfer to be cancelled. The Transfer ID is used to construct the destination URL in the format:

    • {'/transfers/{id}'}
  • The request body must contain "status": "cancelled" to indicate that the transfer should be cancelled.

:::warning Important Transfer cancellation is only available while the transfer is in pending status. Once a transfer moves to processed, it cannot be cancelled and must be reversed with a new transfer in the opposite direction. :::

For complete details on transfer cancellation and status transitions, refer to the Dwolla Transfers API reference.

Manual configuration

Dwolla destinations can also be manually configured to send data to any valid Dwolla API endpoint, including write operations not covered by the pre-built templates, such as creating beneficial owner records, uploading documents, or interacting with other Dwolla API resources. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, data format, endpoint URL, request headers, attribute exclusions, record batching, and response webhooks.

Dwolla uses POST for creating resources and most write operations (PUT for certain updates); requests and responses use JSON (application/json or application/vnd.dwolla.v1.hal+json). Endpoint URLs follow https://api-sandbox.dwolla.com/{endpoint_path} (Sandbox) or https://api.dwolla.com/{endpoint_path} (Production), with the target resource ID appended for operations on a specific resource (for example, https://api.dwolla.com/customers/{customer-id}). Nexla automatically includes Bearer token authentication, so the Authorization header does not need to be set manually; consider adding an Idempotency-Key header for transfer creation to prevent duplicate transfers on retry.

Save & activate

Once all endpoint settings have been configured, click the Done button in the upper right corner of the screen to save and create the destination. To send the data to the configured Dwolla endpoint, open the destination resource menu, and select Activate.

The Nexset data will not be sent to the Dwolla endpoint until the destination is activated. Destinations can be activated immediately or at a later time, providing full control over data movement.