To schedule a report through an API, you send an HTTP request, usually a POST, that describes a recurring job: which report, how often, in what format, and who receives it. The server stores that schedule and runs it on time with no one clicking anything. The idea is the same everywhere. The details differ a lot between platforms, and those details decide whether you end up with a clean integration or a pile of scripts to maintain.
This guide covers the common shape of a scheduling API, what Power BI, SSRS and Tableau give you natively, the traps that cause scheduled jobs to fail quietly, and when it makes sense to stop writing code and use a product built for the job.
TL;DR
- A report schedule is one object that bundles the report, its parameters, output format, recipients and timing. Most REST APIs create it with a POST and list it with a GET.
- Power BI's export API is asynchronous (request, poll, download) and, per a Microsoft community write-up, runs only on Premium-type capacity, so it is not a scheduler by itself.
- SSRS (2017 and later) and Tableau expose subscription endpoints that attach a report to a schedule for a recipient.
- Most failures come from authentication, time zones, long-running exports and missing retries, not from the schedule request itself.
- If you need hundreds of recipients, event triggers and error handling across several BI tools, a dedicated automation layer such as PBRS costs less than maintaining custom code.
Table of Contents
- What "scheduling a report via API" actually means
- The shape of a typical schedule request
- What the major BI platforms give you
- A reliable pattern when you build it yourself
- Where API scheduling breaks down
- Our perspective: use the API for control, not for plumbing
- Build, buy or combine: how to decide
- Automating report delivery with PBRS, ATRS and CRD
- FAQ
- Sources
What "scheduling a report via API" actually means
An API schedule is a programmatic way to create, update or delete recurring report tasks over HTTP. Vertex's reporting documentation describes the typical parameters: a report ID, a frequency such as daily, weekly or monthly, an execution time, a recipient list and an output format such as PDF, CSV or Excel.
The useful mental model is that a schedule is not just a timer. As Datadog's report schedule endpoint shows, it packages report metadata, rendering options such as filters, a delivery destination and timing rules into one repeatable object that the server executes. You manage the object, and the server owns the execution.
That distinction matters because there are two very different things people mean by the phrase:
- Creating a schedule through the API. You POST a definition once. The platform runs it forever. This is what subscription and schedule endpoints do.
- Triggering a run through the API. Your own scheduler (cron, Azure Data Factory, a workflow tool) calls an endpoint at the right moment to generate a report now. You own the timing.
If the platform has the first, use it. If it only has the second, you are building the scheduler yourself.
The shape of a typical schedule request
Public documentation from unrelated vendors converges on nearly the same design. A few examples:
- Digi Remote Manager lets you schedule recurring reports that are emailed to recipients as Excel files, with daily, weekly or monthly runs.
- Letpay uses a POST to a schedule endpoint to run a report at a set time on a daily, weekly or monthly cycle.
- GetResponse schedules custom reports with a POST to a custom reports endpoint, with options that depend on the report type.
- Silverflow offers a report scheduling API to automate report generation on its platform.
A generic request looks like this:
POST /reports/schedules
Content-Type: application/json
{
"reportId": "sales-by-region",
"frequency": "weekly",
"dayOfWeek": "Monday",
"time": "07:00",
"timeZone": "America/Chicago",
"format": "PDF",
"parameters": { "region": "Southwest" },
"recipients": ["ops-leads@example.com"]
}
This is an illustration of the pattern, not any vendor's actual schema. Always check field names and limits in the platform's own reference.
The five fields that matter
| Field | What to decide | Common mistake |
|---|---|---|
| Report identifier | Stable ID, not a display name | Using names that someone later renames |
| Recurrence | Frequency, day, time | Ignoring daylight saving changes |
| Parameters | Filters, date ranges | Hard-coding a date that goes stale |
| Format | PDF, Excel, CSV | Choosing PDF for data people will re-use |
| Destination | Email, file share, chat | Sending to individuals instead of a managed list |
What the major BI platforms give you
Power BI
Power BI's REST API can export a report to a file, but it works as a job, not a schedule. A Microsoft community walkthrough describes the sequence: call Export to File with the workspace and report IDs to get an export ID, call the status endpoint until it reports success, then retrieve the file. The same post notes the method is for Premium workspaces and does not run on Pro or PPU. Check Microsoft's current documentation for your license before you design around it.

