Contents

Introduction

Modern Treasury now supports API access by user-managed keys. Instead of relying on a single key to gate all API access for an organization, developers can create new API keys, each with their own set of permissions. Additional key options include read-only access, individual account access, IP address restriction, and archiving. Each API key generates its own request log and audit trail, so developers can gate and audit API access to their Modern Treasury instance with fine granularity.

These features round out a suite of developer features that enable customers to build more efficiently and confidently on top of Modern Treasury.

Viewing API Keys

Users with the “View” developers permission can view the list of API keys by navigating to the “Developers” tab.

Developers can easily retrieve the organization ID and API key secrets from this view for authenticating their API calls to Modern Treasury. When an API key’s secret is copied, an audit record event of that user requesting the API key secret will be recorded.

API keys that have been archived are viewable by toggling the “Include Archived” search option.

New API Keys can be created by clicking the “New API Key” button in the top right of the search area. This is only available to users who have the “Manage” developers permission.

Creating New API Keys

New API keys can be created with a name, a list of restricted IP addresses, and a set of permissions. Permissions cannot be edited after the key has been created.[1] Keys can be created with read-only permissions, and even per-bank-account level permissions.

API Keys can be viewed and edited after creation or by clicking on the API key in the list view.

This view shows additional information like who created the API key, when it was created, its list of permissions and the list of allowed IPs (if specified). Developers can see and copy the organization ID and API key secret here as well.

This page also shows an audit trail of the entities created or changed with this API key. This is only viewable by organization admins.

Clicking on the Actions dropdown badge reveals the following options:

  1. “View API Logs” will bring the user to the API Logs page, scoped to API requests made by this API key.
  1. “Edit” will allow the user to edit this API key (available only to users with the “Manage” developers permissions).
  1. “Archive” will prompt the user for confirmation before archiving this API key (available only to users with the “Manage” developers permissions). 

Editing API Keys

Users can edit the name and list of allowed IP addresses of an active API key. The permissions assigned to an API cannot be altered after the key has been created. Archived API keys cannot be edited.


Archiving API Keys

API keys can be archived as part of a routine key rotation process or if an API key secret has been compromised. To do this, click on the “Archive” option of an active API key and confirm the prompt that appears. Archived API keys will indicate their status in a red banner at the top of the page. Users can still view the API logs of an archived API key.



Note: Accounting IDs Moved

The “Configuration” page underneath the Developers navigation section has been removed. If an accounting integration was configured (Quickbooks, Netsuite), this page displayed the mapping of accounting category and classes to IDs for use within Modern Treasury. This information now lives under the Settings -> Organization tab (again, only appearing if an accounting integration was configured).

Conclusion

If you're interested in managing payments securely through API, we are happy to help. Send us a note to get in touch.

References

1.

If the permission levels of an API key could be changed, it would be extremely difficult to conduct an audit of a maliciously used key. The investigator would have to correlate the audit trail of permission changes made to the key (and by whom) alongside the request logs of the key at a given point in time. For these security reasons, it was decided that forcing the user to create a new key instead of allowing them to change an active key was preferred.

2.
3.
4.
5.
6.
7.
8.
9.
10.