Maximum Limits in Enate

Understanding Enate's Data Limits

Enate's system administrators and builders can use the information provided here to understand the data limits for different objects. The intention is to help Enate clients understand the tested and supported data limits of the system. Additionally, warnings may start to be added into the system for end users once they reach the maximum limit for a certain type of data.

See the diagram below for information around specific recommended maximums for the most regularly uses types of data in the Enate system (expand image for more detailed view).

Limit on Custom Data per Work Item

A Ticket, Case or Action can hold up to 2,000 pieces of custom data. This is a hard limit: Enate refuses an update that would take a work item over it.

Enate counts a piece of custom data like this:

What the work item holds	Pieces of custom data
A custom data field that isn't in a table	1 for each field
A Currency field	1, the same as any other field
A custom data table	1 for each cell, so the number of rows multiplied by the number of columns

A custom data field that isn't set to Private, is shared among related work items, so it counts towards every work item that shares it. A Private field counts only towards the work item it belongs to.

A table of 200 rows and 10 columns is 2,000 pieces on its own, so the whole allowance for a work item can be used up by one table.

What the limit does

Behaviour	Detail
What is refused	An update that adds rows to a custom data table and leaves the work item with more than 2,000 pieces of custom data. Nothing in the update is saved
What the caller sees	The validation message PacketCustomData_LimitExceeded (828023): "This work item has more custom data than the limit allows."
What is not refused	Creating a work item, including bulk creation. Updates that don't add table rows. Updates that remove at least as much custom data as they add.
A work item that is already over the limit	Still works. It can be assigned, progressed and edited, and its custom data can be reduced. Only an update that adds more table rows is refused.
Custom data Enate creates when it loads a work item	Not counted against an update. For example, a field added to a process after the work item was created is not counted against a save.

Custom data tables are exported to the data warehouse in full, however many rows they hold, so a work item that is already over the limit still appears in your reports.

A message is returned by the Operational API. See the APIs page for what the response looks like and how each API version handles it:

APIs

Worked example: adding rows to a table

A Case has 8 custom data fields that aren't in a table, and a table called Invoice Lines with 12 columns and 165 rows.

Part of the Case's custom data	Calculation	Pieces
Fields that aren't in a table	8 × 1	8
Invoice Lines table	165 × 12	1,980
Total		1,988

• An update that adds one row to Invoice Lines adds 12 pieces and brings the total to 2,000. That is allowed, because the limit is 2,000.

• An update that adds two rows adds 24 pieces and would bring the total to 2,012. Enate refuses it with 828023 and saves nothing, including any other changes in the same update.

• An update that sends the table back with 150 rows instead of 165 removes 15 rows, which is 180 pieces. The total falls to 1,808 and the update is allowed.

Limits for Integrations

The maximums above describe how much data Enate holds. The limits below describe how much work Enate will accept from an integration, and how hard it tries to deliver a Webhook message to you. They matter when you're integrating with Enate, running bulk operations, or planning a migration.

API request limits

Enate's APIs are rate limited so that one busy integration can't degrade the platform for everyone else using the same Enate instance. The limit applies to your Enate instance and to each caller within it, and is counted on a sliding window, so Enate looks at the requests received in the preceding window rather than resetting a counter on the minute boundary.

Limit	Default
Authenticated requests, per window	1,000
Unauthenticated requests, per window	10,000
Window	Sliding, 60 seconds
Response when the limit is exceeded	HTTP 429 Too Many Requests. Nothing is processed, so the request is safe to send again
Information returned with the rejection	None. There's no Retry-After header and no body describing your usage or when to retry
Changing the limits	Raise a support request if you believe your integration needs a different allowance

These are the default values. Build your integration to handle a 429 rather than to the exact numbers above.

Requests made by Work Manager and Builder on behalf of your users count towards the same authenticated allowance as your integration. If an integration runs against the Enate instance your operational teams work in, plan for both. Calls to the legacy API count towards the unauthenticated allowance instead.

Test work and live work count the same. A request against a process version in Testing state is counted exactly like a live one. Load test integrations against a non production Enate instance rather than against the instance your teams are using.

For guidance on handling a 429 and on pacing bulk work, see the APIs page:

APIs

Webhook delivery attempts

Limit	Value
Delivery attempts per Webhook message, including the first	10
What counts as success	Any 2xx response
After the tenth failed attempt	The message is discarded. It isn't retried and won't reach your endpoint
Notification that a message was discarded	None
Replay of a discarded message	Not available

Enate also delivers Webhook messages with limited concurrency per Enate instance, so a burst of events reaches your endpoint over a short period rather than all at once. Full detail on Webhook delivery, including how to build an endpoint that stays inside these limits, is on the Webhook Delivery and Failure Handling page:

Webhook Delivery and Failure Handling

Worked example: migrating 50,000 Tickets

An implementation team loading 50,000 historic Tickets through the Operational API, using a single Application Credential, is limited by the request allowance rather than by anything about the Tickets themselves. At the default of 1,000 requests a minute and one request per Ticket, that's a minimum of 50 minutes of API calls, before any reads the migration also needs.

Three things follow:

• Schedule the load outside the hours your operational teams are working, so the migration and Work Manager aren't competing for the same allowance.

• Pace the sender rather than letting it run flat out. A run that sends steadily under the limit finishes sooner than one that repeatedly hits 429 and backs off.

• If the Tickets you're loading have Webhook subscriptions matching them, expect the resulting Webhook messages to arrive at your endpoint over a longer period than the load itself took, because they're delivered with limited concurrency.