Automating Report Retrieval and Export Tasks Using SAS Visual Analytics REST APIs

Five ready-to-use SAS Studio programs that let you export and retrieve SAS Visual Analytics reports via REST APIs, PDF, PNG, package, and metadata with step-by-step explanations for readers new to REST APIs.

1. Introduction

SAS Viya REST APIs let developers and enterprise applications create, access, and manage SAS resources programmatically using any client technology. They make it possible to work with Visual Analytics reports by retrieving data, exporting content, and automating tasks without relying solely on the Visual Analytics user interface.

REST APIs offer great flexibility, but many SAS users are more comfortable working directly in SAS Studio. To bridge that gap, this article translates five commonly used SAS Visual Analytics REST APIs into ready-to-use SAS Studio programs built with PROC HTTP. The goal is to give customers and internal teams a practical, low-barrier starting point for automating report retrieval and export tasks, without needing deep REST API expertise.

This article is written for readers who may not have a technical background in REST APIs. Each section explains not just what a program does, but why it works the way it does, so you can adapt these examples with confidence.

2. What Is a REST API?

If you're new to REST APIs, it helps to think of one like ordering at a restaurant. You, the client, do not need to know how the kitchen works; you just need to know how to ask for what you want using a shared menu of requests. SAS Viya's REST APIs work the same way: your SAS Studio program asks a SAS Viya service for something, and the service responds.

Every request uses one of a small set of standard actions, called HTTP methods:

GET — "Show me something." Used to read or retrieve data (this is what all five programs in this article use).
POST — "Create something" or start an action.
PUT — "Update or replace something."
DELETE — "Remove something."
HEAD — "Just check whether it exists," without returning the full content.

Because all five programs in this article use GET, they are read-only: they retrieve or export information but never change anything in your SAS Viya environment. This makes them safe to test and learn with.

A typical REST API request has four parts:

URL — the address of the resource you're asking for (for example, a specific report).
Method — GET, POST, PUT, or DELETE, as described above.
Headers — extra information sent with the request, such as your access token and the response format you want back.
Body — additional data sent with the request (mainly used for POST and PUT; not needed for the GET calls in this article).

SAS Viya's REST APIs are also link-driven, meaning many responses include links to related resources or next actions. You do not need to memorize every possible URL; once you retrieve a resource, its response often tells you where to go next.

3. Benefits of Using REST APIs

Using these REST APIs through SAS Studio programs offers several advantages:

Automate repetitive report export tasks instead of doing them manually in the UI — saving time on recurring work.
Integrate SAS Visual Analytics with external systems, schedulers, or pipelines, so reports can flow into other tools automatically.
Reduce manual effort for recurring reporting needs, such as generating and distributing a PDF every month.
Enable scheduled, hands-off report generation, so reports are ready without anyone needing to log in and export manually.
Support broader enterprise reporting and automation workflows, laying the groundwork for more advanced integrations later.

4. Prerequisites

Before using the programs described in this article, confirm the following:

Access to a SAS Viya 4 environment and SAS Studio — you'll need a working login to run any of these programs.
Permission to view or export the target report(s) — having a valid token isn't enough if you don't have rights to the specific report.
PROC HTTP enabled for your SAS session — this is the SAS procedure that sends the REST API requests.

5. Overview of the REST APIs

This article covers five commonly used APIs from the Visualization and Reports category of the SAS REST API catalog, available at developer.sas.com/rest-apis. Each API below has a corresponding SAS Studio program that authenticates, calls the API, and returns the result. For each one, this article explains the endpoint, what happens step by step, what you need to provide, when to use it, and what you get back.

5.1 Export a Report Package

HTTP Method	GET
Endpoint	GET /reports/&report_id/package
Purpose	Exports a report, or selected report objects, as a compressed ZIP package. The package contains the report source files, data query results, and rendered images — everything needed to view the report remotely without a live connection back to the original environment.
Link	https://developer.sas.com/rest-apis/visualAnalytics/getExportedReportPackage

How it works, step by step

The program obtains an access token through SAS_SERVICES using the active SAS Studio session.
The report ID is defined once at the beginning of the program using a %let report_id=...; statement.
The program builds the REST API URL using the report_id macro variable and sends a GET request to the /package endpoint.
SAS Viya gathers the report definition, the latest data query results, and rendered images.
Everything is bundled into a single ZIP file and returned in the response.
The program saves that ZIP file to a location on disk.

What you need to provide (inputs)

A base URL for your SAS Viya environment.
The report_id value, defined in the %let report_id=...; statement at the beginning of the program.
Location of where the zip file will be saved.

When to use it

Backing up a report package.
Sharing reports across environments, for example from dev to test.
Enabling offline report viewing.

What you get back (output)

A binary ZIP file (application/zip) containing the report package. It is not human-readable JSON; it is meant to be saved and opened later or moved to another SAS Viya environment.

