Advanced Implementation

The following are optional implementation steps that can be taken to optimize the branding, streamline the end customer experience, and provide access to richer functionality.

Theming

To match your branding, you can customize colors, logos, fonts, etc. Refer to our theming guide.

The White-Label App can be styled by passing a theme object to the settings-json attribute.

You can also demo these changes using the branding page in your Sandbox Dashboard.

Pre filling end-user information

1-2 days

If you have access to end customer information that you can share in order to streamline their onboarding onto banking and can reduce the friction of submitting the application, we allow you to provide it and we will use it to pre-fill the end customer’s application form. To support that, you will have to expose an API endpoint that Unit will call when seeing an end user (identified by their JWT subject) for the first time.

Unit will make an HTTP request to this endpoint with a JWT token associated with this user in the Authorization header before initiating the end customer application process. The server will need to return the End User Configuration resource. The response must include the data, type: whiteLabelAppEndUserConfig and attributes keys.

Please contact Unit in order to configure the endpoint.

Request example:

curl -X GET 'https://yourdomain.com/unit/application-form-prefill' \
-H "Authorization: Bearer ${JWT Token}"

Inviting additional users to Banking

1-2 days

In order to allow more than one end user of yours access to the same banking experience (e.g. two employees of the same business, represented as two separate JWT subjects on your platform), The user that applies for banking, once approved, needs to be able to invite additional users.

Note this is only available for business customers.

Since Unit isn’t familiar with the relationship between users on your platform, we rely on you to tell us who the users are that another user may grant access to, by providing an API endpoint we can call, that returns a list of users, represented as JWTs.

Unit relies on you to manage and define user roles effectively. Below are the responsibilities and requirements for user management and role assignment within the Ready-to-Launch Banking App.

Role Assignment via JWT Token​

Each user in Ready-to-Launch Banking has an assigned role, which your backend is responsible for managing. The end customer can create users in the White-Label App and assign roles to them. To update a user’s role, include the new role in a unitRole attribute in the JWT token. Unit validates the JWT token on a user login: if a role is provided in the token, Unit will update the user’s role in the White-Label App accordingly. If a role is not provided in the JWT token, Unit will retain the last role that was sent.

Allowed Roles​

The only allowed roles are Admin and ReadOnly. If you include a role other than these in the JWT token, the request will fail.

Managing End Users​

The White-Label App provides functionality for creating, removing, and listing users within the app. The customer can manage all types of users. Admin can only manage users who has ReadOnly permissions. To enable these capabilities, you will need to implement an API endpoint that returns a list of your app's existing end-users.

API Endpoint Requirements​

Request:​ Unit will send an HTTP request to the API endpoint that you will implement, including a JWT token in the Authorization header.

curl -X GET 'https://yourdomain.com/unit/users' \
-H "Authorization: Bearer ${JWT Token}"

Response:​ The API must return a list of end-users associated with the customer resource created at Unit. Each end-user in the list should be represented as an object and include their unique JWT subject. By adhering to these guidelines, you will ensure consistent user role management within the White-Label App.

fullName

FullName

Full name of the end user.

email

string

Email address of the end user.

phone

Phone

Phone number of the end user.

jwtSubject

string

Unique string identifying the end user.

unitRole

string

The role of the end user. Can be either Admin or ReadOnly.

bankingPageURLOptional

string

Optional. URL to the banking page on the client’s website (For linking via email).

Example whiteLabelAppEndUser type:

[
  {
    "data": {
      "type": "whiteLabelAppEndUser",
      "attributes": {
        "fullName": {
          "first": "Peter",
          "last": "Parker"
        },
        "email": "peter.parker@parker.com",
        "phone": {
          "countryCode": "1",
          "number": "2345678888"
        },
        "jwtSubject": "test",
        "unitRole": "Admin"
      }
    }
  },
  {
    "data": {
      "type": "whiteLabelAppEndUser",
      "attributes": {
        "fullName": {
          "first": "April",
          "last": "Oneil"
        },
        "email": "april.oneil@parker.com",
        "phone": {
          "countryCode": "1",
          "number": "2345678899"
        },
        "jwtSubject": "test2",
        "unitRole": "ReadOnly"
      }
    }
  }
]

After the endpoint has been implemented on your side, please contact Unit in order to configure it.

Custom JWT Authentication

3-4 hours

Unit can rely on a custom implementation of JWT token that adheres to the specifications outlined in RFC 7519.

In this case you should provide Unit with a public key that will be used to validate the token.

The token must be signed using the RS256 algorithm and must include the following claims:

Claim	Description
sub	A unique identifier for the end-user
exp	The expiration time of the token
iss	The issuer of the token

JWT Authentication Troubleshooting:

If you receive an error, ensure the following:

