Registering and Publishing Your App

Registering your app

Before you can submit your draft for approval and publishing, you must provide metadata about your app 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 (both the mobile HQ app and the Web Directory). To add this information go to Deploy > Directory information.

  1. Enter descriptions for your app, 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 Actions. Make sure you've tested your sample invocations in the simulator or on a device, if they don't all work your app will be denied.
  3. Provide banner and logo images for your app. 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 app. 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 app.
  7. If you want your app 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 app features any alcohol or tobacco-related content, toggle the Alcohol and Tobacco option.
  9. Optionally enter testing instructions for your app. These are only visible to the review team and will not be seen by users.

Adding app details for other languages

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

By default, your default browser language will be selected in the language drop-down when you create a new project. You can change the list of languages by clicking on the language drop-down in the upper-right corner of the Overview page of your project, then clicking Add language.

You can configure application information such as the app’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 app 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 app's information as resource strings, which can be sent out for translation and imported back later. Read External app information translation for details.
  4. Click Save.

External app information translation

If you need to translate your app's information for different locales without granting translators access to the Actions console, you can export your app's information as resource strings that can be externally translated and imported back into the app. 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 app:

    <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 app (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 app (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 app 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 app 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 app that only allows purchases in certain countries or if your app relies on the user physically being in a specific country to use it. However, you should make your app available to as many regions as possible. For instance, if you create an app that teaches users about United States history, you should make the app 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 app supports. By default, all regions are supported.

Surface capabilities

Surface capabilities let you control whether or not users can invoke your app, based on the surface they are using. If users try to invoke your app 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.


Once you have added your actions and provided your app's details, you can simulate your draft which allows you to test and see what the user experience will be like on devices like Google Home and the Pixel.

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

To invoke your draft on the simulator, or on your devices, try typing or saying “Talk to APP_NAME, where APP_NAME is the name of your app.


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

This will submit the current draft of your app for review. Our review team will test the app 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 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 actions 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 Unnaproved 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 actions are 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 actions 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 actions 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 actions 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 actions have 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.

Linking to your Actions

On a per-Action basis, you can generate a URL that will deep-link directly to the specific Action. Users who click the Action link in a web or mobile browser will be directed to the Assistant on their device, where they'll interact directly with your corresponding Action.

Some examples of useful Action links include:

  • Linking users to voice-guided instructions from a how-to website.
  • Linking users to a customer support experience off of a "get help" page.
  • Linking users to an Action with an opt-in for updates so they can opt-in to your future updates.

To generate a URL for an Action, do the following:

  1. In the Actions Console, navigate to Build > Actions.
  2. Click the Action you want to generate a link for.
  3. Under the Links section, enable Would you like to enable a URL for this Action.
  4. Enter a Link title. This title should include a verb that is descriptive of what the Action will do. For example, if your Action will take the user down a transaction flow to buy tickets to a concert, a useful link title would be "purchase concert tickets".
  5. Click Save.

You can copy the provided URL and reference it wherever you want to direct users to this specific Action.

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
    • 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.


Undoubtedly, over time you'll want to update information or actions in your app and these changes will result in a new version. Each version goes through the same approval process before your app is released to the public.

Updating Actions

If you want to make updates, return to the platform you used, make changes to your actions and then update your draft to Actions on Google again. Once all of your changes are ready, click Submit For Production on the app Overview page and a new version will be created. This new version will go through the same review process and if approved, the previous version will be unpublished, updating your app available to users.

Updating App Information

If you want to edit or change any app information specified in the console, just go to the My App card, make the changes, and click Submit. This will deploy your most recent actions and any new changes you have saved, as a new version.

Tracking and Modifying 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 the current app.

Now that your app is available to users, continue on to the Analytics and Health section to see how its doing.