What is Gas Sweeping?

Gas Sweeping is an essential part of how inabit automates the secure movement of funds across deposit addresses and wallets. Every widget created within the inabit Terminal collects user deposits to unique, on-chain addresses. To ensure these funds are accessible and manageable at scale, inabit uses sweeping mechanisms to transfer them into centralized organization wallets.

Gas Sweeping refers to this automated fund consolidation, and requires blockchain-native gas fees to execute transactions securely and efficiently.

How Gas Sweeping Works

When users deposit funds via a widget (e.g., USDT on Tron or Ethereum), the funds initially sit in a dedicated deposit address generated for that session. To make these funds usable for your organization, the Terminal automatically "sweeps" them into a central wallet.

Key Behaviors

• Sweeping is triggered based on the widget's configuration:

  • Daily, Weekly, On-demand, or Never

• Each sweep consumes gas fees (TRX for Tron, ETH for Ethereum, etc.)

• To prevent failed or stuck transactions, inabit handles sweeping gas from a separate station wallet, not from the customer’s deposit address

Smart Sweeping Design

• Gas Separation: Gas for sweeping is drawn from your organization's gas station wallet, not from the deposit address, ensuring funds are always sweepable.

• Fail-safe Logic: inabit’s infrastructure monitors sweep attempts and retries if gas is insufficient.

• Fee Control: You can configure whether the gas cost is covered by you (the merchant) or passed on to the end user at the widget level.

Viewing Your Gas Balances Status

On the Terminal Dashboard, you’ll find a section showing gas balances per blockchain:

• Tron

• Ethereum

• BSC (Binance Smart Chain)

• Polygon

These balances represent how much gas is available to support sweep transactions.

✅ Best Practices

⚙️ Advanced Widget Settings

Reusable Address (Toggle)

• Enabled – The same deposit address will be used for each transaction.

• Useful for recurring or identifiable customers.

• Can be reused for new deposits without creating a new widget.

Expiration Time

• Set a time window (in minutes) for how long the widget will remain valid after being opened.

• Example: 15 minutes, 60 minutes.

Expiration Time Action

What should happen when the widget expires?

• Fail the request – The transaction is invalidated.

• Update the rate of the POS transaction – The widget remains usable, but the rate will refresh based on current market price.

Confirmations Settings

Choose how many blockchain confirmations are required before the deposit is considered final.

You have two options:

1. Organization Default

These defaults vary by chain and can be edited in organization settings:

• Tron (TRC20) – 19 confirmations

• Ethereum (ERC20) – 12 confirmations

• Polygon – 128 confirmations

• Bitcoin – 3 confirmations

• BSC – 15 confirmations

2. Custom

Customize confirmations per blockchain according to your preference, directly in this widget. This gives you more control and flexibility!

Accept Partial Payment (Toggle)

• Enabled – The widget will accept any amount deposited, even if it doesn’t match the target amount.

• Use this when the deposit can vary or when customer balance might be uncertain.

Overview

inabit’s Terminal includes robust gas management features that ensure seamless blockchain operations at scale. From automating transaction costs to allowing easy refueling, the Gas Features in the Terminal give your organization full control and reliability over how blockchain-native gas is handled across your payment infrastructure.

Gas Sweeping

Whenever a user makes a deposit through a widget, the funds are initially stored in a dedicated blockchain address. To centralize and secure these funds, inabit automatically sweeps them into your organization's main wallet using a process called Gas Sweeping.

This process requires gas fees (e.g., ETH, TRX, MATIC), which are not deducted from the user’s deposit. Instead, they are handled through your organization’s Gas Station Wallet, ensuring reliability and avoiding failed transactions.

Sweeping frequency is fully configurable:

• Daily

• Weekly

• On-demand

• Never (manual sweep only)

Gas Refueling

To support sweeping and other blockchain operations, inabit provides an easy way to top up gas balances directly from the Terminal.

You can refuel your Gas Station Wallet by:

• Paying with a credit card (select chain, amount, and billing details)

• Sending crypto to a dedicated funding address per blockchain

These funds are stored securely and used exclusively to cover gas fees for sweep operations — not user balances or purchases.

Why It Matters

• No need to rely on user deposits having spare gas

• Automated fund consolidation keeps your assets secure and organized

• Reduce operational risk with proactive refueling and monitoring

• Works across multiple blockchains: Ethereum, Tron, Polygon, BSC, and more

Create an inabit API Wallet

The CreateApiWalletAddress mutation allows API admins to create a new inabit API wallet with a designated address for a given asset & blockchain.