• You're using the Sandbox (ui.s.unit.sh) or Production (ui.unit.co) script matching your environment.
• Decode your token. The iss matches the Issuer you configured in the Dashboard and the sub value is a string (stable user id). The token is still valid, with an exp in the future. The header includes alg: RS256 and a valid kid.
• The Public Key was entered into the Unit Dashboard correctly, and is the correct one for the provided token. The kid in the JWT matches one in your uploaded Public Key or JWKs.
• The cache has been cleared (localStorage keys unitCustomerToken and unitVerifiedCustomerToken).
• The jwt-token value is present before the component initializes.

Integrate the embedded application form within partner registration

30 minutes

To embed the application form as part of your company's application flow (separately from the full banking experience), use the unit-elements-application-form component. This allows you to embed only the onboarding flow, sending the customer back to your application and not automatically transitioning to the customer view after application submission.

To embed the application form, use the unit-elements-application-form component with the jwt-token attribute:

<unit-elements-application-form jwt-token="{{JwtToken}}">
</unit-elements-application-form>

Key differences from unit-elements-white-label-app

• Application-only focus: The unit-elements-application-form component keeps users on the application form and does not automatically transition to the customer banking view after application submission.
• Simplified embedding: Only requires the jwt-token attribute.
• Onboarding flow: Ideal for clients who want to embed only the onboarding/application process and handle post-application flows separately.

Component client-side events

The unit-elements-white-label-app and unit-elements-application-form components support custom events that enable you to respond to user interactions and component lifecycle events. You can add event listeners to handle these events and integrate them with your application logic.

Event Name	Description	Detail
unitApplicationFormCompleted	Occurs when an application form is filled/completed	ApplicationForm

This event works for application form with statuses: AwaitingDocuments, PendingReview, Approved, Denied, Pending.

Example usage:

<unit-elements-application-form jwt-token="{{JwtToken}}">
</unit-elements-application-form>
<script>
  document
    .querySelector("unit-elements-application-form")
    .addEventListener("unitApplicationFormCompleted", async function (e) {
      const applicationForm = await e.detail;
      const status = applicationForm.data.attributes.applicationStatus; // one of `AwaitingDocuments, PendingReview, Approved, Denied, Pending`
      // Handle the application form completion based on status
    });
</script>

For additional event details and examples, see White-Label App events.

Unified Onboarding

2-3 hours

Unified Onboarding is a feature that orchestrates customer onboarding across Unit Banking and external payment processors through a single, coordinated flow. It creates a unified application that tracks the onboarding status across multiple systems, providing a seamless experience for customers who need to be onboarded to both Unit and payment processing services simultaneously.

What It Enables

• Single Application Flow: Create one unified application that automatically initiates onboarding in both Unit Banking and configured payment processors.
• Centralized Status Tracking: Monitor the onboarding progress across all systems through a single unified application status.
• Automated Document Management: Documents required by external systems are automatically tracked and synced.
• Event-Driven Synchronization: Status updates from external systems (via webhooks) automatically update the unified application status.
• Support for Business and Sole Proprietor Customers: Full support for both business entities and sole proprietors.

When to Use

Use Unified Onboarding when:

1. Your customers need access to both Unit Banking services AND payment processing capabilities.
2. You want to provide a streamlined onboarding experience without requiring separate application flows.
3. You need centralized visibility into onboarding progress across multiple financial service providers.

Application Types

Unified Onboarding supports two customer types:

Type	Resource Type	Use Case
Business	businessUnifiedApplication	LLCs, Corporations, and Partnerships
Sole Proprietor	solePropUnifiedApplication	Individual business owners operating as sole proprietors

Application Status Lifecycle

Unified Application Statuses

Status	Description
Pending	Application created, initial processing not yet started
AwaitingDocuments	One or more child applications require document uploads
Submitted	Application submitted for review
InReview	Documents or application under review by external systems
Approved	All child applications approved
PartiallyApproved	Some child applications approved, others pending/rejected
Rejected	Application rejected by one or more systems
Cancelled	Application cancelled
Error	Error occurred during processing

Child Application Statuses

Each child application (Unit, payment processor) has its own status that contributes to the overall unified status:

Status	Description
Pending	Child application created, awaiting processing
AwaitingDocuments	Documents required or previously submitted documents were invalid
InReview	Documents pending review by the external system
Approved	Child application approved
Rejected	Child application rejected

Payment Processor Settings Configuration

To enable Unified Onboarding with payment processors, you must configure the payment processor settings in your organization's settings.

Configuring Payment Processor Settings

Payment processor settings are configured through the Unit Dashboard.

To configure your payment processor settings:

1. Navigate to Settings from the top menu under the Developer section.
2. Select the Payment Processing tab.
3. Select your Vendor from the dropdown (e.g., Stripe).
4. Enter your API key (your payment processor secret key).
5. Enter your Webhook secret (your payment processor webhook signing secret).
6. Optionally, configure Hostname and Files Hostname for custom configurations.
7. Select the applicable Business profile MCC code for your use case.
8. Click Save to apply your settings.

Required Settings

