35+ countries live across 4 regions

For your reviewers

Elsewhere

Get your coverage map

Service Level Agreement (SLA) and Limitations

Version 1.2 – [date]

This addendum (the "SLA") defines the service levels, the support procedures and the technical limitations that apply to the API services provided by Plumma® S.R.L. (the "Supplier"). It forms an integral part of the [exact title of the master agreement] (the "Master Agreement").

Article 1 – Service Availability

1.1. Definition. The API is "available" in a given minute when the production endpoint accepts valid, authenticated requests and answers them without a server-side error (HTTP 5xx). "Monthly Availability" is the percentage of minutes in a calendar month in which the API is available, as measured by the Supplier's monitoring, [describe: e.g. an external check run every minute].

1.2. Target. The Supplier aims for a Monthly Availability of 99.5%, excluding Scheduled Maintenance (Art. 3.1) and the exclusions in Art. 5.

1.3. Upstream dependency. The Client acknowledges that the Supplier aggregates services provided by mobile network operators and other third parties. A response that reports a command as not served, because an operator or aggregator did not answer, does not make the API unavailable. Interruptions or latency caused by mobile network operators, aggregators or Internet routing outside the Supplier's control are excluded from the calculation.

Article 2 – Support

2.1. Support is provided by email at support@plumma.it. The Client should include the X-Correlation-ID of the calls concerned. Incidents are classified and handled as follows:

PriorityDescriptionInitial response
P1 – CriticalThe production API is unavailable for all clients.1 business hour
P2 – HighMajor degradation of the service, or a command failing for all requests.4 business hours
P3 – NormalMinor issues, intermittent errors, or defects with a workaround.Next business day
P4 – LowGeneral questions, documentation, feature requests.2 business days

2.2. "Business hours" are 09:00 to 18:00 Italian time, Monday to Friday, excluding Italian public holidays. Response times are times to a first answer, not to resolution.

Article 3 – Maintenance and Updates

3.1. Scheduled maintenance. Routine maintenance of the infrastructure takes place on Mondays between 03:30 and 05:30 UTC. Updates are normally applied without interrupting the API. A short interruption of the API is possible during this window. For other planned work expected to interrupt the service, the Supplier will endeavour to give at least 48 hours' notice.

3.2. Releases. New versions of the service are deployed progressively, without taking the API offline.

3.3. Emergency maintenance. In case of a critical security threat or a major failure, the Supplier may perform emergency maintenance without notice.

3.4. Upstream maintenance. The Supplier is not responsible for maintenance performed by mobile network operators or other third parties, but will pass on any notice it receives from them when practicable.

Article 4 – Technical Limitations

4.1. Rate limits. Requests are limited per API key and per source address, as published in the Technical Documentation or otherwise agreed in writing. Requests over the limit receive HTTP 429 with a Retry-After header, and are not counted as unavailability.

4.2. Latency. Commands are answered in real time by mobile networks and third parties. The Supplier does not guarantee a specific response time.

4.3. Coverage. The commands available depend on the country and the operator of each number, and may change as operators and aggregators change their offer.

4.4. Data accuracy. The information returned (for example identity match scores or age verification) comes from mobile network operators and other third parties. The Supplier returns it as received and is not liable for inaccurate or outdated information held by those sources.

Article 5 – Exclusions

The service levels do not apply to failures or refusals caused by:

  • The Client: invalid or malformed requests, network problems on the Client's side, expired or compromised API keys.
  • Account status: requests refused because a key is not enabled for the application, a prepaid allowance is used up, or the service was suspended under the Terms of Service.
  • Rate limits: requests refused under Art. 4.1.
  • Test use: demo numbers and the Sandbox page, which are provided "as is" under the Terms of Service.
  • Force majeure: as defined in Art. [9.1] of the Master Agreement.
  • Upstream cessation: if a mobile network operator or aggregator stops providing a service, the Supplier's obligation to provide the corresponding command ends at the same time. The Supplier will inform the Client as soon as practicable.

Article 6 – Remedies

6.1. Service credits. If the Monthly Availability falls below the target in Art. 1.2, the Client's sole and exclusive remedy is a credit against future services equal to [x]% of [the amount invoiced for the month concerned / the commands served in the month concerned], up to a maximum of 10% of that amount.

6.2. Claims. A claim for service credits must be sent in writing within 7 days of the end of the month concerned, with the times of the unavailability and, where possible, the correlation ids of the affected calls.

Read this in the portal, with search and the reference beside it: Usage Limitations