Registering and Publishing Your Action

Register your Action

Before you can submit your draft for approval and publishing, you must provide metadata about your Action and register it in the Actions console. The following sections describe the information that you need to provide.

Directory information

Most of this information will be shown to users in the Actions directory. To add this information go to Deploy > Directory information.

  1. Enter descriptions for your Action, both a short description that describes its function in one line, and a more complete description.
  2. Enter some sample invocations, or some phrases that users can say to invoke your Action. Make sure you've tested your sample invocations in the simulator or on a device, if they don't all work your Actions project will be denied.
  3. Provide banner and logo images for your Action. The image size requirements are 1920 x 1080 pixels for the banner image and 192 x 192 pixels for the logo image.
  4. Enter contact information for your Action. This is displayed publicly and is provided so users can contact you.
  5. Enter links to your Privacy Policy and Terms of Service. These will be publicly available.
  6. Pick the category that is most appropriate for your Action.
  7. If you want your Action to be targeted to kids and families, toggle the For Families option. Note that enabling this option will require you to join the Actions for Families program.
  8. If your Action features any alcohol or tobacco-related content, toggle the Alcohol and Tobacco option.
  9. Optionally enter testing instructions for your Action. These are only visible to the review team and will not be seen by users.

Add details for other languages

You can specify Action information details at the language and locale level for each of your projects.

By default, your browser language will be selected in the language drop-down when you create a new project. You can add additional language support to your project by clicking the gear icon next to Overview and selecting the Languages tab. Click the check box next to each additional language you want to support.

You can configure metadata such as the Action’s name and description for each language in your project. To do this:

  1. In the Overview, click on Deploy > Directory information.
  2. Select a language from the picker in the upper-left corner.
  3. Enter details for your Action in a similar way as described in Directory information, substituting the default language details with the equivalent information in your selected language. You can also bulk export your Action's metadata as resource strings, which can be sent out for translation and imported back later. Read Exporting metadata for translation for details.
  4. Click Save.

Export metadata for translation

If you need to translate your Action's metadata for different locales without granting translators access to the Actions console, you can export your Action project's metadata as resource strings that can be externally translated and imported back into your project. To do this:

  1. In the Overview, click on Deploy > Directory information.
  2. Click on the vertical dots icon to the right of the language selector and Export for translation to download a .zip archive:
  3. The .zip archive contains .xlf files for each locale. Each file includes a <source> and <target> translation for each field in the description for this Action:

    <trans-unit id="tu3" resname="shortDescription">
    <source xml:lang="en">short description</source>
    <target xml:lang="it">short description</target>
    <note>The default short description for the Action (if there is not a translation available). This is limited to 80 characters.</note>
  4. Replace the <target> strings with translated strings for the file's locale:

    <trans-unit id="tu3" resname="shortDescription">
    <source xml:lang="en">short description</source>
    <target xml:lang="it">Breve descrizione</target>
    <note>The default short description for the Action (if there is not a translation available). This is limited to 80 characters.</note>
  5. Re-zip the folder containing all of the now-translated .xlf files.

  6. Navigate back to the Directory information page in the Actions console, click on the vertical dots icon near the top and Import translations to upload your archive.

Location targeting

By default, your Action is available in all regions as long as the user's device locale is set to an "English" variant (for example, EN-US or EN-GB).

The Actions console lets you control region availability with the Location targeting setting, which specifies the regions your Action supports. A device's region is determined by its physical location and not by its locale. Regions are currently set at the country level.

You might want to use location targeting if you have an Action that only allows purchases in certain countries or if your Action relies on the user physically being in a specific country to use it. However, you should make your Action available to as many regions as possible. For instance, if you create an Action that teaches users about United States history, you should make the Action available to all regions to get the most usage and exposure.

To set location targeting:

  1. Go to the Overview section of your project in the Actions console.
  2. In the Deploy > Location targeting section, specify the regions that your Action supports. By default, all regions are supported.

Surface capabilities

Surface capabilities let you control whether or not users can invoke your Action, based on the surface they are using. If users try to invoke your Action on an unsupported surface, they receive an error message telling them their device is unsupported.

Your actions can appear on a variety of surfaces that the Assistant supports, such as phones (Android and iOS) and voice-activated speakers.

Account Linking

