API Key Security

An API key is a credential which identifies your application to Column and grants it access to the Column API. Think of this as the password that lets your application connect to Column. To protect your platform, Column provides a few security controls to limit a key's ability to perform unintended actions. These protect you in case your application does something it shouldn't or a key is compromised.

Keys are issued and managed from the dashboard, not through the API. Each key is bound to one platform and one mode. To use an API key, take a look at Authentication.

Sandbox and Live Mode

When you create an API key, you must specify if that key can access sandbox or live mode. Once created, a key's mode may not change. We recommend using sandbox keys to test your application and make sure everything is working as expected before sending real money. Check out sandbox and testing to learn more about this.

You can easily identify a key's mode by looking at its prefix:

Mode

Prefix

When to Use

Sandbox

test_

Testing the behavior of Column APIs, building your application.

Live

live_

Launching your application and moving real money.

Permissions

Permissions restrict a key's access to your platform, just like Roles & Permissions:

Setting

Behavior

Full Access

Key can view all account activity, make changes to account information, use the account to initiate transfers, and create new entities and accounts.

View Only

Key can view all account activity, but cannot make changes to account information or use the account to initiate transfers.

Custom

Starting with View Only access, add on additional functionality and edit permissions you'd like to add to the Key.

Custom

The following permissions are available to API keys. Permissions on transfers, entities, and accounts may be overridden on a per-entity and per-account basis. We recommend configuring a key with access to only what it must access; you can always update this later if your application changes.

Access Levels

Permission

Access Levels

Set

Override per Entity/Account

Transfers

Create & Edit, View Only

Per transfer type

Yes

Entities

Create & Edit, View Only, No Access

Once per key

Yes

Bank Accounts

Create & Edit, Edit Access, View Only, No Access

Once per key

Yes

Each transfer type - ACH credits, ACH debits, ACH returns, wires, deposit checks, issued checks, book transfers, realtime transfers, and stop payments - is set independently, so a key can be granted Create & Edit on ACH credits while remaining View Only on wires.

Additional Permissions

These are separate from transfer and account access, and cannot be overriden per-entity or per-account.

Permission

Access Levels

Counterparties

Create & Edit, View Only, No Access

Loans

Create & Edit, View Only, No Access

Reports and Statements

On, Off

Limitations

There are several actions that are unavailable to keys and are restricted to the Column dashboard:

Approving Transfers: Transfers can only be reviewed by Users in the dashboard.
API Keys: Keys cannot create, delete or access other keys (or themselves).
Platform & User Management: Platform configuration, inviting users, removing users, and configuring access can only be performed in the dashboard.

Transfer Approvals

Approvals hold an outgoing transfer in "Pending approval" state until a User reviews it. An API key can never approve a transfer, regardless of whether or not it created the transfer. Platform-level approval rules (configured under the Settings page) do not apply to API keys; keys are configured individually. We recommend enabling approvals while testing an application.

To configure approvals for a key, first configure the key's permissions to allow transfer creation. A Transfer Approvals setting will then appear:

Setting

Behavior

Not Required

No transfer from this key is held.

Required

Every eligible transfer from this key requires review.

Custom

Configure which types of transfers require review.

Coverage is limited to ACH credits, ACH debits, issued checks, wires, and realtime transfers. Other transfer types originated by the key — including ACH returns — are not held.

Best Practices

Store keys securely. Never put keys in source code where they could be leaked to bad actors. Always use a secure storage mechanism, such as a secrets vault.

Follow the principle of least privilege. Choose Custom rather than Full Access, and enable only the transfer types, entities, and accounts your application needs. If a key only needs to read, leave it at View Only.

One key per workload. Each of your applications should use a separate key. This improves your ability to track and reduce the blast radius of compromised keys.

Rotate periodically. Keys do not expire, so rotation is a procedure you own: issue the replacement, cut traffic over, and confirm the old key is no longer in-use before deleting. Perform rotation regularly to ensure you know where keys are used and have procedures in place to replace the key in an emergency.

Revoke compromised keys. If you believe a key has been compromised, revoke it immediately to reduce the risk of unauthorized fund movement. Then replace it with a new key.

Consider IP whitelisting. Column can restrict API access to specific IP ranges. If this is of interest to you, we're happy to chat.