Rate Limits

Automation Runs

An automation run is a metric of usage for no-code automations/integrations. An automation run is accounted for each time a separate automation action is performed. If an automation fires 5 actions, it'll count as 5 automation runs.

No-code Automation and Integration

• When a new record is created, send a Slack message. (1 automation run)
• When a record is updated to the status "Done" in table A, send an e-mail and create a new record in table B. (2 automation runs).

Zapier Automation and Integration

• Jestor-based Zapier actions or triggers will count as 1 automation run. So if you have a zap that is defined as:

When a record is created in Jestor -> Update a record in Jestor

This will count as 2 automation runs.

Free No-Code Automations

• Some no-code native automations are free of charge. They will not be considered on your runs-per-month rate limit, but they could have a maximum limit. When a limit is not specified, it will be caped at 5.000 runs/month for each automation.
• Free automations will be tagged as "Free" with a green label.

You can access the total amount of free runs at Settings > Usage:

Webhooks

• There are two types of webhooks inside Jestor: Object and Function webhooks. Function webhooks are webhooks that, when activated, run a low-code function. As such, they follow low-code rules, which are described further below in this section.

For a more in-depth example, see Low-code Automation and Integration below.

Combining no-code and low-code automations

• It is possible to combine no-code automations with low-code functions. That is: calling upon a low-code function in the middle of your no-code automation. In this scenario, no-code actions will count as 1 automation run each, and the low-code function will follow low-code rules.

For example, if you have an automation sequence that is something like:

• When a new record is created, send a Slack message, then run a low-code function.

You have:

• When a new record is created (1 automation run).
• Send a Slack message (1 automation run).
• Run a low-code function (low-code usage).

So in this example, you'll have a total of 2 automation runs plus a measure of low-code usage every time this sequence is activated.

📘

Automation Runs Limits

It's counted on a per-month basis, non-cumulative.

Every plan has its own rate limit. You can check it out here.

Are Add-on packages available? Yes.

There are some things to keep in mind when dealing with automations:

🚧

Warnings

1. An automation sequence may activate other automation sequences. For example, if you set up an automation that updates a record, then set up an automation that runs when a record is automated, the second sequence will be activated whenever the first one runs. This may create a large, limit-consuming tree of automations, and may even fall in infinite looping (see Infinite loop and circular recursion below).

2. As the mere act of running automations use processing power, automations will count towards your limit even if they fail, regardless of whether they fail because of logical errors, instabilities, or even if they are blocked for recursion or timeout rules.

Low-code Usage

Low-code usage is the metric of usage for low-code automations/integrations. Usage is measured in GBs (Gigabyte x second) and calculated by multiplying the runtime of the automation/function by the total memory allocated for it.

For example, if you trigger a low-code automation that:

• Had a memory allocation of 128MB, that is: 0.125GB given proper convertion.
• Runs for 600ms, that is: 0.6s.

You will have a total usage of 0.125GB x 0.6s = 0.075GBs.

As low-code automations may vary wildly in scope, this way of measuring usage allows for a more flexible building of internal processes. Small scope automation that run for a brief amount of time will be less consuming than greater scope automations that run for a longer period of time, allowing for a broader use of low-code without penalizing simple processes.

Automation Chains

Depending on how you set your triggers and actions, automation sequences may set off other automation sequences, and run in parallel across multiple levels. For example, if you have these two automation sequences:

• When a new record is created in Sales, create a record in Agreements.
• When a new record is created in Agreements, send a Slack message.

Whenever the first one runs, it will activate the second one. This means the first automation sequence is the first level of the automation, and the second one is the second level. If the second automation set off another automation sequence, it would be the third level, and so on.

This is called an automation chain*, and they can only run seven (7) levels deep**. Automation chains that exceed this limitation may be blocked.

API Calls

API calls and Webhooks will both be measured separately from automation runs. Both will count as "API calls".

📘

API Rate Limit

Maximum of 10 API calls per second, 26,000,000 API calls per month, non-cumulative.

Are Add-on packages available? Only for the Enterprise plan.

The limits above are limits, not performance guarantees:

🚧

Stress-induced limitations

Sometimes API calls may set off automations, or may even take a while to finish because they depend on external processes or manage heavy amounts of data. In these cases, it may not be possible to make 10 API calls in 1 second.

What's an API (Application programming interfaces) call?
APIs are a way for one program to communicate with another by establishing endpoints where programs can make requests (calls) to fetch or send data. APIs make integrations between different tools possible.

Every time one system (A) communicates with another (B) it's an "API call" or "API request". In every request (A to B, or B to A), you can send one (or many) parameters and one (or many) records at the same time.

In other words, every time a request is sent to a Jestor endpoint, it will count as 1 API call.

Example
Running the code snippet below would make an API call to https://documentation.api.jestor.com/object/list to get records/cards from the table "sample_table". So running it once would count as 1 API call.

curl --request POST \
     --url https://documentation.api.jestor.com/object/list \
     --header 'Authorization: Bearer MjE5NzEzYWM0OWU2N2M5cd014f3bd4MTYxNjYwNDg2NWMzM2Nl' \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
     "object_type": "sample_table",
     "sort": "number_field desc",
     "page": 1,
     "size": "100"
}
'

It's important to note that the /object/list endpoint has a response limit of 200 records, so if you have 1,000 records in a table and call the endpoint 5 times in order to fetch them all, it would count as 5 API calls.

SDK Automation and Integration

• Jestor SDKs are essentially shortcuts to API endpoints, so that you can achieve the same results with less code. This means SDK methods are essentially API calls to specific endpoints, and using a method equals to 1 API call.

Webhooks

• There are two types of webhooks inside Jestor: Object and Function webhooks. Object webhooks are webhooks that, when activated, create a record directly in a table. As such, they are essentially public endpoints that you can activate or inactivate at will. This means activating an object webhook once equals to making 1 API call.