Remember to authenticate to call our graphQL API using an access token (bearer) with your API Admin credentials. (If you're not sure how, refer to Authentication)

Don't have an API Admin user yet? contact us at support@inabit.com to create one!

CreateApiWalletAddress Mutation:

mutation CreateApiWalletAddress($data: ApiWalletCreateAddressInput!) {
  createApiWalletAddress(data: $data) {
    address
    walletId
  }
}

Body (ApiWalletCreateAddressInput object)

Example body:

{
  "data": {
    "blockchainId": "clefn78cl00i3lc6rih442mx9",
    "financialAssetId": "clefn78h5012plc6rxbmofnop",
    "organizationId": "clsu8bel7000dlciyfdfbmwcw"
  }
}

Response

{
	"data": {
		"createApiWalletAddress": {
			"address": "0xcc918e16bc528bf58fc250f56898c7d917d33de2",
			"walletId": "cluicfnpb000066015d3narbc"
		}
	}
}

{
  "error": "Invalid request"
}

In the mutation's response, you will receive the created api wallet ID including the associated blockchain address.

Create an inabit API Wallet

The CreateApiWalletAddress mutation allows API admins to create a new inabit API wallet with a designated address for a given asset & blockchain.

Remember to authenticate to call our graphQL API using an access token (bearer) with your API Admin credentials. (If you're not sure how, refer to Authentication)

Don't have an API Admin user yet? contact us at support@inabit.com to create one!

CreateApiWalletAddress Mutation:

mutation CreateApiWalletAddress($data: ApiWalletCreateAddressInput!) {
  createApiWalletAddress(data: $data) {
    address
    walletId
  }
}

Body (ApiWalletCreateAddressInput object)

Example body:

{
  "data": {
    "blockchainId": "clefn78cl00i3lc6rih442mx9",
    "financialAssetId": "clefn78h5012plc6rxbmofnop",
    "organizationId": "clsu8bel7000dlciyfdfbmwcw"
  }
}

Response

{
	"data": {
		"createApiWalletAddress": {
			"address": "0xcc918e16bc528bf58fc250f56898c7d917d33de2",
			"walletId": "cluicfnpb000066015d3narbc"
		}
	}
}

{
  "error": "Invalid request"
}

In the mutation's response, you will receive the created api wallet ID including the associated blockchain address.

Create an inabit API Wallet

The CreateApiWalletAddress mutation allows API admins to create a new inabit API wallet with a designated address for a given asset & blockchain.

Remember to authenticate to call our graphQL API using an access token (bearer) with your API Admin credentials. (If you're not sure how, refer to Authentication)

Don't have an API Admin user yet? contact us at support@inabit.com to create one!

CreateApiWalletAddress Mutation:

mutation CreateApiWalletAddress($data: ApiWalletCreateAddressInput!) {
  createApiWalletAddress(data: $data) {
    address
    walletId
  }
}

Body (ApiWalletCreateAddressInput object)

Example body:

{
  "data": {
    "blockchainId": "clefn78cl00i3lc6rih442mx9",
    "financialAssetId": "clefn78h5012plc6rxbmofnop",
    "organizationId": "clsu8bel7000dlciyfdfbmwcw"
  }
}

Response

{
	"data": {
		"createApiWalletAddress": {
			"address": "0xcc918e16bc528bf58fc250f56898c7d917d33de2",
			"walletId": "cluicfnpb000066015d3narbc"
		}
	}
}

{
  "error": "Invalid request"
}

In the mutation's response, you will receive the created api wallet ID including the associated blockchain address.

🧩 Creating Widgets Through The Interface

POS Widgets in inabit’s Terminal are embeddable components that enable merchants to accept cryptocurrency payments directly from users. These widgets are highly customizable and connected to your organization’s internal wallet infrastructure, giving you full control over supported assets, payout behavior, fees, expiration rules, and more.

What is a POS Widget?

A POS (Point of Sale) Widget is a payment interface you can generate inside your Terminal to receive deposits from end users or customers in a specific cryptocurrency. You can configure it to:

• Support specific assets (e.g., USDT on Tron or Ethereum)

• Sweep funds to your wallets automatically

• Apply expiration and confirmation logic

• Choose who pays the fees (merchant or customer)

• Embed it into your app, website, or customer flow

These widgets are ideal for:

• Subscription billing

• Pay-per-use tools

• Partner platforms

• In-app payments

➕ Creating a New Widget

From the Terminal dashboard:

2. A widget creation drawer will appear on the right side with the following fields:

🧾 Widget Creation Form Fields

1. Widget Name

• A unique name to identify your widget (e.g., Basic Plan Payment).

• Visible internally and optionally to users.

2. Description

• A short explanation of what this widget is used for.

• Optional but helps for internal tracking.

3. Merchant Name (Optional)

• Name of the merchant displayed to the end user (if applicable).

4. Assets (Supported Assets)

• Select which cryptocurrencies the widget will accept.

• Example: USDT (TRC20), USDC (ERC20), ETH.

• Dropdown field with multi-select options.

• You can also search for a specific asset code you're looking for using the search bar.

This defines how and when collected funds will be transferred from the widget deposit addresses to your organization wallet.

Options:

• Daily – Sweeps once per day to the configured wallet.

• Weekly – Sweeps once per week.

• Never – Funds remain in the widget wallet until manual transfer.

• On-Demand – Funds are swept only when triggered via API or Terminal manually.

Choose based on your operational and liquidity needs.

🎯 Destination Address

• Select the wallet address to which collected funds will be swept.

• Dropdown field pulling from your organization's whitelisted wallet list.

⚙️️ Sweeping Fees

Choose who pays the gas/processing fee when sweeping occurs:

• Charge Merchant (Myself) – Your organization covers the sweep cost.

• Charge Customer – Fees are deducted from the user's deposit amount.

⚙️ Advanced Settings

🎉 Final Step: Create Widget

Once all the fields are set:

• Your new POS Widget will be added to the list and ready for use.

Widget Preview Example:

About Our Webhooks 📣

Receive notifications/alerts on every new transaction or transaction status change in any of your inabit organizations within your account, as well as fee updates for a transaction.

There are two endpoints you can use with our Webhooks:

• Events Handled:

  • New Transaction Event

  • Transaction Status Updates (Incl. txn fee updates)

• Supported transaction types:

  • Received (Deposits)

  • Sent (Withdrawals)

Create Subscription

In order to create a subscription on our GraphQL API, you'll need to call the following mutation:

mutation CreateSubscription($data: SubscriptionCreateInput!) {
  createSubscription(data: $data) {
  id,
  token
  }
}

Headers

Body (SubscriptionCreateInput object)

Example body:

{
  "data": {
    "organization": {
      "id": "clu1dzpny0007vjto1gxhl5my"   # inabit organization Id
    },
    "url": "https://studio.apollographql.com",   # Webhook for subscriber
  }
}

Response

{
  "data": {
    "createSubscription": {
      "id": "clugv892y0000vjhga8ugol38",   # Created subscription Id
      "token": "sub_c028ef8d-b8b9-49c0-b5a9-f7451884b834"   # Unique generated token recognized by inabit
    }
  }
}

{
  "errors": [
    {
      "message": "INTERNAL_SERVER_ERROR",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "createSubscription"
      ],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR",
        "message": "There's already an active subscription for this organization. (organization: clu1dzpny0007vjto1gxhl5my)",
        "exception": {
          "message": "INTERNAL_SERVER_ERROR",
          "stacktrace": [
            "Error: There's already an active subscription for this organization. (organization: clu1dzpny0007vjto1gxhl5my)",
            "    at SubscriptionResolver.createSubscription (C:\\Users\\Ori Botan\\Documents\\inabit\\inabit\\server\\src\\subscription\\subscription.resolver.ts:81:13)"
          ]
        }
      }
    }
  ],
  "data": null
}

{
  "errors": [
    {
      "message": "INTERNAL_SERVER_ERROR",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "createSubscription"
      ],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR",
        "message": "Create subscription failed (organization: clu1dzpny0007vjto1gxhl5my)",
        "exception": {
          "message": "INTERNAL_SERVER_ERROR",
          "stacktrace": [
            "Error: Create subscription failed (organization: clu1dzpny0007vjto1gxhl5my)",
            "    at SubscriptionResolver.createSubscription (C:\\Users\\Ori Botan\\Documents\\inabit\\inabit\\server\\src\\subscription\\subscription.resolver.ts:81:13)"
          ]
        }
      }
    }
  ],
  "data": null
}

In the mutation's response, the following is retrieved:

ID - The ID of the subscription that was created.

Token - A unique token generated by inabit.

• The token will be the identifying the webhook resource for the subscriber set as a header: 'authorization' : (i.e. - sub_c028ef8d-b8b9-49c0-b5a9-f7451884b834)

query Subscriptions($where: SubscriptionWhereInput) {
  subscriptions(where: $where) {
  id  
  token
  }
}

Body (SubscriptionWhereInput object)

