19 Jul 2023 10:41 AM
With reference to https://developer.dynatrace.com/develop/functions/, what does it mean for following items:
Solved! Go to Solution.
19 Jul 2023 03:58 PM
Hi there
Let me know if it answers your question. Thanks 🙂
28 Jun 2025 03:58 PM
Subject: Clarification on Log Ingest via AppFunction with Api-Token
Hi imsingh,
First off, I just wanted to compliment you on the excellent and informative videos you created on Dynatrace University — they’ve been a huge help.
While building my first AppFunction, I ran into a limitation that I hope you might be able to clarify.
I was trying to call the v2/logs/ingest API from within an AppFunction using an Api-Token. This call works perfectly when made externally (e.g. from Python or Postman), but inside the AppFunction I received the following error:
"Unsupported authorization scheme 'Api-Token'. Dynatrace platform APIs require the authorization scheme 'Bearer'."
Here’s the full error payload, in case it helps:
{ "error": { "code": 401, "message": "Unsupported authorization scheme 'Api-Token'. Dynatrace platform APIs require the authorization scheme 'Bearer'.", "details": { "traceId": "c25be4adefbbb1296f15adf13a275196" } } }
I now understand that AppFunctions operate within the Dynatrace Platform context, which requires Bearer authentication — but unfortunately, the v2/logs/ingest endpoint doesn’t currently support Bearer tokens or OAuth clients. This caught me off guard and was admittedly a bit frustrating, as I expected parity between external and platform-internal API usage.
I also explored the Developer Portal and came across @dynatrace-sdk/client-classic-environment-v2, but I wasn’t sure if this is the right approach for ingesting logs from within an AppFunction. I wasn’t able to install the package or find a working example using the logsClient.
Given that my use case is quite simple — just forwarding a small set of JSON events into Dynatrace from within an AppFunction — could you please recommend the best-supported method to do this from inside the platform? A sample the proper SDK or HTTP call would be extremely helpful.
Really appreciate your time and guidance.
Best regards,
MarwanC
01 Jul 2025 09:09 AM
You should use the @dynatrace-sdk/client-classic-environment-v2 sdk from the AppFunction without using an extra tokens. The platform and sdk will take care of authentication.
01 Jul 2025 09:25 AM
Thank you which function is in
01 Jul 2025 09:34 AM
You need to use logsClient to ingest logs into Dynatrace. Here is an example code snippet that you can use for inspiration: https://developer.dynatrace.com/develop/data/ingest-data/
02 Jul 2025 09:40 AM
Thank you for the clarification. I understand that this scenario involves a direct invocation of the Dynatrace API, which allows for native calls without explicitly requiring an API token in the request path.
However, my current use case involves system-to-system communication, where an external system triggers a Dynatrace AppFunction. While I'm able to successfully extract and parse the payload (via JSON.stringify()), I critically require access to the HTTP headers forwarded from the calling system — specifically for purposes such as validation, routing, or custom authorization.
The problem is that, within the AppFunction runtime, I have not found a documented or programmatic method to access the original request headers. My assumption is that this information is available internally, possibly via the execution context or a specific SDK helper, but I have yet to identify the proper pattern or API surface to expose those headers.
For reference, here is the function signature I’m currently working with: export default async function handler(request: AppFunctionRequest): Promise<AppFunctionResponse> {
// logic here
}
The request object does expose the payload/body as expected, but there is no explicit .headers or similar metadata surface that I can access in this context.
Any guidance on how to extract custom headers (e.g., X-Correlation-ID, Authorization, etc.) from the incoming request within the AppFunction environment would be greatly appreciated — especially if there is an SDK-based or officially supported mechanism.
Thanks again for your assistance and kudo to the videos that you publish regularly.
Marwan...
03 Jul 2025 01:53 PM
Hi Marwan, Function invocations are not tied to HTTP calls and can be called via other means as well. This is why there is currently no information on HTTP headers available. Also, currently, calls via HTTP run over the public API Gateway and are stripped of all information that is not relevant to a function invocation. The relevant information is available within the `globalThis.dtRuntime` object. I see that some use cases might benefit from additional information that is stored in headers, and I'll take that back with my Architect colleagues to discuss further.
03 Jul 2025 08:35 PM
Thank you, Stefan — I appreciate your response.
This is a critical discussion point for many Dynatrace users, particularly in enterprise environments where integrations are driven by external systems beyond our control. In such scenarios, it’s impractical to ask customers to modify their outbound payload structure to conform to Dynatrace-specific expectations. They often need to emit data as-is, without reshaping their systems around the receiver’s constraints.
When invoking AppFunctions, this becomes especially problematic. There is currently no straightforward way to extract parameters passed via the URL — such as ?particular=xyz — for contextual routing or logic shaping inside the function. These kinds of query parameters are foundational in many API-driven ecosystems and are widely used to encode dynamic context, versioning, filtering, and feature toggling.
To that end, I would like to understand whether it's possible — or planned — to expose the globalThis.dtRuntime object or a similar execution context API that allows developers to introspect headers, query parameters, or invocation metadata within an AppFunction. This would significantly enhance the flexibility and integrability of the platform for system-to-system automation scenarios.
I intend to raise this idea in the community for discussion and voting. Do you believe DT would support enabling secure access to invocation metadata from within AppFunctions? I’d be keen to hear your thoughts — and those of the product team — on its architectural implications and viability.
03 Jul 2025 08:44 PM
I raised this as an idea to DT Development team, kindly vote for it as well.
03 Jul 2025 08:16 AM
Hi Marwan
Let me understand your challenge.
You have a script that run outsides Dynatrace. This script is executing App function. You're trying to pass authentication headers from your external script to app function right?
If the answers to above question is yes. Then I think you just need to use OAuth Client with your external script as mentioned here https://developer.dynatrace.com/develop/access-platform-apis-from-outside/ You don't need to handle authentication in AppFunction then. Just use the DT SDK for ingesting data.
If that's not what you want. Unfortunately, you can't extract custom headers in App function.
03 Jul 2025 11:57 AM
Thanks once more, now you confirmed that headers can not be passed to an AppFunctions. This is clear now and I will handle the logic inside the AppFunction.
One last question, is there a way to pass an argument(s) to the AppFunction, can data pass only via payload?
I appreciate a quick answer.
03 Jul 2025 12:50 PM
You can only send data to AppFunction via payload. In fact, if your script has access to headers before the request is sent, you can send them via payload.
04 Jul 2025 03:57 PM
Thank you. I hit another limitations today (see error below), would you be kind to tell me the maximum size limit that is allowed allowed by AppFunction?
Parsed JSON Response:
{ "error": { "code": 541, "message": "Execution crashed", "details": { "logs": "", "type": "RESPONSE_TOO_LARGE", "message": "The response of the called function exceeded the size-limit" } } }
08 Jul 2025 10:01 AM
Hi Marwan!
The size limit for responses in a serverless function is roughly 5MB.
Please refer to https://docs.dynatrace.com/docs/shortlink/workflows-action-javascript#run-javascript-action-requirem... and https://developer.dynatrace.com/develop/app-functions/#runtime-limitations for further information on limitations.
09 Jul 2025 10:42 AM
I would like to share this factsheet about AppFunction, hope it helps everyone before deciding on the usage widely within your project.
AppFunction Runtime Limitations
A Technical Fact Sheet for Platform API
Runtime Environment
Language Support |
TypeScript / JavaScript |
Execution Engine | Deno Container |
Memory Allocation | 256 MB per function |
Maximum Execution Time | 120 seconds |
Payload Format | JSON only — for both input and output |
Input Interface | No support for parameters or headers |
Payload Size Limit | 5 MB maximum (combined input/output) |
HTTP Status on Breach | 541 — Error triggered when payload exceeds limit |
Licnse Consumption | There is a cost associated with each call on the license consumption. |
Security & Access Control
Architectural Limitations
Usage Guidance
AppFunction is best suited for lightweight, single-purpose, deterministic logic.
Not recommended for heavy computation, external API integration (without setup), or long-running processes.
Developer Note
This document is intended to inform teams and stakeholders of critical limitations in AppFunction architecture before integration. Please assess functional scope carefully and run stress tests on payload volume when developing new functions.