Sample SAS Code Snippet

5.2 Export a PDF of a Report

HTTP Method	GET
Endpoint	GET /reports/&report_id/pdf
Purpose	Exports a Visual Analytics report as a PDF document. The connection stays open while the PDF is generated, which can take some time for larger reports. Query parameters can override the rendering service's defaults and any export defaults saved with the report itself.
Link	https://developer.sas.com/rest-apis/visualAnalytics/getExportedReportPdf

How it works, step by step

The program obtains an access token through SAS_SERVICES using the active SAS Studio session.
The report ID is defined once at the beginning of the program using a %let report_id=...; statement.
SAS Viya renders the report exactly as it would appear on screen, page by page.
The service keeps the connection open while rendering completes — larger reports take longer.
The finished PDF is returned and saved to disk by the program.

What you need to provide (inputs)

A base URL for your SAS Viya environment.
The report_id value, defined in the %let report_id=...; statement at the beginning of the program.
Location of where the pdf file will be saved.

When to use it

Producing reports for management or board reviews.
Attaching a report to a scheduled email.
Generating documentation for compliance or audit purposes.

What you get back (output)

A binary PDF file (application/pdf), ready to save, print, email, or archive.

Sample SAS Code Snippet

5.3 Export a PNG Image of a Report Object

HTTP Method	GET
Endpoint	GET /reports/&report_id/png
Purpose	Exports a report, or part of a report, as a PNG image. The image format returned is controlled by the Accept header of the request.
Link	https://developer.sas.com/rest-apis/visualAnalytics/getExportedReportImagePNG

How it works, step by step

The program obtains an access token through SAS_SERVICES using the active SAS Studio session.
The report ID is defined once at the beginning of the program using a %let report_id=...; statement.
The program builds the REST API URL using the report_id macro variable and sends a GET request to the /png endpoint, optionally specifying a size as shown in the sample code.
SAS Viya renders the report or object as a static image.
The image is returned in the response and saved as a .png file by the program.

What you need to provide (inputs)

A base URL for your SAS Viya environment.
The report_id value, defined in the %let report_id=...; statement at the beginning of the program.
Optionally, the desired image size (width and height in pixels).
Location of where the png file will be saved.

When to use it

Capturing dashboard snapshots.
Sending chart images in alert notifications.
Embedding a visual in a presentation or document.

What you get back (output)

A binary PNG image, ready to embed, email, or display.

Sample SAS Code Snippet

Note: Confirm the exact Accept header value against the current SAS REST API documentation for your Viya release, as header formats can change between versions.

5.4 Get Report

HTTP Method	GET
Endpoint	GET /reports/&report_id
Purpose	Retrieves the specified report, including metadata such as report name, ID, creation date, owner, and last-modified date.
Link	https://developer.sas.com/rest-apis/reports/getReport

How it works, step by step

The program obtains an access token through SAS_SERVICES using the active SAS Studio session.
The report ID is defined once at the beginning of the program using a %let report_id=...; statement.
The program builds the REST API URL using the report_id macro variable and sends a GET request to /reports/&report_id.
SAS Viya returns the report's metadata as a JSON response (not the report's visual content — just information about it).
The program parses that JSON and can print it, for example using a JSON libname engine and PROC PRINT, as shown in the sample code.

What you need to provide (inputs)

A base URL for your SAS Viya environment.
The report_id value, defined in the %let report_id=...; statement at the beginning of the program.

When to use it

Building a report inventory for automation.
Validating that a report ID exists before running other operations.
Supporting audit and reporting workflows.

What you get back (output)

A JSON response describing the report: its unique ID, name, who created it, when it was created and last modified, and links to related resources.

Sample SAS Code Snippet

Illustrative Sample Output

Field names and values below are illustrative only, to show the shape of the response — your actual output will reflect your own report.

{

"id": "12345-abcde-67890",

"name": "Sales Performance",

"createdBy": "analyst_user",

"creationTimeStamp": "2026-05-04T09:15:00Z",

"modifiedTimeStamp": "2026-05-04T09:45:00Z",

"links": [ { "rel": "self", "href": "/reports/reports/12345-abcde-67890" } ]

}

5.5 Get Report Content

HTTP Method	GET
Endpoint	GET /reports/&report_id/content
Purpose	Retrieves the detailed content of a report, including objects, layouts, visual elements, and data bindings — essentially the structure that makes up the report.
Link	https://developer.sas.com/rest-apis/reports/getContent

How it works, step by step

The program obtains an access token through SAS_SERVICES using the active SAS Studio session.
The report ID is defined once at the beginning of the program using a %let report_id=...; statement.
The program builds the REST API URL using the report_id macro variable and sends a GET request to the /content endpoint.
SAS Viya returns the report's full internal structure as JSON — its sections, visual objects, layouts, and how each object is bound to data.
The program can save or inspect this JSON to understand exactly how the report is put together.

