Implementation Checklist

Implementation Checklist

A full Rutter implementation requires both a frontend and a backend application. The backend server securely manages the requests and responses to and from Rutter APIs. The frontend application provides an interface for initiating authentication and managing data from third-party platforms via Rutter.

High level Implementation Steps

  1. Set up Rutter Developer Account
  2. Configure platform connectors in Rutter
  3. Implement Rutter Link
  4. Perform Rutter API testing
  5. Integrate Rutter APIs into your backend
  6. Go into Production

1: Set up Rutter Developer Account

Set up user accounts

Set up the environment

  • Sandbox Mode – The sandbox environment allows you to test out the REST APIs without the need to connect to an underlyingexternal platform. For more information about our sandbox, click here.
  • Production Mode – To test out the platform’s end-to-end connectivity, you’ll need to connect to a third partyn external platform using the Rutter production environment. Request production access if you don’t have access.
  • Staging vs Production Environment - Set up 2 different Rutter user accounts for staging vs production environment to test.

Get your API Keys

  • Acquire your credentials from the API keys page. These credentials will authenticate your requests and grant you access to Rutter API's functionality.

2: Configure platform connectors in Rutter

Enable Platform Connectors

  • Enable the connector - Select a list of platforms you want to enable in the Platforms page.
  • Review the developer app requirements — Depending on your target platform integrations, you may need to set up a developer account (eg. QBO, Xero) and acquire developer credentials.
    • If developer app is required, make sure to configure your developer credentials in the Platform page. We’ll be using your developer credentials used to authenticate and access the API.

Data sync configuration

We recommend configuring the following data sync settings in the dashboard.

Initial Sync

  • Configure the Rutter Objects to import - To ensure all the Rutter objects are imported, we recommend first understanding the dependencies of data objects. For example, to work with bills, you need vendor information.
  • Configure batching - Take a Batching strategy with the Data Sync Configuration. This will ensure that there is a quicker time to value to start using the endpoints based on the initial batch that completes. At the same time, the secondary batches will continue to load in older data from the platform, as set in your configuration. Rutter recommends a minimum of two batches as part of the initial sync.
  • Configure time range of historical data - Example scenario where you are looking to load in 3 years of invoicing data
    • Batch 1 - Last 1-2 months
    • Batch 2 - Last 2-3 years

Incremental Sync (Ongoing sync frequency)

  • Configure Rutter Objects to import
  • Configure Sync frequency - Rutter can adjust this parameter for you in the backend.
    • These are the scheduled incremental syncs that Rutter evaluates for your connections. By default, this is set to 60 minutes. If you would like to have this lowered, reach out to your Rutter Success Manager.
  • Backfill Options (as needed)

    • Manual backfills can be triggered if needed as well for historical data. An example is if you make an update to an existing connection's Data Fetch Configuration, and you want to sync all historical data for the new objects you've added into the Data Fetch Configuration.

      NOTE: This functionality should only be used on a one-off basis. If you trigger a Backfill, this will pause the scheduled Incremental Syncs that Rutter automatically performs for the connection until the Backfill is complete.

Webhook Configuration

  • Rutter recommends setting up at least one webhook URL to ingest events. The following events are essential and will be processed regardless of your use case:

    INITIAL_UPDATE, HISTORICAL_UPDATE, CONNECTION_DISABLED, CONNECTION_ERROR, CONNECTION_LINK_ERROR, CONNECTION_NEEDS_UPDATE, CONNECTION_UPDATED

Rutter Link is the primary end-user facing authentication flow. It handles the entire end to end process of authenticating an end-user, handling permissions and data governance, and creating and monitoring their consent.

Create a test connection

Retrieve Access Token per connection

  • Rutter Link returns a public_token whenever a customer successfully shares their data with you.
  • However, the public_token cannot be used directly with our API, and must be exchanged for an access_token. Our Token Exchange API endpoint allows you to exchange this public_token for an access_token without human intervention.

4: Perform Rutter API testing

Develop a Test Plan

Develop a test plan that includes testing against a real third party platform and the Rutter environment.

  • Take a look at the Rutter API reference docs to screen for the data fields you need. Our use case guides provide information about the entities you may need for your use case
  • If you are not sure which platforms would require which fields/objects, use the Platform Configuration mapping option at the bottom of the data sync settings in the dashboard
  • Make a list of all the Rutter API endpoints and data fields you need to test

We recommend manually making some API calls to test out the Rutter endpoints. Here are some examples of test cases:

  • Reading data:
    • Check if data object have all the necessary fields
    • Makinge sure that query parameters are available for your use case
  • Writing data:
    • Checking that all input fields required for write requests are working as expected
    • Makeing sure updates and deletes are working
    • Make sure that editing something in the target platform’s software UI is reflected after a while in the Rutter GET responses
    • Makeing sure that you handle the format of Rutter objects like date formats

Making API calls to Rutter

  • Here’s a Postman Collection that you can use to test out the APIs. Once you authenticate and create a new connection, you can enter your client_id, client_secret from your Rutter organization and your access_token created from your connection.
  • In some situations, you may see that the data returned from the Rutter API is unexpected. Depending on the situation, data may be missing, or returned differently than what you expect. Please reach out to your Solutions Architect for assistance.
  • For writing data, understand how idempotency keys can be used with Rutter. This will allow you to safely retry requests without accidentally performing the same operation twice.

5: Integrate Rutter APIs into your backend

Set up live connections

  • If you’re migrating from existing in-house connections or from other unified API platforms (eg. Codat, Merge), you can refer to our migration guide.
  • Otherwise, a new Rutter connection will be created whenever a new customer connects their platform with you. We recommend familiarizing yourself with the connection lifecycle to understand the different stages and notifications available.

Manage Tokens

  • Store user access tokens in the backend data store against users of your application. This should not be exposed client side. We recommend storing them encrypted.
  • Rutter manages authentication and token creation for platform connections, allowing you to focus on working with customer data. Our guide outlined best practices for handling customer data (eg. fetching, syncing, and updating data)

Handling Webhooks

  • Create a worker queue to ingest and check if a webhook is processed
  • We don't recommend solely rely on webhooks to ingest data from Rutter. We recommend regularly polling for updates to keep data in sync with Rutter's system. This can be done with any advanced scheduler (eg. a cron job) that runs at a regular interval based on your company’s needs for data freshness.

Set up Data Pipeline

Set up a data pipeline to handle the following:

Manage connections

  • Monitor connection health and disconnections
  • Update and delete connections
  • Subscribe to connection webhooks to be notified immediately of any changes to connection health of your connections

Mitigate Errors

6: Go into Production

Set up a go live review with your customer success manager.

Testing

  • Set up unit and integration tests written against the Rutter APIs
  • Implement a staged rollout plan. We recommend onboarding a few test users first, and then rolling out to full user base afterwards.
  • Conduct load testing ahead of each stage of rollout
  • Understand Rutter's rate limiting to ensure your implementation strategy is consistent

Monitoring and support

  • Ongoing enablement and localization support for global platforms
  • Monitor errors and performance
  • Ramp up support team to troubleshoot Rutter issues
Next
Dashboard