The Flip Sync API for users and channels

Further guidance on this topic:

Sync API: Asynchronous error handling

Sync API: Restricting interactions

Sync API: Common problems


The domains of the Sync API are as follows:

  1. Create, read, update, and delete (CRUD) user information
  2. Create, read, update, and delete (CRUD) channel information
  3. Create, read, update, and delete (CRUD) channel memberships and channel roles for users
  4. Create, read, update, and delete (CRUD) tag rules regarding the restriction of interactions between users
  5. Read the state and errors of asynchronous requests

In the first step, please ask your contact person at Flip to create an API client configuration for you. You will then receive all the information you need to work with this API.

The Flip Sync API allows you to automate populating your Flip instance with users and channels. You must build a connector between your existing data source and the Flip Sync API to enable seamless data synchronization between the two systems.

Master data.png

Important aspects to consider before implementation

It is important to think about certain things as they directly affect the user experience.

If employees need to log in with a username and password, they need a username that is easy to remember and unique. It’s up to you how the username looks like. Here are three common use cases:

  • In cases where each user has a known email address, this is used as the username, as this ensures uniqueness.
  • In other cases, a username with the pattern “firstname.lastname” is used. Since uniqueness cannot be guaranteed with a large employee base, a number is often added: “firstname.lastname2”.
  • If employees know their employee number from the source HR system, it’s also possible to use this as a username.

Another essential decision is whether an employee must agree to the terms and conditions before using the app regularly. This information can be provided to each individual user via the API. You have the following options:

  • Do not ask, which is the current default.
  • Ask on next login.
  • Ask on first login.

In general, we recommend looking at every attribute that can be passed with the API and making decisions before implementation.


Sync API specification

Please find our API specification at the link below. To familiarize yourself with the specifications, we recommend testing the API with Postman, Insomnia, or a similar tool.

Please note that “groups” means “channels” in the documentation. This is because the corresponding functionality was renamed after the API was published.

Flip API Documentation


Suggested strategies to implement

Delta processing of data, querying the async request endpoints, and queuing are three mechanisms we suggest you implement in your connector.

Efficient data synchronization with delta processing

Consider sending only updates to the Flip Sync API for daily data synchronization. This reduces data volume, significantly improving the performance of your connector and the Flip application. Achieve this by building a delta processing mechanism that compares your data source with Flip data. Only the difference, or “delta”, must be sent to the Sync API.

Tracking asynchronous API responses

The Flip Sync API is asynchronous, meaning it does not confirm success or failure for every request. Instead, it simply acknowledges receipt with the 202 response code. You must query the asynchronous request endpoints to identify possible errors from your data updates. See our specifications for a detailed description. Your connector should automatically send requests to these endpoints to simplify error tracking and provide valuable feedback on any issues with your data.

Reliable data delivery with queuing

Implement a queuing mechanism that sends data in batches to the Sync API. This queue handles data chunks by sending them one at a time. Data is only released from the queue upon successful events, such as acquiring a request token. If an error occurs after sending data, the affected user or channel will automatically be routed to a separate error or secondary queue. This, along with querying the asynchronous request endpoints, makes it possible to keep track of all the data sent to Flip. It gives a complete view of potential issues and ensures data is sent successfully.

By implementing these mechanisms, your Flip connector will transform into a more effective and dependable data bridge, streamlining the data transfer between your system and Flip.

Was this article helpful?

0 out of 0 found this helpful

Have more questions? Submit a request



Please sign in to leave a comment.