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...
- Meet the Developer Experience Team
Send an email to [email protected] and say hello! We'd love to hear about your use case and timeline so we can get you started on the right foot. We'll also set you up with Sandbox Access so you can have a test API token and Routable Dashboard to work with when developing your app.
- Enabling your API
To start using the API, you'll need an API Token. You can generate one on your Routable Dashboard. Note that to make a token for your sandbox, you'll need to log into the sandbox version of the Routable Dashboard with the credentials you got in step 1 above. 🚢.
- Build in our Sandbox
To make your API experience as stress-free as possible, we have a full-featured sandbox environment that lets you do everything you can do in production... without moving real money or worrying about customers and vendors getting emails they shouldn't!
- 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_sendstate by setting
send_on=nullduring the initial launch of their integration to give their finance team a chance to give a sign off ✍️ before going fully automatic.
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.
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.
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.
Updated 3 months ago