You can use apex_export.get_application to create Apex exports from pl/sql.
This works fine, but as with the APEXExport java utility, not everything is exported by default. Most options are set to false by default, so you should check carefully which ones you need.

The API Reference gives a simple example, but since I always seem to forget how to use apex_t_varchar2 types (having to use apex_string.push just doesn't seem logical somehow), I have included my own one here.

apex_export.get_application usage (Apex 23.1):

declare l_files apex_t_export_files; l_components apex_t_varchar2; l_name varchar2(100); l_contents clob; begin apex_string.push(l_components, 'PAGE:1001'); l_files := apex_export.get_application(p_application_id => 25384 ,p_with_ir_public_reports => true ,p_with_ir_private_reports => true ,p_components => l_components); l_name := l_files(1).name; dbms_output.put_line('l_name = ' || l_name); l_contents := l_files(1).contents; dbms_output.put_line('l_contents length = ' || length(l_contents)); end;

According to Doc ID 2893264.1 this can happen after an upgrade to 22.1 when using apex_export.get_application.

From that document:
CAUSE The issue has been identified as the product defect. The same was documented over the INTERNAL Bug 34534485 APPLICATION EXPORT FAILS WHEN USING SWITZERLAND NLS TERRITORY SETTING SOLUTION 1) for SQLcl: setting NLS_LANG in the session calling SQLcl export NLS_LANG='AMERICAN_AMERICA' or 2) for both SQLcl and PL/SQL: adding this to the SQL or PL/SQL script alter session set nls_numeric_characters='.,'; Import the application and test the behavior.