What you need to provide (inputs)

A base URL for your SAS Viya environment.
The report_id value, defined in the %let report_id=...; statement at the beginning of the program.
Location of where the XML file will be saved.

When to use it

Troubleshooting report structure issues.
Supporting report migration between environments.
Deeper analysis of how a report is built.

What you get back (output)

A JSON response describing the report's internal structure: its sections, visual objects, layout definitions, and the data each object is bound to.

Sample SAS Code Snippet

Illustrative Sample Output

Field names and values below are illustrative only, to show the shape of the response — your actual output will reflect your own report.

{

"reportId": "12345-abcde-67890",

"sections": [

{ "name": "Overview", "objects": [ "Bar Chart 1", "KPI Tile 1" ] }

],

"dataBindings": [ { "object": "Bar Chart 1", "dataSource": "SALES_TABLE" } ]

}

6. Authentication Using SAS_SERVICES

SAS Viya REST APIs use OAuth2 access tokens. In the SAS Studio examples in this article, the programs use the SAS_SERVICES oauth_bearer, which uses the current SAS Studio login session to generate an access token automatically. This token is then included as a Bearer token in the Authorization header of each REST API request. Without a valid token, calls fail with a 401 Unauthorized error.

Why use SAS_SERVICES?

It avoids hard-coding or manually supplying authentication details in the program.
It uses the authenticated SAS Studio session to request the access token.
It provides a cleaner and safer pattern for SAS Studio users who are already signed in to SAS Viya.

At a high level, the flow looks like this:

Step 1 — The user signs in to SAS Studio.
Step 2 — The program uses the SAS_SERVICES oauth_bearer to request an access token based on the active SAS Studio login session.
Step 3 — SAS Viya returns an access token associated with the signed-in user.
Step 4 — The program extracts that token and adds it as a Bearer token in the Authorization header.
Step 5 — The REST API call is made using that header, and SAS Viya honors the request according to the signed-in user's permissions.

Figure: Using SAS_SERVICES to request a token

The program uses SAS_SERVICES to obtain an access token from the current SAS Studio login session, so no separate authentication details need to be added to the code.

7. Common Errors and Troubleshooting

If a program doesn't behave as expected, the HTTP status code returned in the response is usually the fastest way to diagnose why. REST APIs use standard, well-known status codes, so learning to recognize a handful of them will get you a long way:

Status / Error	What It Means	Likely Cause	Suggested Action
200 OK	Success	Request succeeded.	No action needed.
201 Created	Success, resource created	A create/POST operation succeeded.	No action needed (not applicable to the GET-only programs in this article).
204 No Content	Success, empty response	Request succeeded but returned no body.	No action needed; confirm this is expected for the call.
401 Unauthorized	Not authenticated	Token missing, invalid, or expired.	Refresh the SAS Studio session, request a new token through SAS_SERVICES, and retry.
403 Forbidden	Not authorized	User lacks permission for the report.	Check report access permissions with your admin.
404 Not Found	Resource not found	Incorrect report ID or URL.	Verify the report ID and base URL.
409 / 412	Conflict	Update conflict or conditional header (ETag) mismatch.	Refresh the resource and retry the request.
SSL / Certificate error	Connection not trusted	Trust chain issue with the environment's certificate.	Check with your admin about the environment's certificate setup.
Timeout	No response in time	Large export (for example, a large PDF or package).	Increase the client timeout and retry.

A few general troubleshooting habits that help regardless of the specific error:

Read the response body, not just the status code — SAS Viya often returns a JSON error object with more detail.
Double-check the report_id and base URL first — typos here cause a large share of 404 errors.
If something worked yesterday and fails today with a 401, assume an expired token before anything else.
Test the simplest call (Get Report) first when debugging a new environment, before trying export-related calls.

8. Security Considerations

Because these programs use access tokens generated from the current SAS Studio session, treat tokens with the same care you would any other sensitive credential. A leaked token can be used by anyone to act as you within the token's lifetime and permissions.

Do not add personal authentication details directly into these SAS Studio programs.
Use SAS_SERVICES to obtain tokens from the active SAS Studio session instead of storing credentials in plain text.
Follow your organization's authentication and session-management policies.
Restrict who has access to generated tokens and to the programs that generate them.
Avoid printing or logging tokens — don't paste them into logs, emails, or chat messages, since anyone who sees the token can use it.
Each user is responsible for requesting and securing their own token; do not share a personal token with others.
If you suspect a token or credential has been exposed, request a new token and inform your SAS administrator promptly.

9. Disclaimer and Support

Important Disclaimer

These examples are intended for general guidance. For complex applications, review the SAS Help Center for detailed documentation.

10. Location of the code

The source code is available in the https://gitlab.sas.com/techsupport/technical-support-code/-/tree/main/usage/programming/sas-visual-a... project.