API landing page template

Note: Remove this whole explanatory note before publishing

Page front matter:

The frontmatter at the top of the page is used to define "page metadata". The values should be updated appropriately for the particular interface.

---
title: NameOfTheAPI API
slug: Web/API/NameOfTheAPI_API
page-type: web-api-overview
status:
  - experimental
  - deprecated
  - non-standard
---

title: Title heading displayed at top of page. This is the name of the API followed by the text "API": NameOfTheAPI API. For example, WebXR Device has a title of WebXR Device API, Fetch has a title of Fetch API.
slug: The end of the URL path after https://developer.mozilla.org/en-US/docs/). This will be formatted like Web/API/NameOfTheAPI_API. For example, the WebXR Device API's slug is Web/API/WebXR_Device_API.
page-type: The page-type key for Web/API landing pages is always web-api-overview.
status: Include (appropriate) technology status keys: experimental, deprecated, non-standard (if not on a standards track).

Top-of-page macros

A number of macro calls appear at the top of the content section (immediately below the page frontmatter). You should update or delete them according to the advice below:

{{SeeCompatTable}} — this generates a This is an experimental technology banner that indicates the technology is experimental. If the technology you are documenting is not experimental, you should remove this. If it is experimental, and the technology is hidden behind a pref in Firefox, you should also fill in an entry for it in the Experimental features in Firefox page.
{{Deprecated_Header}} — this generates a Deprecated banner that indicates that use of the technology is discouraged. If it isn't, then you can remove the macro call.
{{SecureContext_Header}} — this generates a Secure context banner that indicates the technology is only available in a secure context. If it isn't, then you can remove the macro call. If it is, then you should also fill in an entry for it in the Features restricted to secure contexts page.
{{APIRef("GroupDataName")}} — this generates the left-hand reference sidebar showing quick reference links related to the current page. For example, every page in the WebVR API has the same sidebar, which points to the other pages in the API. To generate the correct sidebar for your API, you need to add a GroupData entry to our GitHub repo, and include the entry's name inside the macro call in place of GroupDataName. See our API reference sidebars guide for information on how to do this.
Remember to remove the {{MDNSidebar}} macro when you copy this page.

Browser compatibility

API landing pages optionally have a browser compatibility section that shows compatibility tables for one or more of the most important interfaces in the API. If the compatibility is similar for most interfaces in the API then often just one compatibility table is needed. If compatibility across the API is complicated/impossible to capture in a few tables, this sections should be omitted.

To fill in the browser compatibility section, you may first need to create/update entries for the API interfaces in our Browser compat data repo — see our guide on how to do this.

Add the {{Compat("path.to.feature.Interface")}} macro for each interface for which compatibility information is required, replacing the "path.to.feature.Interface" argument with the path to the desired interface in the browser compatibility data.

Specifications

API landing pages optionally have a specifications section that lists the relevant specification(s) for each interface. Often there is just one specification covering all interfaces in the API.

To fill in the specifications section, you may first need to create/update entries for interfaces in the Browser compat data repo to include specification data — see our guide on how to do this.

Use the {{specifications("path.to.feature.Interface")}} macro to add tables for the main specifications.

Remember to remove this whole explanatory note before publishing

Secure context: This feature is available only in secure contexts (HTTPS), in some or all supporting browsers.

The summary paragraph — start by naming the API, and saying what it is used for. This should ideally be 1 or 2 short sentences.

Concepts and usage

In this section, describe the API's purpose and usage cases in a bit more detail — why was a need recognized for it? What problems does it solve? What concepts does it involve? How do you use it, from a high level perspective?

Don't go into a lot of detail in this section, and don't include code examples. If there are a lot of concepts to explain around this API, you should explain them in a separate "Fundamentals" or "Concepts" article (e.g. Fundamentals of WebXR). For a practical usage guide with code examples, you should include a "Usage…" article in your API docs (e.g. Using the WebVR API).

To help improve content discoverability and SEO, keep the following tips in mind:

Interfaces

NameOfTheInterface: Include a brief description of the interface and what it does here. Include one term and definition for each interface or dictionary.

Extensions to other interfaces

The name of interface extends the following APIs, adding the listed features.

Interface 1

addition1: Description of the feature of Interface#1 that is added to that API by the API you are currently documenting. One *term and definition for each feature. If this API doesn't extend any other interfaces, you can delete these sections.

Interface 2

addition1: Description of the feature of Interface#2 that is added to that API by the API you are currently documenting, etc.

Examples

Note that we use the plural "Examples" even if the page only contains one example.

A descriptive heading

Each example must have an H3 heading naming the example. The heading should be descriptive of what the example is doing. For example, "A simple example" does not say anything about the example and therefore, not a good heading. The heading should be concise. For a longer description, use the paragraph after the heading.

See our guide on how to add code examples for more information.

Note: Sometimes you will want to link to examples given on another page.

Scenario 1: If you have some examples on this page and some more examples on another page:

Include an H3 heading (###) for each example on this page and then a final H3 heading (###) with the text "More examples", under which you can link to the examples on other pages. For example:

## Examples

### Using the fetch API

Example of Fetch

### More examples

Links to more examples on other pages

Scenario 2: If you only have examples on another page and none on this page:

Don't add any H3 headings; just add the links directly under the H2 heading "Examples". For example:

## Examples

For examples of this API, see [the page on fetch()](https://example.org).

Specifications

No specification found

No specification data found for path.to.feature.Interface_1.
Check for problems with this page or contribute a missing spec_url to mdn/browser-compat-data. Also make sure the specification is included in w3c/browser-specs.

No specification found

No specification data found for path.to.feature.Interface_2.
Check for problems with this page or contribute a missing spec_url to mdn/browser-compat-data. Also make sure the specification is included in w3c/browser-specs.

Browser compatibility

BCD tables only load in the browser