API landing page template

Remove before publishing

Title and slug

An API landing page should have a Title of Name of the API + "API". For example, WebVR has a title of WebVR API, Fetch has a title of Fetch API.

The Slug (the last segment at the end of the URL) should be filled in as Name of the API + "_API". For example, WebVR's slug is WebVR API. This is usually filled in for you automatically.

Top macros

There are four macro calls at the top of the template by default. You should update or delete them according to the advice below:

  • {{draft()}} — this generates a Draft banner that indicates that the page is not yet complete, and should only be removed when the first draft of the page is completely finished. After it is ready to be published, you can remove this.
  • {{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 can 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.
  • {{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 BE DONE WRITE GUIDE+++ to our KumaScript GitHub repo, and include the entry's name inside the macro call in place of GroupDataName.

Tags

In an API landing page, you need to include the following tags (see the Tags section at the bottom of the editor UI): API, Reference, Landing, the name of the API (e.g. WebVR), Experimental (if the technology is experimental), Secure context (if it is available in a secure context only).

Optionally, you can elect to include some other tags that effective represent terms people might search for when looking for information on that technology. For example on the WebVR page we include VR and Virtual reality.

Browser compatibility

To fill in the browser compat data, you first need to fill in an entry for the API into our Browser compat data repo — see our guide on how to do this.

Once that is done, you can show the compat data for the API with a {{Compat()}} macro call.

Draft
This page is not complete.

This is an experimental technology
Because this technology's specification has not stabilized, check the compatibility table for usage in various browsers. Also note that the syntax and behavior of an experimental technology is subject to change in future versions of browsers as the specification changes.

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 recognised 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 to explain around this API, you should explain them in a separate "Concepts..." article (e.g. WebVR concepts). For a practical usage guide with code examples, you should include a "Usage..." article in your API docs (e.g. Using the WebVR API).

Name of interface interfaces

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

Name of interface mixins

NameOfTheInterface
Include a brief description of the mixin and what it does here. Include one term and definition for each mixin. If there are no mixins in this API, delete this section.

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

Fill in a simple example that nicely shows a typical usage of the API (feel free to use a live sample if you like):

my code block

And/or include a list of links to useful code samples that live elsewhere:

  • x
  • y
  • z

Specifications

Specification Status Comment
Unknown Unknown Defines blah blah feature. If no other specs define extensions of this API, you can delete this table row.
Unknown Unknown Initial definition.

Browser compatibility

No compatibility data found. Please contribute data for "path.to.feature.NameOfAPI" (depth: 1) to the MDN compatibility data repository.

See also

  • Include list of
  • other links related to
  • this API that might
  • be useful

Document Tags and Contributors

 Contributors to this page: chrisdavidmills
 Last updated by: chrisdavidmills,