Welcome to Routable!

This page will help you get started with the Routable API. You'll be up and running in a jiffy!

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. 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.

πŸ”
  1. Enabling your API

We will enable API access for you in our sandbox where you can start building and testing your integration. If you're an existing customer, we'll also enable the API in production to streamline your release later. 🚒.

πŸ–
  1. 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 :money-with-wings: .

πŸš€
  1. 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 customer-facing 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.


What’s Next
Did this page help you?