Google CAP requirements

Your alerting data should follow the OASIS Common Alerting Protocol v1.2 specification, plus the Google Public Alerts CAP v1.0 specification and additional requirements noted below.

About Google CAP

The CAP standard establishes the basic structure and data elements for a CAP alert, but still leaves considerable room for inconsistencies in how and when the various data elements are employed.

Our platform aims to simplify the process of finding emergency information by bringing together high-quality, relevant data inside online tools that people already use every day. The additional requirements are meant to maximize the reach and effectiveness of your alerts on Google products.

Google-specific differences with the CAP 1.2 XML requirements are summarized in the Google Public Alerts CAP v1.0 specification.

The "Google Public Alerts CAP" option in the open-source CAP Validator allows you to validate your data against both the OASIS spec and Google's additional requirements.

The guidelines below apply to all types of alerts and hazards. We've also put together a few additional requirements and recommendations for these specific alert types in our Samples section:

Perform periodic testing

  • Ensure your system is capable of publishing alerts with <status>Test</status> in order to perform regular end-to-end system tests.

Target alerting areas

  • If there are non-contiguous areas under the same alert level and type, create separate <alert> messages rather than a single <alert> with disjointed areas.
  • If the <area> element contains <polygon> elements, ensure they're valid polygons without intersecting edges, and specify a maximum of 6 decimal points of precision.
  • If the <area> element of your alerts contains geocodes, provide the geodata in shapefile format and notify Google at at least 30 days before any shapefile changes.
  • Draw impact-based polygons that are customized for current conditions and the nature of the event wherever possible, rather than targeting alerts to predefined geopolitical areas (e.g. provinces, districts).
  • Provide Google with a short (less than 50 characters) description of the affected area in the <areaDesc> or in a separate dedicated <parameter> of your CAP alerts. This text will be displayed in the alert title.

Include rich content

  • Include rich, actionable, human-readable content in the <description> and <instruction> elements.
  • Describe the current event, predicted developments, expected impact, and recommendations as applicable.
  • Use correct spelling, grammar, and punctuation.
  • Use plain-text or markdown to improve the readability of your content, rather than HTML tags.
  • Provide RGB or hex color codes corresponding to each alert level (can be provided to Google offline).

Updating alerts

When an alert changes, issue a new alert that refers to the previous alert, instead of changing or removing the existing alert from your feed. After an appropriate amount of time (e.g. 24-48 hours), remove cancelled, updated, or expired alerts from your feed.

<msgType> UPDATE or CANCEL must include at least one <references> element. As specified in the CAP standard, any alert message that updates a previous alert should use <msgType>Update</msgType> and set <references>code</references> to all previous related messages that haven't reached their <expires> date. The UPDATE or CANCEL must apply to a non-expired alert.

There are three ways to CANCEL events, in order of preference:

  1. Set an <expires> datetime for each event, with the message description setting the expectation that this alert will end on its own.
  2. Issue a new <alert> with <msgType>UPDATE, <responseType>"All Clear", and <expires> a short time in the future.
  3. Issue a new <alert> with <msgType>CANCEL.

Please see our Sample Alerts for updates and cancellations for examples.

Supporting multiple languages

Please create one <alert> containing multiple <info> blocks (one <info> block per language).

For more details and a sample multi-lingual alert, see Multiple languages.