Create Custom Fibery Integrations Apps (Fast)

We are happy to announce that you can create your own custom integrations apps that will sync data from external source into Fibery. It means you may integrate Fibery with your custom software, your database or any existing tool with API relatively quickly. For example, you can create an App that sync Stripe transactions and link them to your CRM in Fibery. Or an App that fetches feedback from your Slack community.

Here is the guide how to implement an App that syncs public holidays for selected countries.


The app you created can be installed in your Fibery workspace and managed as all the other Apps. So you can install it, configure it and delete it if needed.

2022-01-19 14.49.43

If you are a developer, we hope you will try to build something cool and share it with us! Your feedback will help us improve this thing and open Fibery Apps Marketplace in the future.


Ahhh, I have been hoping for something like this. Excellent!

Might these be shareable one day, like app templates?

1 Like

Running through the sample app example docs and repo

  • The repository is missing a line in the package.json file, just below this line
    • It should be "start-simple": "node ./samples/simple/index.js"
  • The discussion around the token/authorization is a bit confusing. When tokens are mentioned in this kind of context, there are lots of things that could be referenced. Fibery API token, some kind of authorization with the fibery integration SDK, some kind of external service’s token, or in this case we are referencing the dummy dataset’s key to identify which user’s data would be sync’d. When you add the integration, you are presented with this screen, which has a lot of ambiguity about what is being asked for.

It wasn’t clear to me initially that it would be looking for token1 or token2 until looking at the source code, then realizing it was looking up from the local dummy dataset.


Actually, I’m just noticing that there are two types of apps referenced there in the docs and I’m not sure what the difference is which this post (custom fibery integration apps) is referencing. There are separate sections for custom apps and integration apps.

1 Like


Will test this out using the guide!

Looks like this might help achieve what we needed (🧮 Feature Suggestion: Query from external database and create types and entities)


1 Like

The endgame is marketplace, but we will think what is the next step to make it happen


Looks like this will help indeed.

Hi, @rothnic

There are several types of apps.
Custom Apps are responsible for visualizing data.
Integrations Apps are responsible for data synchronization.

They have several common endpoints and sometimes one app can be responsible for visualisation and integration by implementing endpoints for both app types in one web app.

But totally I understand your confusion. We will rename things to make it clear.

Thanks for feedback.

1 Like

Thanks, yeah something that gives a quick explanation of if you are doing xyz, then use this, if doing ABC then use this other thing would be helpful.

I did notice the examples under “custom apps” are related to vizydrop. Are you saying that the “custom apps” are to utilize custom data sources within the report view area? So, custom apps are for vizydrop/fibery reports, while integration apps are for fibery databases?

1 Like

Is it possible to use Rules to push Fibery events/changes to a connected service? (i.e. for two-way sync)


@Oleg, I’ve been working through building a custom app to learn this a bit better and ran into a question. I specifically was a bit confused with all the authentication/validation endpoints required, so I decided to work through an example using an authenticated google API. I think having an example of how to do this in addition to the simple example would go a long ways for demonstrating best practices in a more comprehensive example. My questions:

Question 1: Is this how the initial screen in oauth2 authentication should look?

