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’surl 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:
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 storesweather-key and sends it to api.weather.example in an
X-Api-Key header:
"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: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.