Tips&Tricks For monday.com Apps Development

For experienced software engineers, building monday.com apps isn’t that different from working on other apps. After all, it’s just a regular backend and/or frontend that heavily relies on the platform API, which is just a standard GraphQL API.

However, when working on real apps, our developers found few moments they wish they knew in advance. We’ll happily share them:

Using Authorization URL

Every app has access to the board it’s installed on using shortLivedToken from the authorization header passed in every request from the monday.com servers. While it’s enough for many tasks, integration apps often need third-party API tokens, long-lived tokens, or some specific configuration for the whole integration.

Fortunately, work OS provides a way to add custom authorization steps using the Authorization URL field in the app’s integration feature configuration. Every time a user adds an integration, they will be redirected to this URL. The app would also receive a token encoded with the app’s Client Secret that contains userId, accountId, and backTo URL. After performing all the necessary steps, your app should redirect the user to the backTo URL, which leads to the recipes configuration page.

Your app can ask for third-party API tokens or lead a user through OAuth authorizations of other platforms, collecting keys in the process. Also, it’s a suitable place to get a long-lived token by starting monday.com OAuth flow.

Learn more on the monday.com developers portal.

Understanding monday.com API Complexity Level

Rate limiting in monday.com is based on complexity points. Every API operation has an associated complexity value depending on the structure of the query. A single API call can not exceed 5,000,000 points, and all calls per minute should not exceed ten million points (1M for trial and free accounts; 5M for app reads and writes).

You can get the complexity by adding the complexity node to a mutation or a query. The following fields are available:

• before - allowed complexity before the query
• query - complexity of the current query
• after - remaining complexity after execution
• reset_in_x_seconds - seconds remaining to budget reset

The complexity of multiple queries would add up. It means that nested queries would grow exponentially in complexity. Monday platforms encourage pagination by adding page and limit arguments to your calls. Paginated calls would typically have lower complexity than the 1,000 you usually get for querying objects without limits. You can still get all the data, just with more calls.

When the limit is exceeded, a query would still return a regular 200 OK response but with an error that looks like this:

{
  "errors": [
    {
      "message": "Complexity budget exhausted, 
      query cost 100001 budget remaining 99810 out of 1000000 reset in 40 seconds"
    }
  ],
  "account_id": 1234567
}

It’s better to add some throttling logic to your code that would delay the query if it’s about to hit the limit and would certainly wait after hitting it. In monday.com apps, it can even be done on a trigger side if you know that trigger will start an action that would hit the limit - postpone the trigger and don’t worry about shortLivedToken expiration.

We often calculate query complexities during app development to plan how many things we can do in a minute and predict maximum load, latency, and user experience based on that. During initial synchronizations, it’s worth spreading the calls rather than bursting a few dozens and then waiting for almost the whole minute to repeat. It provides visual feedback to the user that the app is still working and the process takes some time.

Read more in the Rate Limits article on the monday.com developers portal.

Manual Recipe Retries

By default, if your actions haven’t responded with 200 OK status, the monday.com platform will retry calling your action endpoint every minute for 30 minutes. It’s more than enough for most scenarios, but in some cases, like talking to external APIs that went down and won’t be back that soon, your app might miss the action.

The simplest way to handle this would be to start some “timer” when the app sends a trigger and stop it when it has successfully executed an action. You can use queues, database records, or whatever else you like for a timer. If it counted these 30 minutes, your action wouldn’t be called anymore, and the app should handle this exceptional case by, for example, firing the same trigger again.

In real life, things aren’t often that simple, though. Trigger and update order updates usually matter, or the user might have been interacting with the item that should’ve been updated, etc. The app should track that and avoid updating items with older data.

Clearing Fields in Item Mapping

Item mapping is a powerful mechanism for data synchronization between monday.com work os and other platforms. It allows the users to fine tweak how they want to project and transform the records.

Implementing it in a monday.com app is pretty straightforward. However, there’s one catch: while the platform accepts empty values and null for simple fields, they don’t work for JSON fields in mapping. Most of the time, it’s not too big of a deal, but occasionally the app might need to clear those fields. The problem is - there’s no way to know the mapping configuration if a trigger sends an empty value. It’s just not present in the action request at all.

Unfortunately, the only way we know to overcome it is to use some magic values to mark no data. Those would go all the way through and end up in the action request. Of course, you’ll need to replace them to empty values there manually. Try to choose a magic value that won’t occur in the actual data or at least has nearly zero chances of being there. We also suggest writing a short framework to handle replacements back and forth and using default constants for those values in most cases.

Conclusion

Building monday.com apps is indeed a pretty straightforward process. It’s not that different from developing regular backends and frontend apps. There are some specifics, and we suggest carefully reading the API documentation and their Apps development guides before working on apps.

We haven’t covered everything here, so if you have more questions, don’t hesitate to contact us using the form below.