createReport
Request generation of a platform report for a date range and store scope. Asynchronous: the response returns the report with status queued before any data is gathered.
Failures beyond the document-wide codes: 422 when this (platform, type) is not available to your organization — including every DoorDash type, and a scope that resolves to no eligible store — or when the period violates the type's window constraint. fetchReportCoverage and its windowConstraint field say in advance which requests are valid.
Request
- typestring
The platform's own report type, e.g.
PAYMENT_DETAILS_REPORTororder-details. - platformstring
Delivery platform slug, e.g.
ubereatsorgrubhub. - periodStartstring<date>
First day of the period, inclusive.
- periodEndstring<date>
Last day of the period, inclusive.
- locationIdsstring[]
Narrow to stores at these locations. Omit for all locations.
- storeIdsstring[]
Narrow to these stores. Omit for all stores in scope. Mutually exclusive with
locationIds.
{
"type": "<type>",
"platform": "<platform>",
"periodStart": "<periodStart>",
"periodEnd": "<periodEnd>",
"locationIds": [
"<locationIds>"
],
"storeIds": [
"<storeIds>"
]
}Responses
- reportReport
The newly recorded report request. Poll
fetchReportsfor its status.
About Reports
Partner reporting. Coverage and every report are tenant-scoped and never global: the organization is the one the API key authenticates, and no request field can name another.
createReport is a WRITE and is classified as one in ManagementApiKeyHook.
NOT IMPLEMENTED: replay via Idempotency-Key (ONE-2950 decides the platform-wide answer). The published contract declares the header on createReport; it is accepted and IGNORED today, so a retried createReport requests a second report with a new reportId. That wastes platform budget but corrupts nothing — each report is an independent file. Treat a timeout as "may have succeeded" and check fetchReports before retrying.