Catalog request: AppSignal (token is a query parameter, like UptimeRobot)
Hi team,
First of all, I love exe.dev and how you've put it together. It really fits nicely for agents and I'm having a lot of fun with it!
We run our on-call agent on exe.dev (team account fashionunited, VM fu-agent-oncall) and route every credential through integrations, so no token ever sits on a VM. One API breaks that pattern and I'd like to ask for a catalog entry for it.
The API, AppSignal's GraphQL endpoint, https://appsignal.com/graphql, authenticates only with a personal API token passed as a query parameter: ?token=<personal-api-token>. Their docs say "All requests require a personal API token passed as a query parameter" and describe no header form.
Why the generic http-proxy doesn't cover it. It injects headers, and a query string on --target is dropped. I checked with a throwaway integration targeting https://httpbin.org/?token=dummy: requests arrived at httpbin with args: {}. So today the only way to reach AppSignal from a VM is to put the token on the VM, which is what we want to avoid with integrations.
The ask. An appsignal catalog service that injects the personal API token as the token query parameter on requests to appsignal.com, the way uptimerobot already injects its api_key. The catalog entry for UptimeRobot notes the key rides the query params, so the mechanism exists; this is the same shape against one host.
- Target host: https://appsignal.com
- Credential: one personal API token (string)
- Injection: ?token=<credential> appended to every request
- Verify call, if you want one: POST /graphql with body {"query":"{ viewer { id } }"}; a bad token returns 401, a good one 200 with data.viewer.id
- Response bodies never echo the token, so nothing needs redacting
Alternatively, if http-proxy gained a --query name=value option next to --header, that would cover this and any other query-param API without a catalog entry.
Happy to test a beta on our VM.
First of all, I love exe.dev and how you've put it together. It really fits nicely for agents and I'm having a lot of fun with it!
We run our on-call agent on exe.dev (team account fashionunited, VM fu-agent-oncall) and route every credential through integrations, so no token ever sits on a VM. One API breaks that pattern and I'd like to ask for a catalog entry for it.
The API, AppSignal's GraphQL endpoint, https://appsignal.com/graphql, authenticates only with a personal API token passed as a query parameter: ?token=<personal-api-token>. Their docs say "All requests require a personal API token passed as a query parameter" and describe no header form.
Why the generic http-proxy doesn't cover it. It injects headers, and a query string on --target is dropped. I checked with a throwaway integration targeting https://httpbin.org/?token=dummy: requests arrived at httpbin with args: {}. So today the only way to reach AppSignal from a VM is to put the token on the VM, which is what we want to avoid with integrations.
The ask. An appsignal catalog service that injects the personal API token as the token query parameter on requests to appsignal.com, the way uptimerobot already injects its api_key. The catalog entry for UptimeRobot notes the key rides the query params, so the mechanism exists; this is the same shape against one host.
- Target host: https://appsignal.com
- Credential: one personal API token (string)
- Injection: ?token=<credential> appended to every request
- Verify call, if you want one: POST /graphql with body {"query":"{ viewer { id } }"}; a bad token returns 401, a good one 200 with data.viewer.id
- Response bodies never echo the token, so nothing needs redacting
Alternatively, if http-proxy gained a --query name=value option next to --header, that would cover this and any other query-param API without a catalog entry.
Happy to test a beta on our VM.
1 Comment