# The API Vendor Commitment Reference: SLA, Deprecation, Support Terms

*Read any API vendor's SLA, deprecation policy, and support terms, convert each promise into real minutes of downtime or months of notice, and name how it misleads.*

- Canonical URL: https://www.refolk.ai/guides/api-vendor-sla-deprecation-reference
- Pillar: Engineering and open source
- Format: Reference
- Published: 2026-10-17
- Last reviewed: 2026-10-17
- Reading time: 21 min
- Keywords: how to read an API vendor SLA, SLA exclusions and service credits explained, API deprecation policy notice period, what does 99.9% uptime actually mean, evaluate third-party API before integrating, Sunset header deprecation header meaning

## Key takeaways

- A 99.9% uptime SLA allows 43.2 minutes of downtime in a 30-day month, and if a 4-hour monthly maintenance window is excluded it is effectively 99.34%.
- A 99.99% SLA with a 4-hour monthly maintenance exclusion is effectively 99.43%, which is worse than an honest 99.5% with no exclusion.
- AWS EC2's first credit band pays 10% for anything from 4.32 minutes to 7.2 hours of monthly downtime, about a 100x spread of outage length for the same credit.
- Service credits are lost unless someone files for them: Google Maps Platform requires notice within 30 days, AWS requires claims by the end of the second billing cycle, and AWS issues no credit of one dollar or less.
- A published deprecation window is only as long as its escape clause: Google Maps waives its 12-month notice if continuing could create a security risk or substantial economic or technical burden.
- The Sunset header from RFC 8594 is a resource hint, not a guarantee, and neither it nor the Deprecation header from RFC 9745 sets any minimum notice period.

This is the lookup to keep open while you read a third-party API vendor's SLA, deprecation policy, and support terms before the API goes on your production path. It is for engineering managers, technical founders, developer-relations leads, and the technical sourcers who staff vendor-risk work. For each written term it says what the term binds the vendor to, how to turn it into real allowed downtime or real migration notice, and exactly how it misleads.

## Which written terms actually bind an API vendor?

Only the contract layers bind the vendor: the master agreement, the SLA, the deprecation or versioning policy, and the support guide for the plan you buy. Changelog posts, marketing pages, and runtime headers tell you things, but they create no obligation you can enforce.

#### Where a vendor's commitments live

1. **Master agreement** - Termination for convenience, change-of-terms notice, liability limits
2. **SLA** - Uptime target, measurement window, exclusions, scope, credits, sole remedy
3. **Deprecation and versioning policy** - Notice window, prior-version support, escape clauses
4. **Support guide** - Severity targets per plan, hours, first response versus resolution
5. **Runtime signals** - Deprecation and Sunset headers, changelog posts; informative, not binding

*An outer layer can cancel an inner one, so a strong SLA inside a weak master agreement is only as strong as the agreement.*

The order matters. Google Maps Platform's terms promise 12 months' notice before a deprecation, but the same terms say "Google may terminate the Agreement for its convenience at any time without liability". Those terms also let a materially adverse SLA change take effect 90 days after notice, and other material changes 30 days after notice. So before you read any number, read the agreement around it.

### The SLA terms, one row each

An **SLA** (service level agreement) is the document that sets an availability target and what you get if the vendor misses it. These are the terms that decide what the headline number is worth.

| Term | What it binds | How it misleads |
|---|---|---|
| Uptime target | Share of the window the service must be up | Says nothing about exclusions or scope |
| Measurement window | Period downtime is summed over | Monthly and yearly budgets differ by 12x |
| Downtime definition | What counts as unavailable | Partial failures may not count |
| Exclusions | Time that never counts, e.g. maintenance | 4 h/month turns 99.99 into 99.43 |
| Covered Service | Which service and deployment is covered | AWS 99.99 needs multi-AZ; one instance gets 99.5 |
| Preview carve-out | Which launch stages are covered at all | Google Preview: "no SLAs or technical support commitments" |