Delete Subscription

In order to delete a subscription, the following mutation needs to be used:

mutation DeleteSubscription($where: SubscriptionWhereUniqueInput!) {
  deleteSubscription(where: $where) {
  id  
  }
}

Headers

Body (SubscriptionWhereUniqueInput object)

Example body:

body:
{
  "where": {
    "id": "clu5bxctk0003vje4n4pqfdya"   # Subscription Id
  }
}

Response

{
  "data": {
    "deleteSubscription": {
      "id": "clugwvbm70007vj4w74gxch3u"
    }
  }
}

{
  "errors": [
    {
      "message": "INTERNAL_SERVER_ERROR",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "deletesubscription"
      ],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR",
        "message": "Delete subscription failed (organization: clu1dzpny0007vjto1gxhl5my)",
        "exception": {
          "message": "INTERNAL_SERVER_ERROR",
          "stacktrace": [
            "Error: Delete subscription failed (organization: clu1dzpny0007vjto1gxhl5my)",
            "    at SubscriptionResolver.deleteSubscription (C:\\Users\\Ori Botan\\Documents\\inabit\\inabit\\server\\src\\subscription\\subscription.resolver.ts:81:13)"
          ]
        }
      }
    }
  ],
  "data": null
}

About Our Webhooks 📣

Receive notifications/alerts on every new transaction or transaction status change in any of your inabit organizations within your account, as well as fee updates for a transaction.

There are two endpoints you can use with our Webhooks:

• Events Handled:

  • New Transaction Event

  • Transaction Status Updates (Incl. txn fee updates)

• Supported transaction types:

  • Received (Deposits)

  • Sent (Withdrawals)

Create Subscription

In order to create a subscription on our GraphQL API, you'll need to call the following mutation:

mutation CreateSubscription($data: SubscriptionCreateInput!) {
  createSubscription(data: $data) {
  id,
  token
  }
}

Headers

Body (SubscriptionCreateInput object)

Example body:

{
  "data": {
    "organization": {
      "id": "clu1dzpny0007vjto1gxhl5my"   # inabit organization Id
    },
    "url": "https://studio.apollographql.com",   # Webhook for subscriber
  }
}

Response

{
  "data": {
    "createSubscription": {
      "id": "clugv892y0000vjhga8ugol38",   # Created subscription Id
      "token": "sub_c028ef8d-b8b9-49c0-b5a9-f7451884b834"   # Unique generated token recognized by inabit
    }
  }
}

{
  "errors": [
    {
      "message": "INTERNAL_SERVER_ERROR",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "createSubscription"
      ],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR",
        "message": "There's already an active subscription for this organization. (organization: clu1dzpny0007vjto1gxhl5my)",
        "exception": {
          "message": "INTERNAL_SERVER_ERROR",
          "stacktrace": [
            "Error: There's already an active subscription for this organization. (organization: clu1dzpny0007vjto1gxhl5my)",
            "    at SubscriptionResolver.createSubscription (C:\\Users\\Ori Botan\\Documents\\inabit\\inabit\\server\\src\\subscription\\subscription.resolver.ts:81:13)"
          ]
        }
      }
    }
  ],
  "data": null
}

{
  "errors": [
    {
      "message": "INTERNAL_SERVER_ERROR",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "createSubscription"
      ],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR",
        "message": "Create subscription failed (organization: clu1dzpny0007vjto1gxhl5my)",
        "exception": {
          "message": "INTERNAL_SERVER_ERROR",
          "stacktrace": [
            "Error: Create subscription failed (organization: clu1dzpny0007vjto1gxhl5my)",
            "    at SubscriptionResolver.createSubscription (C:\\Users\\Ori Botan\\Documents\\inabit\\inabit\\server\\src\\subscription\\subscription.resolver.ts:81:13)"
          ]
        }
      }
    }
  ],
  "data": null
}

In the mutation's response, the following is retrieved:

ID - The ID of the subscription that was created.

Token - A unique token generated by inabit.

• The token will be the identifying the webhook resource for the subscriber set as a header: 'authorization' : (i.e. - sub_c028ef8d-b8b9-49c0-b5a9-f7451884b834)

query Subscriptions($where: SubscriptionWhereInput) {
  subscriptions(where: $where) {
  id  
  token
  }
}

Body (SubscriptionWhereInput object)

Delete Subscription

In order to delete a subscription, the following mutation needs to be used:

mutation DeleteSubscription($where: SubscriptionWhereUniqueInput!) {
  deleteSubscription(where: $where) {
  id  
  }
}

Headers

Body (SubscriptionWhereUniqueInput object)

Example body:

body:
{
  "where": {
    "id": "clu5bxctk0003vje4n4pqfdya"   # Subscription Id
  }
}

Response

{
  "data": {
    "deleteSubscription": {
      "id": "clugwvbm70007vj4w74gxch3u"
    }
  }
}

{
  "errors": [
    {
      "message": "INTERNAL_SERVER_ERROR",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "deletesubscription"
      ],
      "extensions": {
        "code": "INTERNAL_SERVER_ERROR",
        "message": "Delete subscription failed (organization: clu1dzpny0007vjto1gxhl5my)",
        "exception": {
          "message": "INTERNAL_SERVER_ERROR",
          "stacktrace": [
            "Error: Delete subscription failed (organization: clu1dzpny0007vjto1gxhl5my)",
            "    at SubscriptionResolver.deleteSubscription (C:\\Users\\Ori Botan\\Documents\\inabit\\inabit\\server\\src\\subscription\\subscription.resolver.ts:81:13)"
          ]
        }
      }
    }
  ],
  "data": null
}

Sign On Transactions (Automated Flow)

On a transaction creation in Inabit, Inabit will send a request to the Approver to handle the requested transaction approval, and sign on the approve/reject decision.

In order to handle transaction approvals:

1. Approver (API Signer) needs to be in Paired status.

2. Configure an external validation url ('endpoint'), implementing the Approver's required approval logics:

   • The external validation endpoint is expected to expose a 'post' http endpoint for validation purpose.

           
      VALIDATION_CALLBACK_URL=http://koko.com/validation
      

• The endpoint will automatically be passed a TransactionValidationData json object at the body of the http 'post' call. with the following structure:

 
  {
        createTime: string;
        transactionId: string;
        transactionType: string;   // Withdrawal / Deposit / Swap
        initiatorId: string;
        organizationId: string;
        network: string;
        walletId: string;
        walletAddress: string;
        to: string;
        coin: string;
        amount: number;
        baseCurrencyCode: string;
        baseCurrencyAmount: number;
  };
  

• The endpoint is expected to return a response with the following structure:

{ approved: boolean }  // allowed: { approved: true / false }