Setting	Required	Description
Vendor	Yes	Select your payment processor (e.g., Stripe).
API key	Yes	Your payment processor API key (secret key). This is required for Unit to create and manage accounts on your behalf.
Webhook secret	Yes	Your payment processor webhook signing secret. This is required to verify incoming webhook events and keep application status synchronized.
Hostname	No	Custom API hostname (for testing or custom configurations). Defaults to the payment processor's production API.
Files Hostname	No	Custom hostname for file uploads.
Business profile MCC code	Yes	The Merchant Category Code for card transactions.

Supported Payment Processors

Currently, the following payment processors are supported:

Processor	Type Code	Description
Stripe	r	Stripe Connect for payment processing

Additional payment processors will be added based on partner request.

How Payment Processor Integration Works

1. Application Creation: When a unified application is created through the application form, Unit automatically creates an account with the configured payment processor.
2. Status Synchronization: Payment processor webhook events update the child application status in real-time.
3. Document Requirements: When the payment processor requires identity verification documents, the child application status changes to AwaitingDocuments.
4. Verification Flow: Documents can be uploaded through the unified onboarding document upload flow.

Unified Onboarding Webhook Events

To receive notifications about unified application status changes, configure a webhook endpoint in your organization settings. Unit will send webhook events when unified applications reach terminal or significant states.

Available Unified Onboarding Webhook Events

Event Type	Description
unifiedApplication.created	Fired when a new unified application is created
unifiedApplication.approved	Fired when all child applications are approved and the unified application reaches Approved status
unifiedApplication.rejected	Fired when the unified application is rejected
unifiedApplication.partiallyApproved	Fired when some child applications are approved but others are pending or rejected

To receive these events, ensure your organization has a webhook endpoint configured that subscribes to unified application events. This allows your system to:

• Trigger downstream processes when onboarding completes successfully
• Notify internal teams when applications require attention
• Update your own systems with the latest application status
• Handle partial approvals where only some systems approved the application

Event Payload

Webhook events include the unified application details, including:

• Application ID
• Organization ID
• Current status
• Child application statuses
• Timestamps

Stripe API Key Permissions

If you are using a Stripe secret key, all permissions are granted by default. If you are using a Stripe restricted API key (recommended for production), the following permissions must be enabled:

For more information about Stripe permissions, see the Stripe Permissions Reference.

Creating a Restricted API Key

1. Navigate to Developers → API keys in your Stripe Dashboard.
2. Click Create restricted key.
3. Give your key a name (e.g., "Unit Unified Onboarding").
4. Set the following permissions:

Required Permissions

Resource Category	Resource	Permission Level
Connect	Accounts	Write
Connect	Persons	Write
Core	Files	Write

5. Click Create key and copy the restricted key to configure in your Unit payment processor settings.

Why These Permissions Are Needed

Permission	Purpose
Accounts (Write)	Create and update Stripe Connect accounts, retrieve account status and requirements, and set external bank accounts after Unit Banking approval.
Persons (Write)	Create and update persons (representatives and beneficial owners) on Connect accounts, and attach verification documents.
Files (Write)	Upload identity verification document files to Stripe.

Note: Write access in Stripe implicitly includes Read access, so enabling Write for Accounts, Persons, and Files covers all operations in the unified onboarding flow.

Required Stripe Webhook Events

The following Stripe webhook events must be enabled in your Stripe Dashboard (or via API) for the unified onboarding flow to function correctly. These events are used to synchronize the payment processor child application status in real-time.

Events Required for Unified Onboarding

Stripe Event Type	Purpose	Unified Onboarding Action
account.updated	Fired when account requirements or status change	Updates child application status based on current account requirements (e.g., pending verification, approved, has errors)
account.application.authorized	Fired when the Connect application is authorized	Initializes the payment processor child application with Pending status
person.created	Fired when a new person is added to an account	Evaluates person verification status and creates document requirements if needed
person.updated	Fired when a person's details or verification status change	Updates document status based on verification state: Unverified → document required, Pending → document pending review, Verified → document approved
person.deleted	Fired when a person is removed from an account	Evaluates impact on child application verification status

Configuring Webhook Events in Stripe

1. Navigate to Developers → Webhooks in your Stripe Dashboard.
2. Click Add endpoint and enter the webhook URL provided by Unit.
3. Under Events to send, select the events listed in the table above.
4. Copy the Signing secret and configure it as the Webhook secret in your Unit payment processor settings.

Webhook Events

2-3 hours

You may consume webhooks events to receive real-time notifications about your customers' activity on Ready to Launch Banking. Unit uses webhooks to notify your platform when an event occurs, such as when an application is denied, a customer is created, or a transaction is processed.

When one of these events occurs, an HTTP POST request is sent to your webhook's configured URL, allowing you to act upon it in real-time. This enables you to build responsive integrations, update your systems automatically, and provide better customer experiences.

Suggestion

Unit highly recommends that you make your webhook handlers Idempotent, to ensure events are only handled once on your end.

Setting Up Webhooks

To start receiving webhook events, you'll need to:

