Thresholds and load estimates

When a producer creates a new version of an e-service, they must indicate two tolerance thresholds for their infrastructure:

This measure is provided for in the AgID Guidelines to protect the producer’s infrastructure and to support proper sizing of their infrastructure in relation to the expected load from consumers.

The threshold and load estimate mechanism is a technical tool to support PDND parties and to ensure the proper functioning of services for all.

There may be administrative and privacy considerations regarding the amount of data extracted, especially if personal data is processed. The correct tool to track this information is not thresholds and load estimates, but rather the declaration made by the consumer in the risk analysis. The risk analysis includes the question: “Indicate whether you know the amount of personal data you will obtain through the use of this E-service.” Any justifications and reasons can be discussed in that context.

A consumer with an active service request for a version of an e-service may continue to declare purposes until reaching one of the two thresholds. Once a threshold is exceeded, new purposes will no longer be automatically approved.

It will be up to the producer to manually activate the purposes after verifying the declared load. If the consumer’s request is excessive, the producer may contact them or provide a date by which they expect to have upgraded their infrastructure to handle the new load. The completion date is indicative and can be changed unilaterally by the producer via the PDND UI or API.

The producer may update their thresholds at any time without creating a new version of the e-service. This change is applied immediately and only affects purposes received from that moment onwards.

Purposes that were Waiting for approval before the update must still be approved manually by the producer.

In this case, Purpose 3 is placed by the platform in Waiting for approval status. It will be up to the producer to manually activate it. Purposes 1 and 2 continue to operate regularly.

This happens because adding up the API calls/day of the three purposes from consumer Party B (1,000 + 1,000 + 1) exceeds the per-consumer threshold set by the producer (2,000). This threshold applies only to this e-service and not to other e-services provided by the same producer.

All subsequent purposes submitted by that consumer for that e-service version must be manually activated by the producer, unless the producer decides to raise the per-consumer threshold.

In this case, Purpose 1 from Party D is placed by the platform in Waiting for approval status. It will be up to the producer to manually activate it. The purposes previously published by Parties B and C continue to operate regularly.

This happens because adding up the API calls/day from three consumers (5,000 + 5,000 + 1) exceeds the total threshold set by the producer (10,000).

All subsequent purposes submitted by any consumer for that e-service version must be manually activated by the producer, unless the producer decides to raise the total threshold.

In this case, Purpose 2 has two states simultaneously:

This arrangement allows the consumer to continue using the purpose with the previous estimate (1,000 API calls/day) while waiting for the producer to approve the new estimate that exceeds one of its thresholds.

In this case, Purpose 1 from Party D remains in Waiting for approval status and will need to be manually approved by the producer.

However, if any party subscribed to the e-service creates new purposes that, when summed, remain below the new availability, those purposes will be set to Active immediately. The new availability is 5,000 API calls/day (originally 10,000, raised to 15,000).

The load management model in place is rather simplified and does not address a very common problem: API call spikes (for example, during so-called “click days”).

The model is designed this way for several reasons, including:

According to the indications in the ModI, both producer and consumer are required to keep a record of all API calls received.

In this way, the producer can over time:

Where possible, it is always recommended to avoid immediate synchronous calls that could cause a load spike on a producer’s infrastructure.

In many cases, it is possible to:

It is possible to do this by saving the minimum information and the priority acquired from the user for a limited time in your own database. Only later should you perform checks by contacting the producers’ e-services and completing the procedure.