So with Power BI you typically get the render, and you supply everything else: the timer, the loop over recipients, the email sending, the retries. That is why teams often reach for Power Automate. Our own walkthrough of using Power Automate for BI report scheduling and delivery covers where that approach works and where it starts to strain. For a broader view, see our Power BI report automation API overview.
SSRS and Power BI Report Server
SSRS is the friendliest of the three for API scheduling. The community project SSRS_Rest_API on GitHub includes a PowerShell script that creates, modifies, moves and deletes SSRS objects, including subscriptions, through the REST API. It requires SQL Server Reporting Services 2017 or later, or Power BI Report Server. Subscriptions are first-class objects, so you can create a schedule once and let the report server own the execution.
The limits are the usual native ones: subscription features depend on the edition, and complex personalization or conditional delivery means more custom work.
Tableau
Tableau's REST API includes a subscriptions resource. According to a community-maintained OpenAPI description of the Tableau Subscriptions API, the create call makes a new subscription to a view or workbook for a specified user on a specified schedule. Notice what that implies: a subscription is per user, and the schedule must already exist on the server. Setting up a thousand recipients means a thousand calls, plus ongoing upkeep when people join or leave. If you work mostly in Tableau, our guide to scheduling Tableau reports by email and exporting to Excel shows the native options side by side.
Crystal Reports and SAP BusinessObjects
Crystal and BusinessObjects scheduling through REST is a frequent source of confusion. Threads such as this SAP Community question about scheduling a Crystal report from the REST API show developers hitting errors on the right URL and request format. If you are in that position, read our guide on how to schedule Crystal Reports before writing code.
A reliable pattern when you build it yourself
Whether you call a native endpoint or write your own orchestrator, the same design keeps jobs dependable.
- Authenticate with a service identity. Use a service principal or dedicated service account with only the permissions the job needs. Tokens expire, so refresh them inside the job, not once at the start of a nightly batch.
- Store schedules as data. Keep a table or config file of report, recipients, parameters and cadence. The code reads it and creates or updates schedules. Changes then become a row edit, not a deployment.
- Make creation idempotent. Look up an existing schedule by a stable key before posting a new one. Otherwise a re-run doubles every delivery.
- Poll asynchronous jobs with a timeout. For export-style APIs, wait with growing intervals, set a maximum wait and fail loudly when it is exceeded.
- Pin time zones explicitly. Send the zone name, not an offset. "7:00" means nothing until the server knows whose 7:00 it is.
- Check data freshness first. A report that runs before its dataset refresh finishes delivers yesterday's numbers on time. Chain the run to refresh completion. Readers on other platforms hit the same problem, as in this Amazon QuickSight community thread about running a report after a dataset refresh.
- Log every run and alert on failures. The worst failure is silence. Record start, end, status and recipient count, and notify a person when a run fails or produces an empty file.
- Retry with limits. Retry transient errors a few times with backoff. Never retry in a way that sends a duplicate email to the whole list.
Worked example: a Monday sales pack
Suppose finance wants a Power BI sales report as a PDF for 40 regional managers, each filtered to their own region, every Monday at 7:00 a.m. Central.
With a scripted approach you would need to:
- read the manager list and regions from a table;
- call the export endpoint 40 times with a different filter each time;
- poll 40 export jobs and handle any that time out;
- download 40 files and email each to the right person;
- confirm the dataset refreshed before starting;
- log results and alert on the failures.
None of it is difficult. All of it is code that someone must own, test and fix when a token policy changes or a manager changes roles. That ongoing cost is what usually gets underestimated.
Where API scheduling breaks down
These are the problems we see teams run into most, and they are mostly about operations.
- Capacity and throttling. Export APIs consume server resources. Fire hundreds of simultaneous requests at 7:00 a.m. and some will queue or fail. Stagger them.
- Licensing. Some APIs only work on certain capacity tiers, as the Power BI example above shows. Confirm before you commit.
- Per-user subscriptions. As with Tableau, one schedule per recipient multiplies maintenance.
- External recipients. Native subscriptions often assume the recipient is a licensed internal user. Customers and partners are harder.
- Security. API keys in scripts, reports emailed to personal addresses and unlogged exports all create audit gaps.
- Preview endpoints. Some APIs are flagged as preview and subject to change, as Datadog notes for its report schedule endpoint. Building production processes on them needs a plan for change.
Our perspective: use the API for control, not for plumbing
We have spent more than two decades helping teams automate reporting across Power BI, SSRS, Tableau and Crystal Reports, and the pattern we see is consistent. Teams start with a script or a flow because it is free and quick. It works for ten reports. By a hundred, someone owns a fragile system that nobody else understands, and the business is relying on it for executive and customer deliverables.

