New webhooks for monitoring Payables and Receivables

Hey there, friends! It's almost fall here at Routable HQ, and the new features are dropping as fast as the leaves. We're happy to announce two new webhook events we're deploying this week: payable.creation_failed and receivable.creation_failed. You might be asking yourself, "Self, why do I need webhooks if I can get a 400 Bad Request when I make a Create a Payable or Create a Receivable call?" An excellent question, so let's make sure you can answer... yourself.

The 400 Bad Request response is what you get when there's an issue creating a Payable or Receivable at create time. This means it'll catch situations where your request payload is somehow invalid: a field is missing, an object referenced by ID doesn't exist or is in a bad state, things like that. Essentially, everything we can check in the instant your Create a Payable request crosses the wire, we check, and return a 4xx error if there's anything amiss.

Once the API responds with a 201 Created or 202 Accepted, though, that's when the power of this fully-operational payment processing station really goes to work, coordinating the flow of funds between banks across the street or across the globe and making sure everything is synchronized perfectly with your accounting platform, whether it's QuickBooks Online, Sage Intacct, Xero, or Oracle NetSuite. These processes can take time, so we perform them asynchronously with the API create request itself. If one of these subprocesses failed - for example, if the accounting platform is having an API issue and we can't connect to it - the Payable or Receivable can't be created even though we've already sent you an ID for the transaction we were in the process of creating. Previously, these failures could "fall between the cracks" and were not reported to applications implementing the Routable API, and they could result in some mismatches and missing transactions between your code and Routable. They'd sometimes result in your accounting team having to reach out to Routable's top-notch support teams to help track down the missing transactions. As much as we love chatting with your finance teams, you're busy people with other stuff to do, so we've given you the means to automate dealing with these situations.

Now, with these two new webhooks, you can have your app react when these "delayed failures" occur, whether by re-submitting them at a later time, changing faulty data, or any other other logic you might want to execute. In the webhook event's detail object, you'll find an errors object with any error messages or other data we have about what went wrong. That object will also include the request_id for the original creation request you sent, as well as any Idempotency Key you used on the transaction and any external_id you provided, to help you match up the transaction in your system with the one Routable tried to create.

As always, you're welcome to reach out to Routable's Developer Experience Team with any questions or if you need a hand solutioning a response to these failure conditions. We'll have a virtual donut and work together to get your integration running smoothly so you can get back to... all those other fun fall activities!