1. Implement an endpoint on your server to receive and process webhook payloads
2. Configure a webhook subscription using one of the methods below:
   • Sandbox Environment: Create your webhook subscription via the Unit Dashboard → DEVELOPER menu → Webhooks → Create
   • Production Environment: Contact your Unit solution engineer to help set up webhook subscriptions
3. Verify webhook signatures to ensure security and authenticity (see Securing your webhooks)

Unit sends POST requests to your webhook's URL from one of the following IP addresses:

Environment	IP Addresses
Sandbox	54.81.62.38 35.169.213.205 3.234.105.75
Live	3.209.193.26 54.156.65.95 54.165.224.37

Please note that these IP addresses are subject to change.

Suggestion

On production, webhooks that were unresponsive for 7 days will change status to Unavailable and will cease to receive events until they are re-enabled.

On sandbox, webhooks that were unresponsive for 2 days will be changed to status Unavailable.

Available Webhook Events for RTL Banking

Ready-to-Launch Banking clients can subscribe to the following webhook events:

application.created

Occurs when a new application is submitted. The userIds refers to the user IDs in your system.

Example application.created payload:

{
  "data": [
    {
      "id": "308",
      "type": "application.created",
      "attributes": {
        "userIds": ["user_12345"],
        "createdAt": "2025-12-14T19:56:29.223Z"
      }
    }
  ]
}

application.awaitingDocuments

Occurs when additional documents are required for an application. The userIds refers to the user IDs in your system.

Example application.awaitingDocuments payload:

{
  "data": [
    {
      "id": "313",
      "type": "application.awaitingDocuments",
      "attributes": {
        "userIds": ["user_12345"],
        "createdAt": "2025-12-14T20:21:22.000Z"
      }
    }
  ]
}

application.pendingReview

Occurs when an application is pending review. The userIds refers to the user IDs in your system.

Example application.pendingReview payload:

{
  "data": [
    {
      "id": "315",
      "type": "application.pendingReview",
      "attributes": {
        "userIds": ["user_12345"],
        "createdAt": "2025-12-14T20:25:00.000Z"
      }
    }
  ]
}

application.denied

Occurs when an application is rejected. The userIds refers to the user IDs in your system.

Example application.denied payload:

{
  "data": [
    {
      "id": "28",
      "type": "application.denied",
      "attributes": {
        "userIds": ["user_12345"],
        "createdAt": "2020-07-29T12:53:05.882Z"
      }
    }
  ]
}

application.canceled

Occurs when an application is canceled. The userIds refers to the user IDs in your system.

Example application.canceled payload:

{
  "data": [
    {
      "id": "314",
      "type": "application.canceled",
      "attributes": {
        "userIds": ["user_12345"],
        "createdAt": "2025-12-14T20:21:47.872Z"
      }
    }
  ]
}

customer.created

Occurs when a new customer record is established after application approval. The userIds array contains the user IDs from your system.

Example customer.created payload:

{
  "data": [
    {
      "id": "53",
      "type": "customer.created",
      "attributes": {
        "createdAt": "2020-07-29T12:53:05.882Z",
        "name": "Acme Corp",
        "userIds": ["user_12345"]
      },
      "relationships": {
        "customer": {
          "data": {
            "id": "10000",
            "type": "businessCustomer"
          }
        }
      }
    }
  ]
}

account.created

Occurs when a new deposit account is successfully created for a customer.

Example account.created payload:

{
  "data": [
    {
      "id": "269",
      "type": "account.created",
      "attributes": {
        "createdAt": "2021-04-13T07:40:43.813Z",
        "accountNumber": "1000000001",
        "routingNumber": "812345678"
      },
      "relationships": {
        "account": {
          "data": {
            "id": "10004",
            "type": "account"
          }
        },
        "customer": {
          "data": {
            "id": "10000",
            "type": "customer"
          }
        }
      }
    }
  ]
}

account.frozen

Occurs when account access is restricted.

Example account.frozen payload:

{
  "data": [
    {
      "id": "2354",
      "type": "account.frozen",
      "attributes": {
        "createdAt": "2021-12-08T07:43:13.813Z",
        "accountNumber": "1000000001",
        "routingNumber": "812345678"
      },
      "relationships": {
        "account": {
          "data": {
            "id": "10004",
            "type": "account"
          }
        },
        "customer": {
          "data": {
            "id": "10000",
            "type": "customer"
          }
        }
      }
    }
  ]
}

account.unfrozen

Occurs when account access is restored.

Example account.unfrozen payload:

{
  "data": [
    {
      "id": "2355",
      "type": "account.unfrozen",
      "attributes": {
        "createdAt": "2021-12-08T07:43:13.813Z",
        "accountNumber": "1000000001",
        "routingNumber": "812345678"
      },
      "relationships": {
        "account": {
          "data": {
            "id": "10004",
            "type": "account"
          }
        },
        "customer": {
          "data": {
            "id": "10000",
            "type": "customer"
          }
        }
      }
    }
  ]
}

