Applet Reports API
Three of the platform’s applet-only reports, given an etl-ep (access-key) twin so a server-to-server integration can pull the same rows the applet screen shows, without a signed-in user session. The endpoints are tenant-generic.
This reference assumes you have read Integration → Getting Started and have an access key. Authentication covers credentials; Data API covers the parts every etl-ep call shares. Everything below is specific to these three reports.
Available pages
- Sales Report By Document — the “SR By Document” screen in the Sales Report applet. Per-line sales detail, cost-basis fallback.
- Historical Stock Balance — the Stock Report applet’s balance-as-at-a-date screen. Zero-balance filtering and a historical-MA computation done server-side to match the applet.
- Profit Loss Report — the Financial Report applet’s top-level P&L (not the “Financial Report” menu’s own P&L view). The only one of the three where the endpoint builds the full statement structure server-side rather than returning raw GL rows.
Not yet in the generated pages
data/routes.tsv, exported from the backend at a pinned commit (data/backend-pin.txt) that predates the merge of #2628, #2629 and #2646. Once the pin advances and the route table is regenerated, the three routes will appear there as rows. Until then this hand-written section is the only place they are documented.Auth and the standard envelope
All three follow the platform’s normal access-key pattern: AccessId / AccessKey / tenantCode headers, POST with a JSON body, EndpointMethod.AuthenticatedTenantEndpointByAccessKey on the backend (falls back to a bearer token if the access-key headers are absent — see the two layers). See Authentication for the credential and Data API for headers and hosts shared with every other etl-ep call.
Two response envelope shapes appear across these three pages — check which one a given endpoint uses before parsing:
| Shape | Used by | Looks like |
|---|---|---|
StreamingPagingResponse | Sales Report By Document, Historical Stock Balance, all dropdowns | {"totalRecords":0,"offset":0,"limit":0,"code":"OK_RESPONSE","message":"","data":[ … ]}. totalRecords/offset/limit are always 0 on these three — none of them page. |
ApiResponse | Profit Loss Report | {"code":"OK_RESPONSE","data":[ … ],"message":""} — no paging fields at all. |
Filter dropdowns
DropDownController backs every filter dropdown on these three reports. Each report page lists the dropdown routes it needs. All use the same request body (keyword, filters, filterLogical, limit default 50, orderBy, order default "ASC") and return {"guid": "...", "code": "...", "name": "..."} per row in the StreamingPagingResponse envelope.
Related
- Reports — the generated page these three routes will join after merge
- API Reference — how the generated and hand-written layers relate
- Data API — hosts, headers, envelopes shared by every
etl-epcall - Authentication — the access key every call on this page’s pages carries