• In case of an exception a retry will be scheduled to execute in 3 minutes time, up to 10 times (10 * 3 minutes).

  VALIDATION_RETRY_INTERVAL_MINUTES=3
  VALIDATION_RETRY_MAX_COUNT=10

• On receiving a validation url call response, a signed approval (using Approver's key) will be sent back automatically to Inabit, for further processing (policy enforcement).

Mock Validation

It is also possible to mock external validation url using a predefined endpoint (transaction/validate) on the Approver, and control the required outcome. Using the following configuration

VALIDATION_CALLBACK_URL=[APPROVER_URL]transaction/validate   # replace [APPROVER_URL] with the Approver's url. 
VALIDATION_MOCK_SET_RESULT=rejected   # allowed: approved / rejected / exception

Initiation trace log example:

{
  level: 'info',
  message: 'Init Approver started',
  metadata: { timestamp: '2024-02-21T08:54:11.990Z' },
  timestamp: '2024-02-21T08:54:11.990Z'
}
{
  level: 'info',
  message: 'Checking if Approver is paired already.',
  metadata: { timestamp: '2024-02-21T08:54:15.174Z' },
  timestamp: '2024-02-21T08:54:15.174Z'
}
{
  level: 'info',
  message: 'Approver needs to be paired, starts a pairing process...',
  metadata: { timestamp: '2024-02-21T08:54:16.071Z' },
  timestamp: '2024-02-21T08:54:16.071Z'
}
{
  level: 'info',
  message: 'Getting a pairing token.',
  metadata: { timestamp: '2024-02-21T08:54:16.075Z' },
  timestamp: '2024-02-21T08:54:16.075Z'
}
{
  level: 'info',
  message: 'Getting a pairing code',
  metadata: { timestamp: '2024-02-21T08:54:17.555Z' },
  timestamp: '2024-02-21T08:54:17.555Z'
}
{
  level: 'info',
  message: 'Pairing code: c754ce6d209dcc1b6f2312903ef31f0ac297b63e5dead29a6b877ecad8c77ada',
  metadata: { timestamp: '2024-02-21T08:54:17.560Z' },
  timestamp: '2024-02-21T08:54:17.560Z'
}
{
  level: 'info',
  message: 'Getting a signature key',
  metadata: { timestamp: '2024-02-21T08:54:17.562Z' },
  timestamp: '2024-02-21T08:54:17.562Z'
}
{
  level: 'info',
  message: 'signature key : eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCIsImp3ayI6eyJrdHkiOiJFQyIsIngiOiItWGJ6Qjdfa2I2cXNJdDRxTTg3cU5OMC1TeTVZWU9NbmN1R1F4U1E1YmZVIiwieSI6IjR6Qk9zR1Yza0NTek4zSW02cE1KSjZzcUJYVW03RHBfRjJmbWNhbEhGVzgiLCJjcnYiOiJQLTI1NiIsImtpZCI6Im01QXpWcWJjQURRK25hSmh5Y1E4b0JXTFJYYTBqeDVOQjEyeW1KQklyYlU9In19.eyJ2ZXJpZnlfa2V5Ijp7Imp3ayI6eyJrdHkiOiJFQyIsIngiOiItWGJ6Qjdfa2I2cXNJdDRxTTg3cU5OMC1TeTVZWU9NbmN1R1F4U1E1YmZVIiwieSI6IjR6Qk9zR1Yza0NTek4zSW02cE1KSjZzcUJYVW03RHBfRjJmbWNhbEhGVzgiLCJjcnYiOiJQLTI1NiIsImtpZCI6Im01QXpWcWJjQURRK25hSmh5Y1E4b0JXTFJYYTBqeDVOQjEyeW1KQklyYlU9In19LCJtZXNzYWdlIjoie1wiY3JlYXRvclwiOntcImVtYWlsXCI6XCJpc3N1ZXJAZXhhbXBsZS5jb21cIixcIm9yZ2FuaXphdGlvbk5hbWVcIjpcIm15LW9yZ2FuaXphdGlvblwifX0iLCJtYWMiOiJhOGJiMjA3ZGRiMTk2MmE1YTg3MjY2YTkzYWI4MDlmOTY1MDcwN2U0NmNkOTE3M2FiYjZhOTE4MDYwY2Q3ODU2IiwiaWF0IjoxNzA4NTA1NjU3fQ.1ZBl8XRllNyoJNWNPaB6iAu9VbQh2Jcr0hXRPppD8wES1Z5ZckPXTe0eqBmmTtZS_l4Gtip7kwOfFMi-jNtbIN',
  metadata: { timestamp: '2024-02-21T08:54:17.578Z' },
  timestamp: '2024-02-21T08:54:17.578Z'
}
{
  level: 'info',
  message: 'Sending pairing data',
  metadata: { timestamp: '2024-02-21T08:54:17.581Z' },
  timestamp: '2024-02-21T08:54:17.581Z'
}
{
  level: 'info',
  message: 'Approver is waiting for approval',
  metadata: { timestamp: '2024-02-21T08:54:20.767Z' },
  timestamp: '2024-02-21T08:54:20.767Z'
}
{
  level: 'info',
  message: 'Init Approver completed, waiting for pairing process completion.',
  metadata: { timestamp: '2024-02-21T08:54:20.769Z' },
  timestamp: '2024-02-21T08:54:20.769Z'
}
[Nest] 4308  - 02/21/2024, 8:54:20 AM     LOG [NestApplication] Nest application successfully started +8819ms
{
  level: 'info',
  message: 'Refresh token completed',
  metadata: { timestamp: '2024-02-21T08:54:20.803Z' },
  timestamp: '2024-02-21T08:54:20.803Z'
}
{
  level: 'info',
  message: 'Scheduling next refresh token in 15 days',
  metadata: { timestamp: '2024-02-21T08:54:20.806Z' },
  timestamp: '2024-02-21T08:54:20.806Z'
}

Gas Refueling – Interface Documentation

Gas Refueling allows your organization to top up blockchain-native gas (e.g., ETH, TRX, MATIC) used for sweeping deposit funds from customer addresses into your central wallet.

This gas is stored in a dedicated "Station Wallet", separate from any user-facing deposit address — ensuring you maintain uninterrupted operations without worrying about gas availability on each incoming address.

When Do You Need to Refuel?

You’ll need to refuel gas when:

• You see gas balances running low on any supported chain

• You anticipate high transaction volume requiring many sweep operations

• You want to proactively ensure sweeping never fails due to gas shortages

How to Add Gas in the Terminal

1. On the main Terminal dashboard, locate the “Gas Balance” panel.

2. A popup will open with funding options.

Option 1: Purchase Gas via Credit Card

This flow enables you to directly buy gas using fiat.

Steps:

1. Select Blockchain to fund (e.g., Ethereum, Tron).

2. Enter Company Name.

3. Select Country.

4. Enter your Credit Card Details.

5. Enter the Amount to purchase.

6. Confirm and complete the payment.

Once approved, gas will be instantly credited to the selected station wallet.

Option 2: Fund via Crypto Transfer

Prefer to move gas from an existing crypto wallet?

Steps:

1. Select the Blockchain you'd like to fund.

2. A dedicated deposit address will be generated along with a QR code.

3. Send the required gas (e.g., TRX, ETH) to the address shown.

4. The station wallet will be updated once the transaction is confirmed.

Safety and Monitoring

• All gas refuels are automatically tracked and reflected in your dashboard.

• There is no expiration for gas balances.

• You can refuel at any time, and all balances are held in enterprise-grade custody infrastructure.

Overview

This standalone project is designed to be deployed on a user's own server, enabling integration with inabit from remote.

Its primary purpose is to facilitate the approval of pending transactions within a gated approvals flow. This is essentially replacing an owner/approver's mobile approvals app, allowing users to control approvals on their server.

Functionality

Upon running, the application must successfully initialize and communicate with Inabit. This involves several steps depending on the initiation state. If the 'signer' is approved, the handling of pending transaction flow may proceed.

First Run

During the first run, a pairing process is initiated. This includes:

1. Logging into Inabit using the provided login token.

2. Validating the user's current state.

3. Requesting a pairing token.

4. Producing an encrypted key used for signing, saving it to a mapped volume.

5. Sending pairing data to Inabit and requesting the 'Owner' to authorize the approver.

6. Refreshing the login token i.e. acquiring automatically a new valid login token.

Recurring Runs

For subsequent runs, after validating that the user is paired, the application continues its operation as usual.

Initiation Errors

If anything goes wrong during the initiation stage, the approver initiation process will be aborted.

Prerequisites

1. An initial login token of a valid user within Inabit with the role: 'apiSigner'.

2. Enabled communication with the Inabit server (valid URL and whitelisted IPs and ports).

Deployment

From within the root directory inabit/inabit-remote:

Set Login Token

• The login token is approver's token valid for 30 days, allowing authentication with Inabit.

• The token is automatically refreshed, i.e. switched to a new 30 days valid token, on:

  • each docker init.

  • every 15 days (configurable)

• The refreshed login token is saved to a mapped volume on host machine.

• The login token must be mapped to a selected location in the host filesystem for initialization and persistency.

• Create a folder named refresh.

• Set into the folder the login token file r.dat (which includes the login token).

• Map the folder in the docker-compose.prod.yml:

volumes:
     - ./refresh:/app/apps/approver/refresh

• Add the following environment variables in correspondence:

LOGIN_TOKEN_FILE_PATH=refresh
LOGIN_TOKEN_FILE_NAME=r.dat
REFRESH_LOGIN_TOKEN_IN_MINUTES=21600 # 15 days in seconds, do not change! 

Build

docker-compose -f docker-compose.prod.yml build approver

Run

docker-compose -f docker-compose.prod.yml up approver

Required Configurations

The required config can be provided in 2 ways:

1. Baked into the docker by building the docker with a valid .env file.

2. Through the docker-compose.prod.yml file variables override section environment.

In case using .env is selected, remember to modify or remove the environment: section, from docker-compose.prod.yml. In case of a change of the .env , a new docker image build must proceed.

Required Environment Variables

INABIT_API_BASE_URL=http://localhost:3000/graphql
APPROVER_URL=http://example.example
APPROVER_PORT=3020
SECRET=change-me
KEY_FILE_PATH=dat
KEY_FILE_NAME=k.dat
LOGIN_TOKEN_FILE_PATH=refresh
LOGIN_TOKEN_FILE_NAME=r.dat
ORGANIZATION_NAME=my-organization

Important

The approvers' key must be mapped to a selected location in the host filesystem for persistency. This is the required combination of env variables:

SECRET=koko-moko  # Encryption secret for the key.
KEY_FILE_PATH=dat     # File path relative to the app/apps/approver i.e., app/apps/approver/dat.
KEY_FILE_NAME=k.dat   # File name of the encrypted key.

In the Docker Compose file:

volumes:
      - ./dat:/app/apps/approver/dat

Ensure Correspondence

Ensure there is correspondence between the volume mapping and the selected KEY_FILE_PATH settings. The volume mapping in the Docker Compose file should reflect the chosen KEY_FILE_PATH for persisting the encrypted key:

volumes:
      - ./dat:/app/apps/approver/dat

Pairing

On Docker init , it is first checked if the approver is in status Paired or WaitingForApproval.

If not, a pairing flow starts:

Within the flow interaction with Inabit,

1. a pairing data is exchanged with Inabit including the public signing key of the approver.

2. an approval message is sent to the owner of the organization.

3. a pairing code is produced in the approver start up log trace, and must be passed directly to the owner for pairing completion.

{
  level: 'info',
  message: 'Pairing code: c754ce6d209dcc1b6f2312903ef31f0ac297b63e5dead29a6b877ecad8c77ada',
  metadata: { timestamp: '2024-02-21T08:54:17.560Z' },
  timestamp: '2024-02-21T08:54:17.560Z'
}

Wish to see how you can automate approving and signing transactions?

Notifications from Inabit's webhook service provide real-time updates on transaction events and status changes, ensuring that you stay informed about crucial activities within your organization. Below are the different types of notifications you can expect to receive:

1. New Transaction Event:

   • Date and Time: Timestamp indicating when the transaction occurred.

   • Transaction Type: Whether it's a deposit (received) or a withdrawal (sent).

   • Transaction ID: Unique identifier for the transaction.

   • Transaction Status: Current status of the transaction.

   • Wallet ID: Identifier for the wallet associated with the transaction.

   • Wallet Name: Name of the wallet involved in the transaction.

   • Address Name: Name of the address involved in the transaction.

   • Coin/Asset Symbol: Symbol representing the cryptocurrency involved.

   • Blockchain: Name of the blockchain associated with the transaction.

   • Cryptocurrency Amount: Amount of cryptocurrency transacted.

   • Fee in Cryptocurrency: Transaction fee in cryptocurrency.

   • Fee (in Organization's Base Currency): Transaction fee converted to the organization's base currency.

   • Amount (in Organization's Base Currency): Transaction amount converted to the organization's base currency.

   • Transaction Hash: Unique hash identifying the transaction.

   • Source Address (From): Address from which the cryptocurrency was sent.

   • Destination Address (To): Address to which the cryptocurrency was sent.

2. Transaction Status Updates (Including Transaction Fee Updates):

   • Similar details as the new transaction event, with updates on the transaction status and associated fees + transaction hash (if completed).

These notifications empower you to track and manage transactions effectively, enabling timely decision-making and ensuring transparency and security within your crypto service.

New Transaction Event

{
  "createTime": "2024-04-01T12:21:00.205Z",
  "transactionType": "Withdrawal",
  "transactionId": "clugx5j1p000pvj4wgog8amvc",
  "transactionStatus": "PendingApproval",
  "walletId": "clu1dzpw00015vjto6gxeld8w",
  "walletName": "My inabit Wallet",
  "addressName": "inabit Wallet Ethereum",
  "coin": "ETH",
  "blockchain": "Ethereum",
  "amount": 0.00034,
  "baseCurrencyAmount": 0.5951873640866312,
  "fee": null,
  "baseCurrencyFee": null,
  "transactionHash": null,
  "sourceAddress": "0xd92a0778ee3f6c35c79407e1611d0dd5543b631f",
  "destinationAddress": "0xaf79d75c836aa10195ce358fc592fbbc2b0c62cc"
}

Transaction Status Updates

This notification is received for every transaction status change.

Here are the possible changes you can receive notifications on:

• Status changed to Processing:

  • Once you approve a transaction, its status should change to this.

• Status changed to Broadcasting:

  • The transaction entered the mempool and is being broadcasted to the blockchain.

• Status changed to Completed:

  • The transaction was completed in the blockchain.

  • In this notification you'll also receive additional data that includes:

    • The transaction fees breakdown.

    • The transaction's hash.

• Status changed to Failed:

  • Transaction failures can occur in the blockchain during broadcasting process or before that, in the processing phase in case any issue occured. (For example - insufficient gas fees to broadcast the transaction)

• Status changed to Rejected:

  • If the approver/s rejected the transaction in the mobile app, the status will be turned "Rejected".

• Status changed to Expired:

  • Transactions have a 5 hour window to be approved/rejected.

  • In case the time limit was reached, the transaction is expired and its status changes to "Expired".

Example Notification

Status changes to Broadcasting:

{
  "createTime": "2024-04-01T12:21:00.205Z",
  "transactionType": "Withdrawal",
  "transactionId": "clugx5j1p000pvj4wgog8amvc",
  "transactionStatus": "Broadcasting",
  "walletId": "clu1dzpw00015vjto6gxeld8w",
  "walletName": "My inabit Wallet",
  "addressName": "inabit Wallet Ethereum",
  "coin": "ETH",
  "blockchain": "Ethereum",
  "amount": 0.00034,
  "baseCurrencyAmount": 0.5951873640866312,
  "fee": null,
  "baseCurrencyFee": null,
  "transactionHash": null,
  "sourceAddress": "0xd92a0778ee3f6c35c79407e1611d0dd5543b631f",
  "destinationAddress": "0xaf79d75c836aa10195ce358fc592fbbc2b0c62cc"
}

Example Notification

Status changes to Completed:

{
  "createTime": "2024-04-01T12:21:00.205Z",
  "transactionType": "Withdrawal",
  "transactionId": "clugx5j1p000pvj4wgog8amvc",
  "transactionStatus": "Completed",
  "walletId": "clu1dzpw00015vjto6gxeld8w",
  "walletName": "My inabit Wallet",
  "addressName": "inabit Wallet Ethereum",
  "coin": "ETH",
  "blockchain": "Ethereum",
  "amount": 0.00034,
  "baseCurrencyAmount": 0.5951873640866312,
  "fee": 0.0013,
  "baseCurrencyFee": 4.38,
  "transactionHash": "0x6a5599d82e56ea89a218f76162cb28c29e28e3e85923ef6dd4cdba8aeec87149",
  "sourceAddress": "0xd92a0778ee3f6c35c79407e1611d0dd5543b631f",
  "destinationAddress": "0xaf79d75c836aa10195ce358fc592fbbc2b0c62cc"
}

Once you receive updates on completion of transactions (status changes to completed), the fees are also updated and are given in the notification data (no longer null):

• Notice the fees are given in both the crypto native currency (in the example above - ethereum) but also in the base currency, which is the base currency of the organization (EUR/USD).

  • fee

  • baseCurrencyFee

• You will also receive the transactionHash of the completed transaction in this notification.

Notifications from Inabit's webhook service provide real-time updates on transaction events and status changes, ensuring that you stay informed about crucial activities within your organization. Below are the different types of notifications you can expect to receive:

1. New Transaction Event:

   • Date and Time: Timestamp indicating when the transaction occurred.

   • Transaction Type: Whether it's a deposit (received) or a withdrawal (sent).

   • Transaction ID: Unique identifier for the transaction.

   • Transaction Status: Current status of the transaction.

   • Wallet ID: Identifier for the wallet associated with the transaction.

   • Wallet Name: Name of the wallet involved in the transaction.

   • Address Name: Name of the address involved in the transaction.

   • Coin/Asset Symbol: Symbol representing the cryptocurrency involved.

   • Blockchain: Name of the blockchain associated with the transaction.

   • Cryptocurrency Amount: Amount of cryptocurrency transacted.

   • Fee in Cryptocurrency: Transaction fee in cryptocurrency.

   • Fee (in Organization's Base Currency): Transaction fee converted to the organization's base currency.

   • Amount (in Organization's Base Currency): Transaction amount converted to the organization's base currency.

   • Transaction Hash: Unique hash identifying the transaction.

   • Source Address (From): Address from which the cryptocurrency was sent.

   • Destination Address (To): Address to which the cryptocurrency was sent.

2. Transaction Status Updates (Including Transaction Fee Updates):

   • Similar details as the new transaction event, with updates on the transaction status and associated fees + transaction hash (if completed).

These notifications empower you to track and manage transactions effectively, enabling timely decision-making and ensuring transparency and security within your crypto service.

New Transaction Event

{
  "createTime": "2024-04-01T12:21:00.205Z",
  "transactionType": "Withdrawal",
  "transactionId": "clugx5j1p000pvj4wgog8amvc",
  "transactionStatus": "PendingApproval",
  "walletId": "clu1dzpw00015vjto6gxeld8w",
  "walletName": "My inabit Wallet",
  "addressName": "inabit Wallet Ethereum",
  "coin": "ETH",
  "blockchain": "Ethereum",
  "amount": 0.00034,
  "baseCurrencyAmount": 0.5951873640866312,
  "fee": null,
  "baseCurrencyFee": null,
  "transactionHash": null,
  "sourceAddress": "0xd92a0778ee3f6c35c79407e1611d0dd5543b631f",
  "destinationAddress": "0xaf79d75c836aa10195ce358fc592fbbc2b0c62cc"
}

Transaction Status Updates

This notification is received for every transaction status change.

Here are the possible changes you can receive notifications on:

• Status changed to Processing:

  • Once you approve a transaction, its status should change to this.

• Status changed to Broadcasting:

  • The transaction entered the mempool and is being broadcasted to the blockchain.

• Status changed to Completed:

  • The transaction was completed in the blockchain.

  • In this notification you'll also receive additional data that includes:

    • The transaction fees breakdown.

    • The transaction's hash.

• Status changed to Failed:

  • Transaction failures can occur in the blockchain during broadcasting process or before that, in the processing phase in case any issue occured. (For example - insufficient gas fees to broadcast the transaction)

• Status changed to Rejected:

  • If the approver/s rejected the transaction in the mobile app, the status will be turned "Rejected".

• Status changed to Expired:

  • Transactions have a 5 hour window to be approved/rejected.

  • In case the time limit was reached, the transaction is expired and its status changes to "Expired".

Example Notification

Status changes to Broadcasting:

{
  "createTime": "2024-04-01T12:21:00.205Z",
  "transactionType": "Withdrawal",
  "transactionId": "clugx5j1p000pvj4wgog8amvc",
  "transactionStatus": "Broadcasting",
  "walletId": "clu1dzpw00015vjto6gxeld8w",
  "walletName": "My inabit Wallet",
  "addressName": "inabit Wallet Ethereum",
  "coin": "ETH",
  "blockchain": "Ethereum",
  "amount": 0.00034,
  "baseCurrencyAmount": 0.5951873640866312,
  "fee": null,
  "baseCurrencyFee": null,
  "transactionHash": null,
  "sourceAddress": "0xd92a0778ee3f6c35c79407e1611d0dd5543b631f",
  "destinationAddress": "0xaf79d75c836aa10195ce358fc592fbbc2b0c62cc"
}

Example Notification

Status changes to Completed:

{
  "createTime": "2024-04-01T12:21:00.205Z",
  "transactionType": "Withdrawal",
  "transactionId": "clugx5j1p000pvj4wgog8amvc",
  "transactionStatus": "Completed",
  "walletId": "clu1dzpw00015vjto6gxeld8w",
  "walletName": "My inabit Wallet",
  "addressName": "inabit Wallet Ethereum",
  "coin": "ETH",
  "blockchain": "Ethereum",
  "amount": 0.00034,
  "baseCurrencyAmount": 0.5951873640866312,
  "fee": 0.0013,
  "baseCurrencyFee": 4.38,
  "transactionHash": "0x6a5599d82e56ea89a218f76162cb28c29e28e3e85923ef6dd4cdba8aeec87149",
  "sourceAddress": "0xd92a0778ee3f6c35c79407e1611d0dd5543b631f",
  "destinationAddress": "0xaf79d75c836aa10195ce358fc592fbbc2b0c62cc"
}

Once you receive updates on completion of transactions (status changes to completed), the fees are also updated and are given in the notification data (no longer null):

• Notice the fees are given in both the crypto native currency (in the example above - ethereum) but also in the base currency, which is the base currency of the organization (EUR/USD).

  • fee

  • baseCurrencyFee

• You will also receive the transactionHash of the completed transaction in this notification.

Overview

This standalone project is designed to be deployed on a user's own server, enabling integration with inabit from remote.

Its primary purpose is to facilitate the approval of pending transactions within a gated approvals flow. This is essentially replacing an owner/approver's mobile approvals app, allowing users to control approvals on their server.

Functionality

Upon running, the application must successfully initialize and communicate with Inabit. This involves several steps depending on the initiation state. If the 'signer' is approved, the handling of pending transaction flow may proceed.

First Run

During the first run, a pairing process is initiated. This includes:

1. Logging into Inabit using the provided login token.

2. Validating the user's current state.

3. Requesting a pairing token.

4. Producing an encrypted key used for signing, saving it to a mapped volume.

5. Sending pairing data to Inabit and requesting the 'Owner' to authorize the approver.

6. Refreshing the login token i.e. acquiring automatically a new valid login token.

Recurring Runs

For subsequent runs, after validating that the user is paired, the application continues its operation as usual.

Initiation Errors

If anything goes wrong during the initiation stage, the approver initiation process will be aborted.

Prerequisites

1. An initial login token of a valid user within Inabit with the role: 'apiSigner'.

2. Enabled communication with the Inabit server (valid URL and whitelisted IPs and ports).

Deployment

From within the root directory inabit/inabit-remote:

Set Login Token

• The login token is approver's token valid for 30 days, allowing authentication with Inabit.

• The token is automatically refreshed, i.e. switched to a new 30 days valid token, on:

  • each docker init.

  • every 15 days (configurable)

• The refreshed login token is saved to a mapped volume on host machine.

• The login token must be mapped to a selected location in the host filesystem for initialization and persistency.

• Create a folder named refresh.

• Set into the folder the login token file r.dat (which includes the login token).

• Map the folder in the docker-compose.prod.yml:

• Add the following environment variables in correspondence:

Build

Run

Required Configurations

The required config can be provided in 2 ways:

1. Baked into the docker by building the docker with a valid .env file.

2. Through the docker-compose.prod.yml file variables override section environment.

In case using .env is selected, remember to modify or remove the environment: section, from docker-compose.prod.yml. In case of a change of the .env , a new docker image build must proceed.

Required Environment Variables

Important

The approvers' key must be mapped to a selected location in the host filesystem for persistency. This is the required combination of env variables:

In the Docker Compose file:

Ensure Correspondence

Ensure there is correspondence between the volume mapping and the selected KEY_FILE_PATH settings. The volume mapping in the Docker Compose file should reflect the chosen KEY_FILE_PATH for persisting the encrypted key:

Pairing

On Docker init , it is first checked if the approver is in status Paired or WaitingForApproval.

If not, a pairing flow starts:

Within the flow interaction with Inabit,

1. a pairing data is exchanged with Inabit including the public signing key of the approver.

2. an approval message is sent to the owner of the organization.

3. a pairing code is produced in the approver start up log trace, and must be passed directly to the owner for pairing completion.

Wish to see how you can automate approving and signing transactions?

Overview

This standalone project is designed to be deployed on a user's own server, enabling integration with inabit from remote.

Its primary purpose is to facilitate the approval of pending transactions within a gated approvals flow. This is essentially replacing an owner/approver's mobile approvals app, allowing users to control approvals on their server.

Functionality

Upon running, the application must successfully initialize and communicate with Inabit. This involves several steps depending on the initiation state. If the 'signer' is approved, the handling of pending transaction flow may proceed.

First Run

During the first run, a pairing process is initiated. This includes:

1. Logging into Inabit using the provided login token.

2. Validating the user's current state.

3. Requesting a pairing token.

4. Producing an encrypted key used for signing, saving it to a mapped volume.

5. Sending pairing data to Inabit and requesting the 'Owner' to authorize the approver.

6. Refreshing the login token i.e. acquiring automatically a new valid login token.

Recurring Runs

For subsequent runs, after validating that the user is paired, the application continues its operation as usual.

Initiation Errors

If anything goes wrong during the initiation stage, the approver initiation process will be aborted.

Prerequisites

1. An initial login token of a valid user within Inabit with the role: 'apiSigner'.

2. Enabled communication with the Inabit server (valid URL and whitelisted IPs and ports).

Deployment

From within the root directory inabit/inabit-remote:

Set Login Token

• The login token is approver's token valid for 30 days, allowing authentication with Inabit.

• The token is automatically refreshed, i.e. switched to a new 30 days valid token, on:

  • each docker init.

  • every 15 days (configurable)

• The refreshed login token is saved to a mapped volume on host machine.

• The login token must be mapped to a selected location in the host filesystem for initialization and persistency.

• Create a folder named refresh.

• Set into the folder the login token file r.dat (which includes the login token).

• Map the folder in the docker-compose.prod.yml:

• Add the following environment variables in correspondence:

Build

Run

Required Configurations

The required config can be provided in 2 ways:

1. Baked into the docker by building the docker with a valid .env file.

2. Through the docker-compose.prod.yml file variables override section environment.

In case using .env is selected, remember to modify or remove the environment: section, from docker-compose.prod.yml. In case of a change of the .env , a new docker image build must proceed.

Required Environment Variables

Important

The approvers' key must be mapped to a selected location in the host filesystem for persistency. This is the required combination of env variables:

In the Docker Compose file:

Ensure Correspondence

Ensure there is correspondence between the volume mapping and the selected KEY_FILE_PATH settings. The volume mapping in the Docker Compose file should reflect the chosen KEY_FILE_PATH for persisting the encrypted key:

Pairing

On Docker init , it is first checked if the approver is in status Paired or WaitingForApproval.

If not, a pairing flow starts:

Within the flow interaction with Inabit,

1. a pairing data is exchanged with Inabit including the public signing key of the approver.

2. an approval message is sent to the owner of the organization.

3. a pairing code is produced in the approver start up log trace, and must be passed directly to the owner for pairing completion.

Wish to see how you can automate approving and signing transactions?

Overview

This standalone project is designed to be deployed on a user's own server, enabling integration with inabit from remote.

Its primary purpose is to facilitate the approval of pending transactions within a gated approvals flow. This is essentially replacing an owner/approver's mobile approvals app, allowing users to control approvals on their server.

Functionality

Upon running, the application must successfully initialize and communicate with Inabit. This involves several steps depending on the initiation state. If the 'signer' is approved, the handling of pending transaction flow may proceed.

First Run

During the first run, a pairing process is initiated. This includes:

1. Logging into Inabit using the provided login token.

2. Validating the user's current state.

3. Requesting a pairing token.

4. Producing an encrypted key used for signing, saving it to a mapped volume.

5. Sending pairing data to Inabit and requesting the 'Owner' to authorize the approver.

6. Refreshing the login token i.e. acquiring automatically a new valid login token.

Recurring Runs

For subsequent runs, after validating that the user is paired, the application continues its operation as usual.

Initiation Errors

If anything goes wrong during the initiation stage, the approver initiation process will be aborted.

Prerequisites

1. An initial login token of a valid user within Inabit with the role: 'apiSigner'.

2. Enabled communication with the Inabit server (valid URL and whitelisted IPs and ports).

Deployment

From within the root directory inabit/inabit-remote:

Set Login Token

• The login token is approver's token valid for 30 days, allowing authentication with Inabit.

• The token is automatically refreshed, i.e. switched to a new 30 days valid token, on:

  • each docker init.

  • every 15 days (configurable)

• The refreshed login token is saved to a mapped volume on host machine.

• The login token must be mapped to a selected location in the host filesystem for initialization and persistency.

• Create a folder named refresh.

• Set into the folder the login token file r.dat (which includes the login token).

• Map the folder in the docker-compose.prod.yml:

• Add the following environment variables in correspondence:

Build

Run

Required Configurations

The required config can be provided in 2 ways:

1. Baked into the docker by building the docker with a valid .env file.

2. Through the docker-compose.prod.yml file variables override section environment.

In case using .env is selected, remember to modify or remove the environment: section, from docker-compose.prod.yml. In case of a change of the .env , a new docker image build must proceed.

Required Environment Variables

Important

The approvers' key must be mapped to a selected location in the host filesystem for persistency. This is the required combination of env variables:

In the Docker Compose file:

Ensure Correspondence

Ensure there is correspondence between the volume mapping and the selected KEY_FILE_PATH settings. The volume mapping in the Docker Compose file should reflect the chosen KEY_FILE_PATH for persisting the encrypted key:

Pairing

On Docker init , it is first checked if the approver is in status Paired or WaitingForApproval.

If not, a pairing flow starts:

Within the flow interaction with Inabit,

1. a pairing data is exchanged with Inabit including the public signing key of the approver.

2. an approval message is sent to the owner of the organization.

3. a pairing code is produced in the approver start up log trace, and must be passed directly to the owner for pairing completion.

Wish to see how you can automate approving and signing transactions?

Terminal Documentation Overview

The inabit Terminal is your command center for managing digital assets, processing payments, and automating Web3 operations — all in one secure, intuitive interface.

Whether you're embedding crypto widgets into your platform, automating fund flows, or fueling cross-chain transactions, this documentation will guide you through everything you need to know to get started and scale confidently.

What is our "Terminal"?

The Terminal is a powerful platform designed for crypto-native teams, fintechs, and enterprises to manage wallets, payments, and infrastructure effortlessly.

With the Terminal, you can:

• Create embeddable crypto payment widgets

• Automate gas and sweeping operations

• Process crypto-to-fiat purchases

• Manage your organization’s wallets, transactions, and webhooks

• Maintain full control while relying on secure, compliant infrastructure

Table of Contents

This documentation is organized into two main sections:

⚙️ Terminal Guide (UI)

Step-by-step guidance for using the inabit Terminal through the web interface.

🛠️ API Endpoints

Everything you need to integrate Terminal features into your backend systems.

In this section you'll find all of the prerequisites & configuration that must be done before creating widgets in order to fully automate the terminal's clearing process. This is a must-have step.

inabit supports major blockchain protocols (mainnet) and nearly limitless digital assets in its system. This page gives an overview of all of the blockchains we support.

Supported functions

Not all blockchains function identically, so we support different features depending on the technical constraints of each blockchain. In the table below, you can compare which broad feature sets are supported on which blockchains.

inabit supports multiple assets

The table below provides the native assets (Blockchain assets) that we supports (that aren't tokens).

Table Columns:

• Financial Asset - the name of the digital asset

• Blockchain Code - the blockchain on which the asset exists

Supported Native Assets