account.closed

Occurs when an account is closed by the customer or Unit.

Example account.closed payload:

{
  "data": [
    {
      "id": "270",
      "type": "account.closed",
      "attributes": {
        "createdAt": "2021-04-13T07:40:43.813Z",
        "accountNumber": "1000000001",
        "routingNumber": "812345678"
      },
      "relationships": {
        "account": {
          "data": {
            "id": "10004",
            "type": "account"
          }
        },
        "customer": {
          "data": {
            "id": "10000",
            "type": "customer"
          }
        }
      }
    }
  ]
}

account.reopened

Occurs when a previously closed account is reopened.

Example account.reopened payload:

{
  "data": [
    {
      "id": "271",
      "type": "account.reopened",
      "attributes": {
        "createdAt": "2021-04-13T07:40:43.813Z",
        "accountNumber": "1000000001",
        "routingNumber": "812345678"
      },
      "relationships": {
        "account": {
          "data": {
            "id": "10004",
            "type": "account"
          }
        },
        "customer": {
          "data": {
            "id": "10000",
            "type": "customer"
          }
        }
      }
    }
  ]
}

card.created

Occurs when a new card is created for a customer.

Example card.created payload:

{
  "data": [
    {
      "id": "322",
      "type": "card.created",
      "attributes": {
        "cardType": "individualDebitCard",
        "createdAt": "2025-12-14T20:56:27.782Z"
      },
      "relationships": {
        "card": {
          "data": {
            "id": "39",
            "type": "card"
          }
        },
        "account": {
          "data": {
            "id": "10028",
            "type": "account"
          }
        },
        "customer": {
          "data": {
            "id": "10025",
            "type": "customer"
          }
        }
      }
    }
  ]
}

card.activated

Occurs when a card is activated for the first time.

Example card.activated payload:

{
  "data": [
    {
      "id": "323",
      "type": "card.activated",
      "attributes": {
        "cardType": "individualDebitCard",
        "createdAt": "2025-12-14T20:59:23.028Z"
      },
      "relationships": {
        "card": {
          "data": {
            "id": "39",
            "type": "card"
          }
        },
        "account": {
          "data": {
            "id": "10028",
            "type": "account"
          }
        },
        "customer": {
          "data": {
            "id": "10025",
            "type": "customer"
          }
        }
      }
    }
  ]
}

Suggestion

Enhanced Information Security documentation is required to access transaction webhooks. Contact your Customer Success Manager for more information about accessing transaction.

transaction.created

Occurs for all account transactions (deposits, withdrawals, transfers). The amount and balance are in cents.

Example transaction.created payload:

{
  "data": [
    {
      "id": "12345",
      "type": "transaction.created",
      "attributes": {
        "createdAt": "2021-06-02T10:15:22.123Z",
        "amount": 50000,
        "direction": "Credit",
        "type": "originatedAchTransaction",
        "balance": 150000
      },
      "relationships": {
        "account": {
          "data": {
            "id": "10004",
            "type": "account"
          }
        },
        "customer": {
          "data": {
            "id": "10000",
            "type": "customer"
          }
        },
        "transaction": {
          "data": {
            "id": "12345",
            "type": "originatedAchTransaction"
          }
        }
      }
    }
  ]
}

whiteLabelAppUser.created

Occurs when a new user is created in the White-Label App. The userId refers to the user ID in your system.

Example whiteLabelAppUser.created payload:

{
  "data": [
    {
      "id": "324",
      "type": "whiteLabelAppUser.created",
      "attributes": {
        "userId": "user_67890",
        "userRole": "ReadOnly",
        "createdAt": "2025-12-14T21:15:30.123Z",
        "initiatorUserId": "user_12345"
      },
      "relationships": {
        "customer": {
          "data": {
            "id": "10000",
            "type": "customer"
          }
        }
      }
    }
  ]
}

Attribute	Type	Description
userId	string	The user ID in your system.
userRole	string	The role assigned to the user. See Allowed Roles.
createdAt	string	The date and time the user was created.
initiatorUserId	string	Optional. The user ID of the user who initiated this action.

whiteLabelAppUser.disabled

Occurs when a user is disabled in the White-Label App. The userId refers to the user ID in your system.

Example whiteLabelAppUser.disabled payload:

{
  "data": [
    {
      "id": "325",
      "type": "whiteLabelAppUser.disabled",
      "attributes": {
        "userId": "user_67890",
        "userRole": "Admin",
        "createdAt": "2025-12-14T21:22:45.456Z",
        "initiatorUserId": "user_12345"
      },
      "relationships": {
        "customer": {
          "data": {
            "id": "10000",
            "type": "customer"
          }
        }
      }
    }
  ]
}

Attribute	Type	Description
userId	string	The user ID in your system.
userRole	string	The role of the user at the time of disabling. See Allowed Roles.
createdAt	string	The date and time the user was disabled.
initiatorUserId	string	Optional. The user ID of the user who initiated this action.

