Welcome to Routable!

Before we dive into the details, we'll show you how to get your integration from sandbox to production with a handy checklist so you know exactly what to expect along the journey...

🔐

1. Create an API Token

To start using the API, you'll need an API Token. You can generate one on your Routable Dashboard. Note that to make an API token for your sandbox, you'll need to log into the sandbox version of the Routable Dashboard with your sandbox credentials. 🚢.

🏖

2. Build in our Sandbox

The Routable sandbox is a full-featured environment that lets you do everything you can do in production, without moving real money, dealing with real banking information, or worrying about customers and vendors getting emails they shouldn't. You can develop code against this environment, integrate it with a testing environment in your accounting software and see your transactions carry through in the Routable Dashboard. 💸

🚀

3. Ship to Production

Once you're happy with the behavior in the sandbox, it's time to ship to production! Many of our customers opt to put their payables and receivables in a ready_to_send state by setting send_on=null during the initial launch of their integration to give their finance team a chance to give a sign off ✍️ before going fully automatic.

About our API

Standards

Routable's API follows a RESTful architecture and uses JSON for data transfer. Payloads should be sent in the raw body of your request. Our API requires HTTPS connectivity; requests sent over HTTP will be rejected.

Unlike Routable's legacy v0 API, our current API no longer implements the JSON:API standard. A discussion of why we made this decision can be found here.

Versioning

Routable numbers versions that contain breaking changes using the date they were released. Improvements that provide additive functionality only and do not constitute breaking changes are not assigned a version number, however, they can still be found in the Changelog. Every effort is made to minimize breaking changes. Routable commits to maintaining prior versions in working order for the foreseeable future, such that implementations may rely on legacy versions without an urgency to upgrade until you want to take advantage of new improvements.

The following types of changes may be made without notice, and you should write your code and tests such as to not fail should they occur:

• We may add new endpoints and new fields to resources at any time, so users should not expect exactly the same list of keys. These new endpoints and fields may not be immediately documented, and any such changes should not be implemented in your production code as they are subject to change.

• We may add optional request parameters to endpoints and optional additional fields to resources in create/update requests. We will not make any new parameter or field required without flagging it as a breaking change, though we may expose new fields on resources with a default value that will be present on newly-created resources without changing your requests.

• Once we have documented a change and announced it in the Changelog, it can be accepted as "released" and may be reliably used. We will not remove, rename, or reformat existing documented parameters, fields or endpoints without a breaking change notification, Changelog entry, and a new version number.

Rate Limiting

There are also usage limits enforced by Routable’s services. By default, Routable limits API requests to 600 per minute. This seems reasonable for most uses of Routable’s API. There's a little more to it, but that’s the basic idea. If you exceed the rate limit, you will receive a 429 Too Many Requests error. If you need to process lots of requests at once, Routable has a bulk import process that you can use from the Routable Dashboard.