Table Size

Records per Table

Each row in a table is a record. There are multiple types of data views in Jestor that are based on tables. As such, you may also think of every card in a kanban as a record, or each line in a list.

It's important to note that views do not count as extra records. If you have a Sales table with 25 records, and activate a kanban view for it, you will still have 25 records total for that table. What counts is the total number of records in the table the views are based on.

📘

Records per table limit

The number of rows of the largest table will be the one that defines your current usage. It's a per-table limit and It's cumulative. If you add more records in different months on the same table, it'll take all of them into account.

Every plan has its own table limit. You can check it out here.

Are Add-on packages available? Yes.

How to release table space

There are two ways to release table space:

• Delete records from the largest table: You can free up space by selecting individual records and deleting them.
• Delete the entire largest table: To permanently delete the table, follow these steps:
  • Navigate to the table and delete it.
  • If you have just deleted a table, it may take some time to update the status of the largest table. During this period, it might display no name until the second largest table becomes the new largest table.

Structural Size

As with any other relational database, our tables have structural size limitations. It can reach a structural limit of bytes of information depending on the number of columns, type of columns, and data in a row. It does not mean you can't have files exceeding this limit, because files are archived in different structures.

Reaching this limitation is common when you have too many columns in a single table. The solution for this problem is to redesign your process or data structure to use more than one table. All the connected table fields could be useful to spread the data into different tables. Thus, creating a much better data structure and best performing internal tool.

📘

Structural limit per table

You can have up to 60,000 bytes of structural data in a table row.

Are Add-on packages available? No.

Table Connections

Jestor is a relational database, you can connect different tables (1:N), (1:1), or (M:N). Every connected table, it's a table connection. Calculation fields (formula, lookup, etc.), connection fields, and user fields (multiple users, users, created by, updated by, record attribution, etc.) have a limit of 20 per table. The ideal for table calculations is to create indicators, charts, and other calculation instruments via App Pages.

📘

Connection per table

You can have up to 20 different table connections pointing to the same table.

Are Add-on packages available? No.

Infinite Loop and Circular Recursion

Sometimes, automation sequences in automation chains may end up activating previously activated sequences. This means the automation will run indefinitely, as it will continue to circle back to previous steps.

We call these types of scenarios infinite loops, or circular recursion, because if not stopped they will run forever.

A classic example would be something like:

• When a new record is created in Sales, create a record in Agreements.
• When a new record is created in Agreements, create a record in Sales.

As it is, whenever a record is created in either Sales or Agreements, an automation will create a record in the other table, and activate an automation that creates a record back in the original table. Because of this logical error, this sequence will never end on its own.

Infinite loops and circular recursion may hurt user experience as it tends to be resource draining and change data indefinitely. Depending on the nature of the recursion, Jestor may automatically block these automation sequences from continuing and disabling the automations that originated them.

🚧

Recursiveness counts towards your rate limits

Regardless of whether the automation sequence is blocked or not, every automation run, API call, or any other rate limit affected by it will still count towards the usage of your account. This will hold true even if the automation is rolled back or causes errors, and the desired outcome the automation is not achieved.

Request timeouts

Whenever your Jestor account makes a request or query for data, there's a maximum amount a time this request will run before being invalidated. The threshold for requests is one minute. This means requests that exceed this limit will hit a timeout and be discarded, and will not be executed fully.

Do note that this is a limit that applies to all requests, such as fetching data for displaying in kanbans or updating a record.

Most requests should be running in miliseconds and, as such, there should be no impact in your account in normal conditions. Timeouts usually occurr as a safety measure for accounts undergoing abnormal usage, such as when suffering from automations stuck in logical loops.

Bots Usage

Bots are computer programs that simulate human behavior.

❗️

It's forbidden. Adding bots on Jestor is against the terms of use

You can't try to simulate human usage using bots. If a bot is detected, the user will be excluded and the account may be blocked.

Sessions by User

A single user can only have up to 5 simultaneous sessions (be it in the same device or across devices). Should a new session (log in) be created which makes this user exceed this limit, one of the previous sessions will be dropped.

🚧

Don't share credentials!

While it is possible to use the same user across devices, we strongly recommend not to share credentials between team members. This is a security issue that could be very detrimental to your account and is considered misuse of the platform.

Data Imports from Connector

You can import spreadsheets to Jestor, automatically creating new records and fields.

📘

Number of Records Imported Rate Limit

Every import has a limit of 7500 cells from a spreadsheet.

Are Add-on packages available? No.

Storage

There are two types of storage limits in Jestor: single files and table storage.

• *Single files: the maximum size of a single file that you upload to Jestor, for example, images or PDFs. For any plan, the maximum size allowed is 100MB.
• *Table storage: the combined size of all files uploaded to a single table or page. For example, if you have a Proposals table with 5 records, and each record has a 5MB PDF file, the total storage used for that table is 25MB. for example images or PDFs. Every plan has its own table storage limit. You can check it out here

Hitting rate limits

If you hit any of the rate limits, you may be blocked from performing actions related to said limit.

For example:

• If you have a limit of 5,000 automation runs and run 5,000 automations in a month, automations will not be set off again until the following month or you expand your limits through add-ons or changing plans.
• If you have a limit of 25,000 records per table and hits a total of 25,000 in a table, you will not be able to create new records until you delete pre-existing records, expand your limits through add-ons, or change plans.

🚧

Plan ahead and don't lose data!

If you hit your account's rate limits, you may end up losing data or halting processes because of blocked features or functionalities. Those will not run retroactively. Unblocking will only affect future actions.

It is your responsibility to have the correct add-ons, plans or overall usage behavior that fits your operational needs.