Since this is a nodejs app, I am using google’s nodejs oauth library to authenticate using oauth2. I was actually surprised that I was able to get to the point where I got my custom app authorized to pull data associated with my google account without too much issue. I did have one question come from that. In the app authentication config, I wasn’t sure what to put there. In the example, you are asking from some information from the user to mock up some kind of authenticated API access. In this case, I don’t think there is anything to ask from the user until authentication is completed. So, should I be doing anything else to make this step of the app configuration look better? In other words, this configuration of the app, results in the following step.

            authentication: [
                    description: 'Authorize with Google',
                    name: 'Google Oauth',
                    id: 'oauth2',

The above screenshot is what you see after putting in the custom app’s URL. When clicking “Connect”, then you get the popup window that contains the list of google accounts to click on.

Question 2: How should I handle new access tokens automatically obtained by the google oauth2 client?

My main question I had is about what happens after the initial authentication. So, let’s assume we are doing a refresh days after the first authentication. The user maybe manually triggers a sync, so the /validate endpoint of the custom app has information posted to it about the authentication details of this particular account. This includes the last known access_token and the refresh_token, which is originally provided in the initial authentication.

I can use these to set the access_token and refresh_token and the library will automatically get new access_tokens on its own. However, I don’t see how I would be able to synchronously refresh the token myself and return it from the /validate endpoint, since the library is handling it all internally. The library has a way to listen for the token changes, but I’m not sure where I could post those changed values to. This is how I am setting the tokens on the oauth2client in /validate.

// setting this in the /validate endpoint

    refresh_token: req.body.fields.refresh_token,
    access_token: req.body.fields.access_token

Given the way that google’s oauth2 nodejs client library works, I don’t see how I can be sure to return an updated access_token from the /validate endpoint. This means that even though new access_tokens will be granted to the app, the access_token provided by fibery to the /validate endpoint will always be the same one that was originally granted when the app was first authorized for that particular account.

I think that would be possible, but in a round-about way at the moment. Rules can push data to a service’s API, then the custom app can sync data into fibery, but on a periodic basis.

My observations:

1. You can create rules that call a script which can call a web endpoint to change something about it. This is something that could occur before custom apps were possible.

2. Custom apps seem to have the ability to set the sync’d fields as read-only or not.

3. Custom apps seem to not be able to be event-based. They have settings around periodic or manual syncing.


4. However, there is some nebulous discussion around webhooks for custom apps

New synchronization source has been created and app supports webhooks. Fibery will attempt to create a webhook.

Create a webhook in fibery, the custom app, or is the custom app supposed to be creating a webhook in the service we are syncing from? This particular page is pretty confusing to try to follow without some diagram of what is going on.

5. I don’t currently see any way to trigger a refresh programmatically. In other words, some endpoint within fibery that would be the same as the user clicking the “sync now”

1 Like

Hi, @rothnic

So, custom apps are for vizydrop/fibery reports, while integration apps are for fibery databases?

Yes. That’s correct.


We will add an additional example with oauth/oauth2 to show how to use it. In meantime please check oauth example created some time ago for vizydrop:

It is created for vizydrop authentication, but the implementation for integration app can be the same.



Thanks for your feedback regarding webhooks and possiblities to referesh the database related to integration. Will think about that.

Custom apps seem to have the ability to set the sync’d fields as read-only or not.

Currently the integration app produces readonly databases. Two-way sync is in future plans.


1 Like

Hi @rothnic


OAuth connector authentication configuration is kind of predefined metadata set that includes special id (oauth or oauth2) and should include redirect_uri parameter

authentication: [
                description: `OAuth-based authentication and authorization for access to %YOUR_APP_NAME%`,
                name: `OAuth Authentication`,
                id: `oauth2`,
                fields: [
                        title: `redirect_uri`,
                        description: `OAuth post-auth redirect URI`,
                        type: `oauth`,
                        id: `redirect_uri`,

This metadata will be rendered on UI as:

To be able to introduce refresh token logic first you should store all required data:

  • access token
  • refresh token
  • expiration date (OAuth providers reply with expires_in so it should be converted to date/timestamp)

/validate receives all these parameters. Suggested approach will be:

  1. check if is token is about to be expired (e.g. now < expiration_date - threshold_period, where threshold_period is up to you e.g. 5mins).
    1.1. [Should be refreshed] execute refresh token procedure
  2. check access to account via latest access token and get user name
  3. return object that includes name and if token was refreshed then also include new expiration_date, access_token and refresh_token

Best Regards,

1 Like

I understand that, but the point I was bringing up is that google’s nodejs API library isn’t designed to work that way. They assume you can store off the access tokens at any time, so the only way to know if the token changes that I could see is if you listen for token changes.

@Oleg’s response quoted below gets to that issue. Anyone working with google services requiring oauth will need to have a manual implementation of token management. I’m not saying it needs to change, but I personally would rather use a library, rather than having to implement each API call myself. While I was able to get it work with the nodejs library, it would just appear to fibery that the access_token is never updated and in practice, I probably would be generating more new access tokens than required.

Having the example oauth2 implementation with google should provide a reasonable example for most to get started. Without that example, I was able to get things working, but it took a bit of reading between the lines and trial and error.

Thanks, this will be helpful.

1 Like

@Oleg or @Evgeni_Kisel: I had a remaining question that came up during my google calendar sync example I have been working through.

I don’t see any way to handle the rich text data. I know some of Fibery’s integrations do use it, so I’m assuming that you must be either leveraging the API to get the document, then adding the rich text data. Or, there is something missing from the documentation.

Hi, @rothnic

I don’t see any way to handle the rich text data.

There is a way. Please find below a fragment of field definition in schema responsible for syncing rich field.

  "desc": {
    "name": "Description",
    "description": "Description of the card",
    "type": "text",
    "subType": "md"

As you see there is “subType” attribute. It can be equal to “md” - markdown or “html”. The rich field will created in database for this case and value will be parsed and synced as markdown or html.


1 Like

As alternative, may be it will be more convenient for you to switch to google app password authentication to make things easy to go. At least for development and testing I choose this one.