Pro App Web Requests

Web requests let a Pro app talk to external services — a courier API, a payment provider, a partner system — without ever holding the credentials or even knowing the address it calls.

You define the request once, in the backend. The running app calls it by name and passes a few parameters. Everything else — the address, the headers, the body, the credentials — stays on the server.

How it works

App  →  "call acme.getOrder with orderId = SO-1042"
              ↓ (backend adds address, headers, credentials)
        https://api.acme.com/v2/orders/SO-1042
              ↓
App  ←  the response

The app cannot change where the call goes. Parameters can only fill in the places you allowed, so a request can never be pointed at a different service.

Enabling web requests

Open the app in the App Builder.
Switch to the Backend tab.
Select Web Requests from the left menu.
Turn on the section.

Web requests require a Pro app. Only users with Design access can define or change them; anyone who can run the app can call an enabled request.

Defining a request

Click Add request and fill in:

Name — how the app refers to it, for example acme.getOrder.
Title and description — what it does, in plain words.
Method — GET, POST, PUT, PATCH or DELETE.
Address — the target address, with placeholders where parameters go, for example https://api.acme.com/v2/orders/{{param.orderId}}.
Parameters — the values the app is allowed to supply: name, type, whether they are required, and an optional default.
Headers and body template — fixed values, with the same placeholders available.
Authentication — see below.
Enabled — turn a request off without deleting it.

Press Test to run the request from the backend and see the response with all credentials redacted.

Authentication

Credentials always come from secrets — you reference the secret by name, never by value.

Option	What it does
None	The service needs no credentials.
Bearer token from a secret	Sends a bearer token taken from a secret.
Basic auth from secrets	Sends a user name and password taken from two secrets.
OAuth2 client credentials	The backend logs in with a client id and secret, gets an access token, and uses it.

With OAuth2 client credentials the backend handles the whole login for you: it fetches the token, keeps it until shortly before it expires, reuses it for every call, and renews it automatically. Tokens are kept separately for each set of credentials, so an instance with its own account never reuses another one's token.

Using it in an app

Just describe what the app should do — the App Builder wires the call in for you:

When the user picks an order, fetch it from Acme and show the delivery status.
Add a button that pushes the selected document to the partner system.
Which web requests can this app call?

The app receives the status code and the response content. If the request is disabled, a parameter is missing, a secret has no value, or the external service fails, the app gets a clear message explaining what went wrong.

Safety limits

Only https addresses; internal and local network addresses are refused.
Redirects to another host are not followed.
Response size and duration are capped, so a slow service cannot block the app.
Sensitive response headers never reach the app.
Per-app and per-user rate limits apply.
Logs record which request ran and which credential scope was used — never the credential itself.