API Calls

Ready-to-Launch Banking provides several API endpoints to help you manage accounts, transactions, and payments.

Our API is available in two environments:

Name	Dashboard URL	API URL
Sandbox	https://app.s.unit.sh/	https://api.s.unit.sh/
Live	https://app.unit.co	https://api.unit.co/

Note

To be able to use the api, you'll first need to Create an API token for Ready-to-Launch APIs by contacting your Unit solution engineer to help set up an API token for both Sandbox and Production environments.

Get Account

Get a specific account by its ID.

Verb	GET
URL	https://api.s.unit.sh/ready-to-launch/accounts/:accountId
Required Scope	accounts
Timeout (Seconds)	5

Example Request:

curl -X GET 'https://api.s.unit.sh/ready-to-launch/accounts/42' \
-H "Authorization: Bearer ${TOKEN}"

Response

Returns account details including routing number, account number, status, and current balance (in cents).

Response is a JSON:API document.

200 OK

id

string

Identifier of the account resource.

type

string

Type of the account resource. Always account.

attributes

JSON Object

JSON object representing the account data.

Attributes

id

string

The unique identifier of the account.

routingNumber

string

The routing number of the account.

accountNumber

string

The account number.

status

string

The status of the account (Open, Frozen, or Closed).

balance

integer

The current balance in cents.

userIds

array

List of user IDs associated with this account.

Example Response:

{
  "data": {
    "type": "account",
    "id": "10004",
    "attributes": {
      "routingNumber": "812345678",
      "accountNumber": "1000000001",
      "status": "Open",
      "balance": 150000,
      "userIds": ["user_12345", "user_67890"]
    }
  }
}

List Accounts

List deposit accounts.

Verb	GET
URL	https://api.s.unit.sh/ready-to-launch/accounts
Required Scope	accounts
Timeout (Seconds)	5

Query Parameters

Name	Type	Default	Description
filter[customerId]	string	(empty)	Filter accounts by customer ID. Required if userId not provided.
filter[userId]	string	(empty)	Filter accounts by user ID. Required if customerId not provided.
page[limit]	integer	100	Optional. Maximum number of resources to return. Maximum is 10000 resources.
page[offset]	integer	0	Optional. Number of resources to skip. See Pagination.

Note

At least one of filter[customerId] or filter[userId] must be provided.

Example Request:

curl -X GET 'https://api.s.unit.sh/ready-to-launch/accounts?filter[customerId]=10000' \
-H "Authorization: Bearer ${TOKEN}"

Response

Returns a paginated list of deposit accounts with their details.

Response is a JSON:API document.

200 OK

data

Array of accounts

Array of account resources.

Example Response:

