API Credentials Supercharged!

We're excited to showcase a long-requested new feature we've added to the Routable API. Starting today, you can create multiple Routable API credentials simultaneously, and give each their own permissions!

Before today, a Routable Workspace had but one API token, and it was always an administrator, able to do anything in the API. For flexibility, compliance and security reasons, our clients have long wanted more granularity.

Now, when you visit the API Access section of the Routable Dashboard, you'll have the option to create and destroy multiple API credentials and select the permission level of each.

For permissions, you'll have three options:

• API Limited creates a limited-access token, perfect for reporting applications, data warehousing, and other applications where creation of resources like Payables and Companies is unnecessary and unwarranted.
• API Standard creates a token with all of the same permissions Routable's legacy API tokens had, able to perform most functions. All existing API tokens have been assigned the API Standard role as part of this rollout.
• API Enhanced is the highest level of permission, and is not needed except for specialized applications. It can do everything API Standard can, but can also retrieve extremely sensitive data like vendors' government ID numbers that are hidden by default with API Standard. In order to minimize the risk of exposing this privileged data, we recommend not using API Enhanced unless your application has a specific need for the additional data it unlocks.

As you'll see, multiple tokens can now be active at once. This not only unlocks the ability to separate out applications by their permission levels and clean up the audit logs, it also allows for more painless rolling of credentials on a periodic basis without incurring downtime or service interruptions for your application. Your IT team can make a new token, change over your applications to use it, and retire the old token as soon as the migration to the new credentials are confirmed working. This has long been recommended best practice for all API credentials, but the need to destroy the previous token to create a new one made that a logistical challenge prior to this release.