Forge no-egress web triggers EAP is now open to participation!

Hey everyone!

Niel here, Associate Product Management Intern at Atlassian.

Per the recent announcement, web triggers will now make apps ineligible for Runs on Atlassian.

We’ve been working hard on a new no-egress web trigger and would love your feedback.

The Forge no-egress web trigger EAP is open and accepting participants!

This new no-egress solution will provide partners with a way to use web triggers while still meeting Runs on Atlassian eligibility requirements.

Developers will be able to configure no-egress web triggers that handle incoming requests and respond with status codes and set static responses.

At this stage, we believe that this will support:

  • Callers that require indicating success or failure generically (e.g., “200” for success, “500” for failure)
  • Callers that require a static error or success message based on the response

If you are interested, we encourage you to sign up for this EAP.

How do you participate?

What happens after you sign up:

  • You’ll be notified once the feature has been enabled so you can start testing on the App ID you submitted in the participation form.
  • You’ll be invited to a slack channel where you will be able to talk to the team about feedback, challenges, and more.

We are looking forward to receiving your feedback so we can deliver a more powerful solution for you!

*Please note, that these features will only be accessible by those participating in the EAP. However we will also be posting relevant updates to ensure everyone is informed.

Thank you!

Niel

4 Likes

Hi @Niel-Reitmann and @MaxLee,

Thanks for adding this!

We tried the no-egress webtriggers as proposed in the docs. Adding the security.egress. allowDataEgress flag worked and removed the egress warning we earlier had with the eligibility command.

I had some trouble to send the correct response to get this example to work

egress:
  allowDataEgress: false
  allowedResponses:
    - statusCode: 200
      body: '{"body": "Allowed static response"}'

Neither {statusCode: 200, body: JSON.stringify("Allowed static response")}
nor {statusCode: 200, body: JSON.stringify({body: "Allowed static response"})}
worked.

It would be nice to have the body property in allowedResponses being a list of strings, so I can send more than one static message for the same HTTP status.

We’ll keep you updated if we have further feedback!

Cheers,
paul

Hi @ppasler,

Thanks for reaching out!

When using static responses, the body and status code must be exact matches, and in using JSON.stringify("Allowed static response") and JSON.stringify({body: "Allowed static response"}), we get '"Allowed static response"' and '{"body":"Allowed static response"}' respectively. Here, the static response is defined as '{"body": "Allowed static response"} inside the manifest, with an extra whitespace after the colon, and therefore your current implementation won’t work since static responses use string literal comparisons for bodies.

It is also possible to to define multiple static responses for the same status code because of allowedResponses being a list of status code and body pairs. An example of this would look like

modules:
  webtrigger:
    - key: no-egress-web-trigger
      function: no-egress-function
      security:
        egress:
          allowDataEgress: false
          allowedResponses:
            - statusCode: 200
              body: '{"body": "Allowed static response"}'
            - statusCode: 200
              body: '{"body": "Another allowed static response"}'

Please let me know if you had any further questions and I hope this was helpful!

Cheers,
Max

2 Likes

Hi there,

as the switch to the no-egress webtrigger will include breaking changes, we’re interested in the timeline to inform our customers.

  • When will the no-egress webtrigger be GA?
  • When will (legacy) egress webtrigger lead to the loss of the “Runs on Atlassian” badge?

Thanks in advance,
paul

Hi @ppasler ,

When will the no-egress webtrigger be GA?

We are aiming for a March release. I have just updated the public roadmap here: Jira

When will (legacy) egress webtrigger lead to the loss of the “Runs on Atlassian” badge?

The Forge CLI eligibility check already reports standard web triggers as not eligible for runs on atlassian.

Hi @HeyJoe ,

thanks for the update!

It would be nice to have the GA before the launch of the “Runs on Atlassian” marketplace badge. It’s stated to be available on Q2 2025 (Runs on Atlassian Gives Partners a New Way to Showcase Strict Data Protections - Work Life by Atlassian).

Can we already release a version for production without the GA of the no-egress webtrigger?

Cheers,
paul

1 Like

Hi @ppasler,

Yes we understand the importance of ensuring that the capabilities needed to achieve “Runs on Atlassian” eligibility are working ahead of the customer-facing launch (with time for partners to adopt them). That is the sequence of events we are striving for.

Can we already release a version for production without the GA of the no-egress webtrigger?

I would not recommend this. As per our release policy, features in early access are not recommended for production use and are not subject to our typical deprecation timelines (we can change them at any time).

We are exploring if we can improve the developer experience of the no-egress web trigger to address the pain point of trying to map exactly the manifest string to the stringified JSON result. So, code changes may be needed between EAP and GA before you launch.

Hope this helps! Thanks for your feedback during the EAP.

2 Likes