There is a reason Atlassian is having trouble figuring this out… it is because Atlassian wants two things that can’t co-exist.
The initial premise of Runs on Atlassian has always been that all data and processing remains within the Atlassian platform.
Step by step, Atlassian is finding out that this really narrows down the type of apps that qualify for Runs on Atlassian. Many apps require data egress to function. In addition, customers may want/need a way to access app data from the Forge platform.
So there are now three initiatives that are exploring amending the Runs on Atlassian program, allowing data egress:
- Analytics & logs to external remotes
- Forge REST API
- Configurable egress & remotes
The first one is easy. Analytics should always be optional, the app continues to work, all is well. We accept that Atlassian cannot control the outbound payload so in theory analytics &
logs might contain user data from the platform. Atlassian acknowledges this by saying that we should act in the spirit of RoA when implementing analytics
In the context of Runs on Atlassian, you must not mark tools that don’t capture analytics data as analytics egress .
The configurable egress & remotes are causing headaches as this basically means unlimited outbound data egress. Sure, customers can enable/disable it, but typically these types of egress will be used for non-optional product features. Disabling egress means the app won’t work anymore. This is probably also why it is currently considered incompatible with RoA (and rightfully so!).
Now let’s look at the current RFC at hand, Forge REST API.
This RFC basically covers two scenario’s:
Inbound data
Inbound data is when the Forge REST API is used to trigger function execution, as a replacement for the current Forge web triggers:
Example integrations might be from an external app, a cron job, a plugin, or even direct API calls.
This is a valid scenario, but interestingly, the current specs do not really work well for this scenario: the request limit is 800kb, while the response limit is 5MB. So the external integration triggering the API can hardly sent any data for processing. It remains to be seen whether or not this is useful for integrations. In addition, one could argue that this scenario does not require a 5MB response, as a 204 No Content response code should be enough to acknowledge the trigger.
Outbound data
Outbound data is when the Forge REST API is used to extract app data. This is what @JamesDumay is referring to:
This is for customers to get their data from our platform.
This is another valid scenario, and this matches the request/response limit. The customer scripts or cron job hit the Forge REST API to get their data from the Atlassian platform. This should not require a large payload, so 800Kb is fine. The Forge REST API function has a 5MB response limit, which makes sense for offloading app data.
However, from the context of Runs on Atlassian, what makes this weird is that the app can intertwine app data and product data in the response. One could argue that the customer can just use the product REST API to get product data and that the Forge REST API should only be able to respond with app data (that is not accessible from the product API).
By allowing the Forge app to respond with product data in the Forge REST API, it negates the proposed (very valid) scenario of allowing customers to retrieve their app data.
Alternative solution 1
As we have seen with Connect, Atlassian Marketplace Partners are very resourceful in finding ways to use platform features in unexpected ways. We are already seeing with Analytics that Atlassian is now relying on partners to “do the right thing 
” with data egress.
Let’s make sure that we do not make the same mistake again.
I would like to propose that Atlassian changes this RFC to allow 2 different types of Forge REST API endpoints: inbound & outbound.
The inbound REST API endpoints should allow for a large request body (5MB) and only support a response code (i.e. 200, 204, 400, 500, etc). This will allow integrations to send data to the Forge app, but ensures that there is no data egress. Inbound endpoints should have asApp and asUser access to product APIs in order to process the data for the app.
The outbound REST API endpoints should allow for a small request body (800kb) and a large response body (5MB) as this is meant to egress app data. However, the outbound API endpoints should NOT have asApp or asUser access to product REST APIs. It should only have access to Forge storage types (KV, SQL, etc).
This way, we can ensure that product data does not (accidentally) leak from the Forge REST API. It also means that Forge REST API can be qualified for Runs on Atlassian. Both inbound and outbound REST API endpoints can be considered optional.
Alternative solution 2
If the goal is to only support allowing customers to retrieve app data, Atlassian could also decide to take full control over this. It could expose product API endpoints that allow customers to retrieve forge app data from KV, SQL or Object storage (or any other support Forge storage solution).
Atlassian could provide Forge developers with “transformers”, which would allow the app vendor to add logic to the data extraction. This could be a simple IO where the transformer does not have access to any internal/external system. It would only be used to re-shape the data in a more logical and understandable way.
Proper stewardship
Whatever solution Atlassian choses, I would really like to urge Atlassian to be a more careful guardian of the Runs on Atlassian program and embrace the No Data Egress promise of this trust signal.
Atlassian can’t have her cake and eat it.
Atlassian can’t expect Atlassian Marketplace Partners to not find creative ways to work with the platform features and somehow appeal to the “spirit” of Runs on Atlassian. People will get burned by this, especially because it seems like Atlassian doesn’t always fully grasp what that spirit means.
Being a good steward of the Atlassian Ecosystem also means that Atlassian prevents setting partners up for failure. By making Runs on Atlassian requirements opaque Atlassian is harming the ecosystem.