Hi coder33, This is a common gotcha: query:execute lives under /platform/... on apps.dynatrace.com, which is a "Platform API," and Platform APIs only accept an OAuth2 Bearer token from an OAuth client — they do not accept a classic API-Token, even though the Api-Token scheme works fine for classic environment APIs like api/v2/logs/ingest.
So the fact that your token works for logs/ingest but not for query:execute is expected, not a bug: those two endpoints are on different API layers with different auth requirements.
To fix it:
- Create an OAuth client (Account Management > Identity & access management > OAuth clients, or in some tenants under Settings).
- Grant it the IAM permissions your query needs, for example storage:buckets:read and storage:logs:read (add others depending on what you are querying, such as storage:events:read or storage:metrics:read).
- Get an access token via the client_credentials grant from the SSO token endpoint.
- Call query:execute with "Authorization: Bearer <access_token>" instead of "Authorization: Api-Token <token>".
There's a similar solved thread here that confirms the exact same pattern for the OpenPipeline API, which is architecturally the same kind of platform endpoint: community.dynatrace.com/t5/Dynatrace-API/Platform-API-authentication-with-access-tokens-support/td-p/264055
One thing worth double-checking on your side: some platform gateways return 404 rather than 401 when the token type/scheme is wrong on that route, so a 404 here doesn't necessarily mean the URL is wrong — it can also mean auth is being rejected before it even reaches the query service. Worth checking the raw response body/headers to see if there's a message like "Unsupported authorization scheme" hiding in there.
Hope that helps!
