If you build a user interface for a script, you can publish the script as aweb app. For example, a script that lets users schedule appointments withmembers of a support team would best be presented as a web app so thatusers can access it directly from their browsers.

Bothstandalone scripts andscripts bound to Google Workspace applicationscan be turned intoweb apps, so long as they meet the requirements below.

Requirements for web apps

A script can be published as a web app if it meets these requirements:

• It contains adoGet(e) ordoPost(e) function.
• The function returns anHTML serviceHtmlOutput object or aContent serviceTextOutput object.

Request parameters

When a user visits an app or a program sends the app an HTTPGET request,Apps Script runs the functiondoGet(e). When a program sends the app an HTTPPOST request, Apps Script runsdoPost(e) instead. In both cases, theeargument represents an event parameter that can contain information about anyrequest parameters. The structure of the event object is shown in the tablebelow:

name=alice&n=1&n=2

{"name": "alice", "n": "1"}

{"name": ["alice"], "n": ["1", "2"]}

332

332

text/csv

Alice,21

postData

For instance, you could pass parameters such asusername andageto a URL as shown below:

https://script.google.com/.../exec?username=jsmith&age=21

Then, you can display the parameters like so:

functiondoGet(e){varparams=JSON.stringify(e);returnContentService.createTextOutput(params).setMimeType(ContentService.MimeType.JSON);}

In the above example,doGet(e) returns the following output:

{  "queryString": "username=jsmith&age=21",  "parameter": {    "username": "jsmith",    "age": "21"  },  "contextPath": "",  "parameters": {    "username": [      "jsmith"    ],    "age": [      "21"    ]  },  "contentLength": -1}

Test a web app deployment

To test your script as a web app, follow the steps below:

1. At the top right of the script project, clickDeploy > Test deployments.
2. Next to "Select type," click Enable deployment typessettings> Web app.
3. Under the web app URL, clickCopy.

4. Paste the URL in your browser and test your web app.

   This URL ends in/dev and can only be accessed by users who have edit accessto the script. This instance of the app always runs the most recently savedcode and is only intended for testing during development.

Permissions

The permissions for a web app differ depending how you choose to executethe app:

• Execute the app as me—In this case, the script always executesas you, the owner of the script, no matter who accesses the web app.
• Execute the app as user accessing the web app—In this case, the scriptruns under the identity of the active user using the web app. This permissionapproach causes the web app to show the email of the script owner when the userauthorizes access.

Embed your web app in Google Sites

In order to embed a web app in Google Sites, it must first bedeployed. You alsoneed theDeployed URL from theDeploy dialog.

To embed a web app into aSitespage, follow these steps:

1. Open the Sites page where you'd like to add the web app.
2. SelectInsert > Embed URL.
3. Paste in the web app URL and then clickADD.

The web app appears in a frame in the page's preview. When you publishthe page, your site viewers may need to authorize the web app before itexecutes normally. Unauthorized web apps present authorization prompts tothe user.

Web Apps and Browser History

It can be desirable to have an Apps Script web app simulate a multi-pageapplication, or one with a dynamic UI controlled via URL parameters.In order to do this well, you can define a state object to represent the app'sUI or page, and push the state into the browser history as theuser navigates your app. You can also listen to history events so that your webapp displays the correct UI when the user navigates back and forth with thebrowser buttons. By querying the URL parameters at load time, you can have yourapp dynamically build its UI based on those parameters, allowing the user tostart the app in a particular state.

Apps Script provides two asynchronous client-side JavaScript APIs to assistwith creating web apps that are linked to the browser history:

• google.script.historyprovides methods to allow dynamic response to browser history changes. Thisincludes: pushing states (simple Objects you can define) onto the browserhistory, replacing the top state in the history stack, and setting a listenercallback function to respond to history changes.

• google.script.url providesthe means to retrieve the current page's URL parameters and URL fragment, ifthey are present.

These history APIs are only available to web apps. They are notsupported for sidebars, dialogs or add-ons. This functionality is alsonot recommended for use inweb apps embedded in a Google Sites.