The **Covered Service** (some vendors say Included Service) is the defined list of services and deployment shapes the SLA applies to. On AWS, the 99.99 target applies only "with all running instances deployed concurrently across two or more AZs" (Availability Zones, AWS's separate data-center groupings within a region). A single instance is covered only at 99.5. If you run one instance and quote 99.99 in your design review, you have read the wrong row.

How often SLAs scope their target to a UI or a platform-wide aggregate rather than to the endpoints you call is not established publicly. Check it yourself in the Covered Service definition every time.

## What does 99.9% uptime actually mean in allowed downtime?

99.9% uptime allows 43.2 minutes of downtime in a 30-day month and 8.76 hours in a 365-day year. If a 4-hour monthly maintenance window is excluded from the count, the same SLA is effectively 99.34%.

The arithmetic is simple enough to do in a design review:

- Allowed minutes per month = (100 minus target) / 100 x 43,200.
- Effective availability = 100 x (1 minus (allowed minutes + excluded minutes) / 43,200).

A 30-day month has 43,200 minutes and a 365-day year has 525,600. Every figure below is my own arithmetic on those two bases.

| Target | Per month | Per year | Effective, 4 h/month excluded |
|---|---|---|---|
| 99.5 | 216 min | 43.8 h | 98.94 |
| 99.9 | 43.2 min | 8.76 h | 99.34 |
| 99.95 | 21.6 min | 4.38 h | 99.39 |
| 99.99 | 4.32 min | 52.6 min | 99.43 |

Look at the last column. A fixed 240-minute exclusion is far bigger than the downtime budget at either 99.9 (43.2 minutes) or 99.99 (4.32 minutes), so once it is subtracted the two tiers end up 0.09 points apart. The extra nine you may be paying for mostly disappears into the maintenance window.

**99.43% - Effective availability of a 99.99% SLA that excludes 4 hours of maintenance a month**

That is worse than an honest 99.5% SLA with no exclusion, which allows 216 minutes a month.

If the maintenance exclusion has no cap at all, the effective figure has no floor: the vendor can schedule as much downtime as it likes and still meet the SLA. I found no published benchmark on how often SLAs contain a maintenance exclusion, so treat its presence as unknown until you have searched the document for "scheduled", "maintenance", and "exclusion".

> **Rule:** Compare SLAs in minutes, after exclusions
>
> Never compare two vendors by their nines. Convert each headline target to allowed minutes per month, add every excluded minute, and compare the effective figures.

## How do service credits, caps, claim windows, and sole-remedy clauses work?

A service credit is a percentage discount on future bills that the vendor pays only if you claim it on time. It is usually capped, and it is often your only remedy. Treat it as a pricing adjustment, not as insurance against what an outage costs you.

The terms, defined:

- **Credit tier**: a band of measured availability mapped to a percentage of the monthly bill.
- **Cap**: the maximum credit, as a share of the amount due.
- **Claim window**: the deadline for filing; miss it and the credit is gone.
- **Minimum payout**: a threshold below which no credit is issued.
- **Sole-remedy clause**: a clause stating the credit is your only remedy for the SLA breach.

| Term | AWS EC2 | Google Maps Platform |
|---|---|---|
| Credit tiers | 10% below 99.99 to 99.0; 30% to 95.0; 100% below 95.0 | Not checked here |
| Cap | Top tier is 100% | 50% of the amount due |
| Claim window | End of 2nd billing cycle after the incident | Notify technical support within 30 days |
| Minimum payout | Issued only if over one dollar | Not checked here |
| Form of credit | No refund; future EC2 payments only | Not checked here |
| Sole remedy | "Sole and exclusive remedy" (historical SLA) | Not checked here |

The tier structure hides more than it shows. On a 30-day month, AWS's 10% band runs from 4.32 minutes of downtime up to 7.2 hours. A 5-minute blip and a 7-hour outage pay exactly the same credit, a spread of about 100x in outage length. When you read any vendor's tiers, convert the width of the first band into minutes. That band is where most real incidents land.

There is one automatic exception worth knowing. Under AWS's instance-hour rule, a single EC2 instance that is unavailable for more than six minutes in a clock hour is not charged for that hour, and "you do not need to request credit". Everything else in both schedules above has to be claimed.

#### The path from outage to credit

1. **Outage** - Your monitoring, not the vendor's status page, records start and end times
2. **Evidence** - Logs, timestamps, and resource IDs gathered for the affected Covered Service
3. **Claim** - Filed inside the window: 30 days for Google Maps, end of the 2nd billing cycle for AWS
4. **Calculation** - Vendor applies its tier, cap, and minimum payout
5. **Credit** - Applied to future bills; on AWS, never refunded as cash

*Every stage between the outage and the credit is the customer's job, and missing any one of them means no credit.*

> **Watch out:** Credits are forfeited by default
>
> The usual outcome of an SLA breach is no credit at all, because nobody owned filing the claim before the window closed. Name an owner and put the deadline in a calendar the day the incident ends.

A survey of typical credit percentages across vendors is not established publicly, so do not benchmark one vendor's tiers against an "industry norm". Read each schedule on its own terms.

## How long is an API deprecation policy notice period, really?

The published notice window is what the vendor offers when nothing goes wrong. The escape clause sets the real floor, so read the list of exceptions before you read the number.

Terms used in this section:

- **Deprecation**: the vendor announces that a version or endpoint should no longer be used, though it still works.
- **Sunset** or **end of life (EOL)**: the point after which it may stop working.
- **Prior-version support period**: how long an older version keeps working after a newer one ships.
- **Escape clause**: the stated conditions under which the vendor may skip or shorten the notice.
- **Unversioned request**: a call that does not name an API version and so gets whatever the vendor's default is.

| Provider | Window | Escape clause |
|---|---|---|
| GitHub REST | At least 24 months | Security, availability, or reliability |
| Google Maps | At least 12 months' notice | Legal, security, "burden" |
| Twilio SDKs | 12 months support, then 12 to EOL | After EOL, systems may change without notice |
| Kubernetes beta | At least 9 months or 3 releases after deprecation | None stated |
| Kubernetes alpha | 0 | Removable without notice |

### What each row means in practice

- **GitHub REST.** GitHub uses calendar-dated API versions, supports the previous version for at least 24 months, and publishes each version's end-of-support date in its API versions documentation. It also reserves the right, "in rare cases, [to] introduce a breaking change to an existing version". After a version's window ends, unversioned requests "default to the next oldest supported version". That shift arrives with no warning in your code. Pin a version on every request.
- **Google Maps.** The 12 months of notice is waived if continuing "could create a security risk or substantial economic or technical burden". "Burden" is the vendor's own judgment. And the agreement still allows termination for convenience without liability.
- **Twilio.** Sync SDKs get 12 months of support, then deprecation, and "12 months after being deprecated, the version transitions to EOL". For whole products, Twilio's end-of-life notice for Notify gave 364 days between end of sale and end of life.
- **Kubernetes.** Beta APIs get at least 9 months or 3 releases after deprecation. "Alpha API versions may be removed in any release without prior deprecation notice." GA (generally available) versions cannot be removed within a major version. To find deprecated API versions already in a cluster, there are scanners such as kubent.

### The beta and preview carve-out

A **beta carve-out** is any clause that excludes pre-release stages from the SLA or the deprecation policy. Google gives Preview offerings "no SLAs or technical support commitments", and Kubernetes alpha has no notice at all. If the endpoint you depend on is labelled preview, beta, or alpha, the numbers in the table above do not apply to it. Check the vendor's launch-stage page, not just the endpoint docs.

### Where the sources disagree on the clock

RFC 8594 treats deprecation and sunset as two separate stages. Vendor policies such as Twilio's and Google's run a single clock that starts when the deprecation is announced. When you calculate real migration notice, measure from the announcement to the sunset date. Do not assume a deprecation period followed by a separate sunset period.

#### Notice length against escape-clause breadth

Horizontal axis runs from Short published window to Long published window. Vertical axis runs from Broad escape clause to Narrow escape clause.

| Quadrant | What it means |
| --- | --- |
| Short and narrow | Budget the migration on the vendor's schedule; it will likely hold |
| Long and narrow | Rely on the window, pin versions, and log headers |
| Short and broad | Put the API behind your own interface, or avoid it on the production path |
| Long and broad | Plan to the escape clause, not the headline; keep a fallback ready |

*A long published window with a broad escape clause should be planned as if the notice were short.*

A published policy tells you the rule. It does not tell you what is coming next quarter. The person who can tell you that is usually on the vendor's developer-relations team, and they are hard to find by title alone. [Refolk](/) returns them by plain-English query across LinkedIn, GitHub, and the open web, so you can ask a named person about a version's future before you build on it.

I ran this search: `Developer advocates in the US at API companies like Stripe, Telnyx or AssemblyAI` - [see the full result list](https://www.refolk.ai/s/emd2q6dqpy).

*Returns named developer advocates and DevRel staff at those API vendors, with their current role and public profiles, so you know whom to ask about upcoming deprecations.*

## What do the Deprecation and Sunset HTTP headers mean?

The Deprecation header (RFC 9745) says a resource is deprecated without changing how it behaves. The Sunset header (RFC 8594) gives a timestamp after which the resource may become unavailable. Both are signals, not commitments: neither RFC sets any minimum notice period.

- **Deprecation header.** RFC 9745, by Dalal and Wilde, is on the Standards Track. Its value "MUST be a Date as per Section 3.3.7 of RFC9651", and the RFC states that "deprecation does not change any behavior of the resource". What it proves is that the vendor has marked the resource as deprecated. Where it misleads: it says nothing about when the resource will go away or what the contract allows.
- **Sunset header.** RFC 8594 is Informational, not Standards Track. It says the field "SHOULD be treated as a resource hint". What it proves is that the vendor has stated an intended date. Where it misleads: a hint is not a promise, and a timestamp already in the past means the resource "may become unavailable at any time".
- **Ordering.** A secondary deprecation guide states that the Sunset timestamp must not be earlier than the Deprecation date.

> **Note:** Verify the ordering rule yourself
>
> The exact normative wording on Sunset-versus-Deprecation ordering comes from a secondary source and is not verified here. Read the section on Sunset in RFC 9745 before you build alerting that depends on it.

> A deprecation header is a hint. The notice you can rely on is the one written in the contract.

The practical value of both headers is detection, not protection. A vendor that sends them lets you see a deprecation at runtime even if nobody read the changelog. To get that benefit you have to log them.

**Runtime header logging rule**

```
For every response from a third-party API:
  If the response carries a Deprecation or Sunset header:
    Record: vendor, endpoint, pinned version (yes/no), Deprecation value, Sunset value, first_seen, last_seen
    If this endpoint and header value pair is new: open a ticket for the owning team
    If the Sunset timestamp is in the past: page the owner (the resource may become unavailable at any time)
    If the Sunset timestamp is earlier than the Deprecation date: flag as malformed and confirm with the vendor
  If the request was unversioned: open a ticket to pin a version
```

*Map the field names onto your own logging pipeline and keep one record per endpoint and header value.*

## How should support severity response times be read?

Read the target for the plan you will actually buy, and check three things: whether a P1 target exists at all, whether it measures first response or resolution, and which hours it runs. A **severity level** (P1 to P4) is the vendor's priority class for a support case, with P1 usually reserved for production down.

| Plan | P1 target | The catch |
|---|---|---|
| Google Cloud Standard | N/A | No P1 commitment at all |
| Google Cloud Enhanced | First meaningful response within 1 hour | A response, not a fix |
| Google Cloud Premium | Within 15 minutes | 12-month minimum subscription |
| Apigee Standard | N/A (P2 4 h; P3 and P4 24 h) | Business hours only |

Two things mislead here. First, the marketing page usually shows the best tier, while your contract will name a specific one. On Google Cloud Standard and Apigee Standard, a production outage has no committed response time. Second, "first meaningful response" is a commitment to reply, not to restore service. When you compare support plans, write down the target in minutes, the hours it applies, and the minimum subscription term next to the price.

## How to read an API vendor SLA before integrating: the procedure

Work through the documents in this order, and do not move on until each stage's "done" condition is met. The durations in the step notes are practitioner estimates, not measured timings. Expect about half a day in total for one vendor.

#### Reading one vendor's commitments

1. **Collect the documents** - Gather the SLA, master terms, deprecation policy, support guide, launch-stage page, and any archived SLA versions (AWS and Google both publish historical pages). About 1 hour; done when everything that could bind or excuse the vendor is in one place.
2. **Fix the scope** - Find the Covered Service that contains the endpoints you actually call and any deployment conditions such as AWS multi-AZ. About 30 minutes; done when you can name the exact target that applies to you.
3. **Do the downtime arithmetic** - Convert the headline target to minutes per month and year, subtract nothing and add every excluded minute. About 30 minutes; done when the SLA is recorded in minutes.
4. **Map the remedy** - Record credit tiers, cap, claim deadline, evidence required, minimum payout, refundability, and any sole-remedy clause. About 30 minutes; done when you know who files and what a short and a long outage would each pay.
5. **Read the deprecation terms** - Record the notice window, every escape clause, the fate of unversioned requests, and whether the vendor sends Deprecation and Sunset headers. About 1 hour; done when you have a worst-case notice figure.
6. **Read the support terms** - Find the P1 target for the plan you will buy, its hours, and whether it measures first response or resolution. About 30 minutes; done when you know whether P1 is committed at all.
7. **Check change-of-terms clauses** - Find the notice the vendor must give before changing the SLA or the agreement, and any termination-for-convenience right. About 15 minutes; done when you know how fast the numbers can move.
8. **Register and monitor** - Enter every term into a register with an owner, set calendar alerts for claim windows, and log Deprecation and Sunset headers at runtime. Ongoing; done when a missed claim or unseen deprecation would raise an alert.

## How vendor commitments mislead: the failure modes

Every failure below comes from reading a vendor term at face value. Each one names what you see, what is actually true, and the check that catches it.

1. **The headline uptime.** You see 99.99%. With a 4-hour monthly maintenance exclusion it is effectively 99.43%, worse than an honest 99.5% with no exclusion. **Check:** search the SLA for "scheduled", "maintenance", and "exclusion", then redo the arithmetic.
2. **The wrong scope.** You see 99.99% on AWS. It applies only to multi-AZ deployments, and a single instance is covered at 99.5. **Check:** read the Covered Service or Included Service definition against your actual deployment.
3. **Credit tiers that ignore severity.** You see a tiered credit schedule. On AWS a 5-minute outage and a 7-hour outage both pay 10%. **Check:** convert the width of the first credit band into minutes.
4. **The claim window nobody owns.** You see credits in the SLA. Google's 30-day window and AWS's end-of-second-billing-cycle deadline mean credits are forfeited if nobody files, and AWS pays nothing of one dollar or less. **Check:** confirm a named person owns claim filing and has the evidence they need.
5. **The waivable deprecation window.** You see "12 months' notice". Google can waive it for "burden", and GitHub reserves breaking changes for security, availability, or reliability. **Check:** read the exceptions clause, not just the number, and plan to the matrix quadrant it puts you in.
6. **The Sunset header taken as a promise.** You see a Sunset date months away. RFC 8594 makes it a hint, and a past date means the resource could go at any time. **Check:** confirm you log the header at runtime and that the contract, not the header, sets your notice.
7. **Unversioned calls.** You see your integration working fine. On GitHub, when a version reaches end of support, unversioned requests shift to the next oldest version without warning. **Check:** confirm every request pins a version.
8. **The support tier you will not buy.** You see a 15-minute P1 target on a marketing page. On Google Cloud Standard there is no P1 target at all. **Check:** read the support terms for the plan on your order form.

Two structural risks sit behind all eight. The vendor can usually change the terms (90 days' notice for materially adverse SLA changes under the Maps terms, 30 days for other material changes), and some agreements allow termination for convenience without liability. A perfect SLA reading is a snapshot. It is only valid until the next change notice.

## Who owns the register, and how do you keep it current?

Keep every vendor's terms in one register with one named owner, re-read it whenever a change notice arrives, and keep claim deadlines and header alerts running between reviews. A register without an owner fails the same way unclaimed credits do.

Re-checking is mechanical: compare the vendor's current SLA against its archived versions (AWS and Google publish historical pages), and diff the deprecation policy and support guide against the copies you stored at step 1. Any time-sensitive figure, such as a specific version's end-of-support date, should be re-read from the vendor's page at each review, not copied forward.

**Vendor commitment register row**

```
Vendor / Covered Service:
Documents and retrieval dates:
Headline target -> allowed min/month -> effective % after exclusions:
Exclusions (type, cap in minutes):
Deployment conditions for the target:
Credit tiers / first-band width in minutes / cap:
Claim window / evidence required / minimum payout / refundable (Y/N):
Sole-remedy clause (Y/N, quoted):
Deprecation window / escape clauses (quoted) / worst-case notice:
Pre-release stage of endpoints used (GA / beta / preview / alpha):
Unversioned requests behaviour / all requests pinned (Y/N):
Deprecation and Sunset headers sent (Y/N) / logged (Y/N):
Support plan / P1 target / first response or resolution / hours:
Change-of-terms notice / termination for convenience (Y/N):
Owner / next review date / claim-deadline calendar link:
```

*One row per vendor and Covered Service; fill every field in minutes or dates, never in nines.*

The people who usually own this work are site reliability engineers, and the people who usually announce deprecations on the vendor side are developer-relations staff. In Refolk's index of professional profiles, the two groups are far from equal in size.

| Segment | Count in Refolk's index | Derived |
|---|---|---|
| SRE, US | 6,628 | 4.56x the UK |
| SRE, UK | 1,454 | Baseline |
| DevRel, US | 296 | 22.4 SREs per DevRel profile |

**22.4 - US site reliability engineers per Developer Advocate or Developer Relations profile in Refolk's index**

The DevRel count is 296 and includes some title noise, but the scarcity is consistent with how often deprecation notices go unseen.

Company mentions in these segments come from samples of 25. Apple was the most common employer in the UK SRE sample (5 of 25), and the US DevRel sample included Stripe, Telnyx, and AssemblyAI. If the register has no owner because you have no SRE to give it to, Refolk can return SREs by city and employer in one plain-English query, which is a faster start than building a boolean string.

#### Before the API goes on the production path

- [ ] The Covered Service definition includes the endpoints you call and matches your deployment shape.
- [ ] The SLA is recorded as allowed minutes per month, with every excluded minute added back.
- [ ] The width of the first credit band is written down in minutes.
- [ ] A named person owns claim filing, and the claim deadline is in a calendar.
- [ ] The sole-remedy and no-refund clauses are quoted in the register.
- [ ] The worst-case deprecation notice is recorded from the escape clause, not the headline window.
- [ ] No endpoint on the production path is labelled preview, beta, or alpha, or the carve-out is accepted in writing.
- [ ] Every request pins an API version.
- [ ] Deprecation and Sunset headers are logged at runtime and alert on first sight.
- [ ] The P1 target is taken from the plan on the order form, including its hours and whether it measures first response or resolution.
- [ ] The change-of-terms notice period and any termination-for-convenience right are recorded with a review date.

## Frequently asked questions

### What does 99.9% uptime actually mean in minutes?

99.9% uptime allows 43.2 minutes of downtime in a 30-day month and 8.76 hours in a 365-day year. That number only holds if nothing is excluded. If the SLA excludes a 4-hour monthly maintenance window, the effective figure drops to about 99.34%. Always convert the headline to minutes and then add every excluded minute before comparing vendors.

### Are SLA service credits paid automatically?

Usually not. Google Maps Platform requires the customer to notify technical support within 30 days, and AWS requires claims by the end of the second billing cycle after the incident. AWS also issues no credit of one dollar or less. The one automatic exception found here is AWS's instance-hour rule, where an EC2 instance unavailable for more than six minutes in a clock hour is not charged and no request is needed.

### What is the difference between the Deprecation and Sunset headers?

The Deprecation header, defined in RFC 9745, says a resource is deprecated, and the RFC states that deprecation does not change the resource's behavior. The Sunset header, defined in RFC 8594, gives a timestamp after which the resource may become unavailable, and is treated as a hint. Neither sets a minimum notice period, so the contract, not the header, determines how much warning you can rely on.

### How much notice do API vendors give before breaking changes?

It varies by vendor and is always qualified. GitHub supports a prior REST version for at least 24 months, Google Maps promises at least 12 months, Twilio gives SDKs 12 months of support plus 12 months to end of life, and Kubernetes beta APIs get at least 9 months or 3 releases. Kubernetes alpha APIs can be removed without notice. Read every escape clause before trusting the number.

### What is a sole-remedy clause in an SLA?

A sole-remedy clause says the service credit is your only remedy for missing the SLA. AWS's historical EC2 SLA calls the credit the customer's sole and exclusive remedy, and its current terms say credits do not entitle you to any refund and apply only to future payments. In practice, the SLA becomes a small pricing adjustment, not compensation for what the outage cost your business.

### Does a premium support plan guarantee a fix within the response time?

No. Support targets usually measure the vendor's first response, not resolution. Google's Enhanced support promises a first meaningful response within 1 hour for P1, and Premium within 15 minutes, with a 12-month minimum subscription. On Google Cloud Standard and Apigee Standard there is no P1 target at all. Check which plan you will actually buy and what hours it covers.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/api-vendor-sla-deprecation-reference*