{
  {
    "data": [
        {
            "type": "account",
            "id": "10020",
            "attributes": {
                "routingNumber": "406735154",
                "accountNumber": "864800000014",
                "status": "Open",
                "balance": 6000,
                "userIds": ["user_12345"]
            }
        }
    ],
    "meta": {
        "pagination": {
            "total": 1,
            "limit": 100,
            "offset": 0
        }
    }
}

List Customers

Get a list of customers.

Verb	GET
URL	https://api.s.unit.sh/ready-to-launch/customers
Required Scope	customers
Timeout (Seconds)	5

Query Parameters

Name	Type	Default	Description
filter[customerId]	string	(empty)	Optional. Filter customers by customer ID.
filter[userId]	string	(empty)	Optional. Filter customers by user ID.

Example Request:

curl -X GET 'https://api.s.unit.sh/ready-to-launch/customers' \
-H "Authorization: Bearer ${TOKEN}"

Response

Returns a list of customers with their details.

Response is a JSON:API document.

200 OK

data

Array of customers

Array of customer resources.

Attributes

userIds

array

List of user IDs associated with this customer.

Example Response:

{
  "data": [
    {
      "type": "customer",
      "id": "10014",
      "attributes": {
        "userIds": ["user_12345", "user_67890"]
      }
    },
    {
      "type": "customer",
      "id": "10016",
      "attributes": {
        "userIds": ["user_11111"]
      }
    }
  ]
}

Get Transaction

Get a transaction by transaction id and account id.

Verb	GET
URL	https://api.s.unit.sh/ready-to-launch/accounts/:accountId/transactions/:transactionId
Required Scope	transactions
Timeout (Seconds)	5

Example Request:

curl -X GET 'https://api.s.unit.sh/ready-to-launch/accounts/12345/transactions/12345' \
-H "Authorization: Bearer ${TOKEN}"

Response

Returns the transaction details. Amounts and balances are in cents.

Response is a JSON:API document.

200 OK

id

string

Identifier of the transaction resource.

type

string

Type of the transaction resource. The value is always transaction.

attributes

JSON Object

JSON object representing the transaction data.

relationships

JSON:API Relationships

Describes relationships between the transaction resource and other resources.

Attributes

createdAt

string

The date the transaction was created. Common to all transaction types.

direction

string

The direction in which the funds flow. Common to all transaction types.

amount

integer

The amount (cents) of the transaction. Common to all transaction types.

balance

integer

The account balance (cents) after the transaction. Common to all transaction types.

transactionType

string

The type of the transaction.

summary

string

A brief summary of the transaction.

tagsOptional

object

Optional. See Tags.

counterpartyOptional

object

Optional. The counterparty of the transaction. See Counterparty

userIds

array

List of user IDs associated with this transaction.

addendaOptional

string

Optional. ACH only. Additional payment description (maximum of 80 characters), not all institutions present that.

atmNameOptional

string

Optional. ATM only. The name of the ATM.

atmLocationOptional

string

Optional. ATM only. The location (city, state, etc.) of the ATM.

merchant.nameOptional

string

Optional. Purchase/Card only. The name of the merchant.

merchant.typeOptional

integer

Optional. Purchase/Card only. The 4-digit ISO 18245 merchant category code (MCC).

merchant.locationOptional

string

Optional. Purchase/Card only. The location (city, state, etc.) of the merchant.

merchant.idOptional

string

Optional. Purchase/Card only. The unique network merchant identifier.

Relationships

account

JSON:API Relationship

The Deposit Account of the customer.

customer

Optional, JSON:API Relationship

The Customer the deposit account belongs to.

customers

Optional, Array of JSON:API Relationship

The list of Customers the deposit account belongs to.

Example Response:

{
  "data": {
    "type": "transaction",
    "id": "12345",
    "attributes": {
      "amount": 50000,
      "direction": "Credit",
      "transactionType": "ACH",
      "createdAt": "2021-06-02T10:15:22.123Z",
      "balance": 150000,
      "summary": "ACH payment from John Doe",
      "tags": {
        "purpose": "invoice-payment"
      },
      "counterparty": {
        "name": "John Doe",
        "routingNumber": "812345678",
        "accountNumber": "1000000002",
        "accountType": "Checking"
      },
      "userIds": ["user_12345"]
    },
    "relationships": {
      "account": {
        "data": {
          "type": "account",
          "id": "10004"
        }
      },
      "customer": {
        "data": {
          "type": "customer",
          "id": "10000"
        }
      },
      "customers": {
        "data": [
          {
            "type": "customer",
            "id": "10000"
          }
        ]
      }
    }
  }
}

List Transactions

List transactions with optional filtering and pagination.

Verb	GET
URL	https://api.s.unit.sh/ready-to-launch/transactions/
Required Scope	transactions
Timeout (Seconds)	5

Query Parameters

Name	Type	Default	Description
filter[userId]	string	(empty)	Filter transactions by user ID. Required if customerId not provided.
filter[customerId]	string	(empty)	Filter transactions by customer ID. Required if userId not provided.
filter[since]	string	(empty)	Optional. Start date for filtering (ISO 8601).
filter[until]	string	(empty)	Optional. End date for filtering (ISO 8601).
page[limit]	integer	100	Optional. Maximum number of resources to return.
page[offset]	integer	0	Optional. Number of resources to skip.
filter[type]	string	(empty)	Optional. Filter by transaction type.
filter[direction]	string	(empty)	Optional. Filter by direction (Credit or Debit).
filter[amount]	string	(empty)	Optional. Filter by amount range (e.g., 100-500).

Note

At least one of filter[customerId] or filter[userId] must be provided.

Example Request:

curl -X GET 'https://api.s.unit.sh/ready-to-launch/transactions?filter[userId]=user_12345' \
-H "Authorization: Bearer ${TOKEN}"

Response

Returns a paginated list of transactions with their details. Amounts and balances are in cents.

Response is a JSON:API document.

200 OK

data

Array of transactions

Array of transaction resources.

Example Response:

{
  "data": [
    {
      "type": "transaction",
      "id": "12345",
      "attributes": {
        "amount": 50000,
        "direction": "Credit",
        "transactionType": "ACH",
        "createdAt": "2021-06-02T10:15:22.123Z",
        "balance": 150000,
        "userIds": ["user_12345"]
      },
      "relationships": {
        "account": {
          "data": {
            "type": "account",
            "id": "10004"
          }
        },
        "customer": {
          "data": {
            "type": "customer",
            "id": "10000"
          }
        },
        "customers": {
          "data": [
            {
              "type": "customer",
              "id": "10000"
            }
          ]
        }
      }
    }
  ],
  "meta": {
    "pagination": {
      "total": 1,
      "limit": 10,
      "offset": 0
    }
  }
}

Get Check Deposit

Get a check deposit by check deposit id.

Verb	GET
URL	https://api.s.unit.sh/ready-to-launch/check-deposits/:checkDepositId
Required Scope	check-deposits
Timeout (Seconds)	5

Example Request:

curl -X GET 'https://api.s.unit.sh/ready-to-launch/check-deposits/12345' \
-H "Authorization: Bearer ${TOKEN}"

Response

Returns check deposit details including direction, type, created at, tags, summary, counterparty, amount and balance (in cents).

Response is a JSON:API document.

200 OK

id

string

Identifier of the check deposit resource.

type

string

Type of the check deposit resource. The value is always checkDeposit.

attributes

JSON Object

JSON object representing the check deposit data.

relationships

JSON:API Relationships

Describes relationships between the check deposit resource and other resources.

Attributes

amount

integer

The amount (cents) of the check deposit.

direction

string

The direction in which the funds flow.

type

string

The type of the check deposit.

createdAt

string

The date the check deposit was created.

balance

integer

The account balance (cents) after the check deposit.

tagsOptional

object

Optional. See Tags.

summary

string

A brief summary of the check deposit.

counterpartyOptional

object

Optional. The counterparty of the check deposit. See Counterparty

Example Response:

{
  "data": {
    "type": "checkDeposit",
    "id": "12345",
    "attributes": {
      "amount": 50000,
      "direction": "Credit",
      "type": "CheckDeposit",
      "createdAt": "2021-06-02T10:15:22.123Z",
      "balance": 150000,
      "tags": {
        "purpose": "invoice-payment"
      },
      "summary": "Check deposit from John Doe",
      "counterparty": {
        "name": "John Doe",
        "routingNumber": "812345678",
        "accountNumber": "1000000002",
        "accountType": "Checking"
      }
    },
    "relationships": {
      "account": {
        "data": {
          "type": "account",
          "id": "10004"
        }
      },
      "customer": {
        "data": {
          "type": "customer",
          "id": "10000"
        }
      }
    }
  }
}

Create Book Payment

Create a new book payment between accounts.

Verb	POST
URL	https://api.s.unit.sh/ready-to-launch/book-payments
Required Scope	payments-write
Data Type	bookPayment
Timeout (Seconds)	5

Attributes

amount

integer

The amount (in cents).

description

string

Payment description (maximum of 80 characters), this will show up on statement of the counterparty.

tagsOptional

object

Optional. See Tags. Tags that will be copied to any transaction that this payment creates (see Tag Inheritance).

idempotencyKeyOptional

string

Optional. See Idempotency.

Relationships

account

JSON:API Relationship

The Deposit Account originating the payment.

operationalAccount

JSON:API Relationship

The Organization's Operational Account the payment to be made to.

Example Request:

curl -X POST 'https://api.s.unit.sh/ready-to-launch/book-payments' \
  -H 'Content-Type: application/vnd.api+json' \
  -H 'Authorization: Bearer ${TOKEN}' \
  --data-raw '{
    "data": {
        "type": "bookPayment",
        "attributes": {
            "amount": 1000,
            "description": "test payment",
            "tags": {
                "test": "test"
            },
            "idempotencyKey": "unique-idempotency-key"
        },
        "relationships": {
            "account": {
                "data": {
                    "type": "account",
                    "id": "10013"
                }
            },
            "operationalAccount": {
                "data": {
                    "type": "account",
                    "id": "10020"
                }
            }
        }
    }
}'