Account linking is a great way to lets users connect their Google accounts to existing accounts on your service. This allows you to build richer experiences for your users that take advantage of the data they already have in their account on your service. Whether it’s food preferences, existing payment accounts, music preferences, your users should be able to have better experiences in the Google Assistant by linking their accounts.

Learn more about account linking.


Before publishing your Action, you should use the Actions console's simulator to test the user experience.

To test your current Actions project draft, click on Test > Simulator. This will make the current version of your draft available in the simulator in the console as well as on your own Actions on Google-enabled devices.

To invoke your Actions project draft on the simulator or on your devices, try typing or saying “Talk to ACTION_NAME, where ACTION_NAME is the invocation name of your Action.


Once you've thoroughly tested your Actions project draft and are happy with the results, you can deploy it to users. To do this, navigate to Deploy > Release and click the Submit For Production button.

This will submit the current draft of your Actions project for review. Our review team will test your Action against our policies and if it is approved, it will be available to users.

As updates occur, you'll get emails and you can always track the status by returning to the Overview section of the Actions console.

Deployment states

Learn more about what your deployment status means and how you can update it.

  • Under Review: When you submit a new deployment, it goes through an approval process. Reviewers test your Action and verify that you haven't violated any policies. You will receive an email once a review has been completed telling you whether your deployment was approved or not.

  • Denied: An unapproved status means that your deployment was denied. You should receive an email explaining why your deployment was denied. You can also click Why? next to the Unapproved status in the console to see the rationale for the denial.

  • Published: An approved deployment that is active and being served to users. Note that you can unpublish a published version at any point from the console.

  • Unpublished: An approved deployment that is not currently active and is not being served to users. Note that you can publish an unpublished version at any point from the console without going through review (since it has already been approved).

  • Published and Unpublishing: Publishing and unpublishing takes some time to take effect. These intermediate states reflect that your Action is either transitioning from unpublished to published, or vice versa.

  • Unhealthy: Google will regularly send a request to the endpoint of your MAIN intent, and check that we get an appropriate response. If we detect that your endpoint has gone down or is unresponsive, we will temporarily stop serving your Action to users.

    In this case, you will receive an email informing you that your endpoint is unhealthy, and we will also show an Unhealthy status. As soon as we detect that your endpoint is responsive again, we will resume serving your Action to users. You will receive an email if this happens, and your deployment’s status should return to Published.

  • Taken down: Google may take down your Action if we detect a policy violation after deployment. You will receive an email if this happens, and you will also see a banner in the developer console informing you that your Action has been taken down. You can click Why? to see the rationale, and to see your options for either fixing the policy violation or appealing the decision. Note that some takedowns are final, and cannot be appealed or revoked.

Restrictions and best practices

Because your link URL can now be distributed and referenced outside of the directory or other Google services, please note that the following restrictions and best practices apply:

  • Make sure you continue to support all of your Action links. If you distribute an Action link that later breaks, your Action project may be flagged as unhealthy and taken down.
  • Publishing a link means you support triggering from untrusted sources. For any linked Actions, you must explicitly confirm with the user before taking any "real-world" action. For example, an Action that turns off a Smart Home appliance should prompt the user saying "Are you sure you want to turn off $applianceName?"
    • A real world action is any action affecting the user's services, data, devices, networks, computers, or APIs. For example, sending an email, performing a transaction, altering the status of a SmartHome appliance, creating a subscription, or updating a piece of content.


Over time you'll undoubtedly want to update your Actions project and these changes will result in a new version. Each version goes through the same approval process before your updated Action is released to the public.

Update an Action

If you want to update the contents of your Action, make whatever changes you need and then update your Actions project draft then click Submit For Production on the Overview page. This will create a new project version which goes through the same review process as before. If approved, the previous version will be unpublished and the latest version of your Action will be available to users.

Track and modify versions

You can track and get information about your versions on the Overview page. Click the version in the table you want information about.

The table shows the last modified date and the current status of the version. You can make specific changes to the status, depending on the version's current status.

  • If a version is under review, you can withdraw the version from review.

  • If a version is published, you can unpublish it.

  • When a previous version is unpublished, you can Rollback to this version to revert to that version.

Now that your Action is available to users, continue on to the Analytics and Health section to see how it's performing.