The API is valuable, but the best use of it is as a control surface: create a schedule from your deployment pipeline, trigger a run when an upstream event finishes, or pull status into your monitoring. The heavy lifting (rendering, bursting to recipients, formatting, delivery to email, file shares, cloud storage and collaboration tools, error handling and retries) belongs in a product designed for it, running on your own infrastructure with proper logging.
That is how we built PBRS, ATRS and CRD. You define the schedule, the filters, the format and the destination once, and the software handles the repetition. When your own systems need to be involved, a REST API lets them start a schedule on demand, and our knowledge base article on executing a PBRS schedule through the REST API shows how. Your code stays small, and the business logic lives where analysts can see and change it.
— Christian Ofori-Boateng
Build, buy or combine: how to decide
| Situation | Likely best choice |
|---|---|
| A handful of reports, one platform, one developer who can maintain it | Native subscriptions or a small script |
| Dozens of reports, a few recipients each, Microsoft 365 already in place | Power Automate or similar workflow tool |
| Hundreds or thousands of recipients, personalized filters, external recipients | Dedicated automation software |
| Several BI tools to cover (Power BI, Tableau, Crystal) | Dedicated automation software, so the process is the same everywhere |
| Delivery must start when a data load finishes | Dedicated software with event triggers, or an API call from your pipeline |
| Audit requirements for every delivery | Dedicated software with logging |
A useful test: count how many people would need to understand your custom code if its author left tomorrow. If the answer is "nobody" and the reports matter, that is your signal.
Automating report delivery with PBRS, ATRS and CRD
If you are scheduling Power BI or SSRS reports, PBRS for Power BI and SSRS schedules, personalizes, exports and delivers reports to licensed or external recipients, with data-driven bursting and event-triggered workflows. ATRS covers Tableau Reports and CRD covers Crystal Reports with the same approach, and each is available as a subscription or perpetual license. You can start with a free trial or demo and test it against a real report. For a walkthrough of the Power BI side, read our enterprise guide to scheduling Power BI reports.
FAQ
What is an API schedule?
It is a recurring report job defined through HTTP requests instead of a user interface. You send the report, the frequency, the time, the format and the recipients, and the server stores and runs it. Most platforms let you create, list, update and delete these schedules with standard REST methods.
Can I schedule a Power BI report using only the REST API?
Not as a single call. The export endpoint renders a report on demand, and you must supply the timer and the delivery. A Microsoft community walkthrough also says the export method needs a Premium workspace. Teams usually add a workflow tool or a dedicated product such as PBRS to handle timing, recipients and email.
How do I schedule SSRS reports through an API?
SSRS 2017 and later, and Power BI Report Server, expose a REST API that can create and manage subscriptions. Community scripts show the full create, modify, move and delete cycle. Test in a non-production folder first, because subscription settings depend on your edition and security setup.
How do I stop scheduled reports from failing silently?
Log every run, alert a person on any failure or empty output, and make the run wait for the dataset refresh to finish. Use a service account with tokens that refresh inside the job. Add limited retries so a transient error does not trigger a duplicate send.
Sources
- Using the Solution Reporting API, Vertex
- Create a report schedule, Datadog API
- Scheduled Reports, Digi Remote Manager
- Create Schedule, Letpay Documentation
- Schedule custom reports, GetResponse API Docs
- Report scheduling, Silverflow API Docs
- How to use Power BI Rest API to export the Power BI Report in PDF format, Microsoft Fabric Community
- SSRS_Rest_API subscription deployment script, GitHub
- Tableau Subscriptions API OpenAPI description, API Evangelist
- Scheduling a dataset and then run a scheduled report, Amazon QuickSight Community
