topic Re: Clarification on AppFunctions limitation in Developer Q&A Forum

Clarification on AppFunctions limitation

william_cher — Wed, 19 Jul 2023 09:41:46 GMT

With reference to https://developer.dynatrace.com/develop/functions/, what does it mean for following items:

Functions are deployed in an environment with 256 MB RAM (Regardless of how many AppFunction created, all will run within 256 MB RAM?)
Functions can't send binary responses (AppFunction can only return JSON ?)

Re: Clarification on AppFunctions limitation

imsingh — Wed, 19 Jul 2023 14:58:06 GMT

Hi there

Each App function runs in its own environment with 256MB RAM. If you have two App functions in your application, both will get 256MB RAM separately.
You can't return binary data like images or videos from a function. You can send text back in either JSON or plain text.

Let me know if it answers your question. Thanks 🙂

Re: Clarification on AppFunctions limitation

MarwanC — Sat, 28 Jun 2025 14:58:38 GMT

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

Re: Clarification on AppFunctions limitation

imsingh — Tue, 01 Jul 2025 08:09:17 GMT

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.

Re: Clarification on AppFunctions limitation

MarwanC — Tue, 01 Jul 2025 08:25:41 GMT

Thank you which function is in

@dynatrace-sdk/client-classic-environment-v2 sdk

I installed it like this. What functions is used in the API calls to extract tokens etc...

-----------------------------------------------------------------

install @dynatrace-sdk/client-classic-environment-v2 sdk

-----------------------------------------------------------------

https://developer.dynatrace.com/develop/sdks/

npm install @dynatrace-sdk/client-classic-environment-v2 sdk

|(node:35476) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification.

(Use `node --trace-warnings ...` to show where the warning was created)

npm warn deprecated node-uuid@1.4.8: Use uuid module instead

npm warn deprecated hawk@1.1.1: This module moved to @hapi/hawk. Please make sure to switch over as this distribution is no longer supported and may contain bugs and critical security issues.

npm warn deprecated request@2.37.0: request has been deprecated, see https://github.com/request/request/issues/3142

npm warn deprecated swig@1.4.1: This package is no longer maintained

npm warn deprecated boom@0.4.2: This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial).

npm warn deprecated cryptiles@0.2.2: This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial).

npm warn deprecated sntp@0.2.4: This module moved to @hapi/sntp. Please make sure to switch over as this distribution is no longer supported and may contain bugs and critical security issues.

npm warn deprecated hoek@0.9.1: This version has been deprecated in accordance with the hapi support policy (hapi.im/support). Please upgrade to the latest version to get the best features, bug fixes, and security patches. If you are unable to upgrade at this time, paid support is available for older versions (hapi.im/commercial).

added 43 packages, and audited 581 packages in 12s

80 packages are looking for funding

run `npm fund` for details

18 vulnerabilities (1 moderate, 13 high, 4 critical)

To address all issues, run:

npm audit fix

Re: Clarification on AppFunctions limitation

imsingh — Tue, 01 Jul 2025 08:34:06 GMT

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/

Re: Clarification on AppFunctions limitation

MarwanC — Wed, 02 Jul 2025 08:40:12 GMT

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...

Re: Clarification on AppFunctions limitation

imsingh — Thu, 03 Jul 2025 07:16:19 GMT

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.

Re: Clarification on AppFunctions limitation

MarwanC — Thu, 03 Jul 2025 10:57:56 GMT

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.

Re: Clarification on AppFunctions limitation

imsingh — Thu, 03 Jul 2025 11:50:18 GMT

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.

Re: Clarification on AppFunctions limitation

stefan_baumgart — Thu, 03 Jul 2025 12:53:53 GMT

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.

Re: Clarification on AppFunctions limitation

MarwanC — Thu, 03 Jul 2025 19:35:30 GMT

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.

Re: Clarification on AppFunctions limitation

MarwanC — Thu, 03 Jul 2025 19:44:55 GMT

I raised this as an idea to DT Development team, kindly vote for it as well.

https://community.dynatrace.com/t5/Product-ideas/Expose-Invocation-Metadata-Query-Parameters-amp-Headers-in/idi-p/280757#M52725

Re: Clarification on AppFunctions limitation

MarwanC — Fri, 04 Jul 2025 14:57:35 GMT

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" } } }

Re: Clarification on AppFunctions limitation

dominik_gruber — Tue, 08 Jul 2025 09:01:20 GMT

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-requirements and https://developer.dynatrace.com/develop/app-functions/#runtime-limitations for further information on limitations.

Re: Clarification on AppFunctions limitation

MarwanC — Wed, 09 Jul 2025 09:42:39 GMT

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

Fully sandboxed execution

Scoped strictly to user context

No external network access unless explicitly configured

Architectural Limitations

❌ No support for binary uploads, file streaming, or multi-format data

❌ Stateless — no persistent storage or session retention

❌ Limited extensibility without advanced setup

⚠️ Runtime crash (541) if payload exceeds 5 MB

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.