Skip to main content
Complete Build and deploy an app first. Signing in and calling the app need publish permission on it; setting secrets and reading its calls need build. Get an app lists yours in permissions. The examples continue with app-claims-notes. Values in them are illustrative.

Sign a browser in

Open the app’s url from Get an app. A browser that isn’t signed in is redirected to an /app-authorize URL. Copy it from the address bar and pass it as authorizeUrl:
Open callbackUrl in the same tab within a minute; it doesn’t work in another tab or browser. The app loads signed in as you for ten minutes.

Call the app’s API

To test a backend route without a browser, send one request to it, signed in as you:
status and body are the app’s own response, so a 200 from Effective can carry the app’s 404 or 500. 502 with app_unreachable means the app timed out or couldn’t be reached, and it may have run the request; Effective doesn’t retry, so repeat it only if that’s safe. When the app calls Effective for you, it has no more access than your API key.

Set a secret

An app’s code never holds a secret. Effective adds the value to the app’s outbound HTTPS requests to the hosts you name. This stores weather-key and sends it to api.weather.example in an X-Api-Key header:
The response describes the secret without its value, with "configured": true. The app uses it from its next request; you don’t need to deploy again. To change the value or routes, send the PUT again with both. See Set an app secret for other header formats.

Find failing calls to Effective

When the app’s requests to Effective fail, list them, newest first:
A 403 means the signed-in user, or the API key they signed in with, can’t use that route. The list covers the last hour, and calls can take a minute to appear. See List app API calls to read further back.