Response

Returns details of the created book payment including status and associated resources.

Response is a JSON:API document.

200 OK

id

string

Identifier of the book payment resource.

type

string

Type of the book payment resource. The value is always bookPayment.

attributes

JSON Object

JSON object representing the book payment data.

relationships

JSON:API Relationships

Describes relationships between the book payment resource and other resources.

Attributes

createdAt

string

The date and time the payment was created.

status

string

The status of the payment.

amount

integer

Payment amount in cents.

description

string

Description of the payment.

direction

string

The direction in which the funds flow (always Credit).

Relationships

Name	Type	Description
account	JSON:API Relationship	The Deposit Account creating the payment.
counterpartyAccount	JSON:API Relationship	The Deposit Account that is the counterparty (receiving) account for the payment.
customer	Optional, JSON:API Relationship	The Customer the deposit account belongs to.
customers	Optional, Array of JSON:API Relationship	The list of Customers the deposit account belongs to.
transaction	JSON:API Relationship	The Book Transaction generated by this payment.

Example Response:

{
  "data": {
    "type": "bookPayment",
    "id": "12345",
    "attributes": {
      "createdAt": "2023-10-20T10:15:22.123Z",
      "amount": 50000,
      "direction": "Credit",
      "description": "Payment transfer",
      "status": "Sent",
      "tags": {},
      "userIds": ["user_12345"]
    },
    "relationships": {
      "account": {
        "data": {
          "type": "account",
          "id": "10004"
        }
      },
      "counterpartyAccount": {
        "data": {
          "type": "account",
          "id": "10005"
        }
      },
      "customer": {
        "data": {
          "type": "customer",
          "id": "10000"
        }
      },
      "customers": {
        "data": [
          {
            "type": "customer",
            "id": "10000"
          }
        ]
      },
      "transaction": {
        "data": {
          "type": "transaction",
          "id": "12345"
        }
      }
    }
  }
}