> **Building with AI coding agents?** Install the authstack plugin with one command. This equips your agent with accurate Scalekit implementation patterns.
>
> **Recommended**:
> ```bash
> npx @scalekit-inc/cli setup
> ```
>
> Global:
> ```bash
> npm install -g @scalekit-inc/cli
> scalekit setup
> ```
>
> Supports Claude Code, Cursor, GitHub Copilot, Codex + skills for 40+ agents.
> Features: full-stack-auth, agent-auth, mcp-auth, modular-sso, modular-scim.
> [Full setup guide](https://docs.scalekit.com/dev-kit/build-with-ai/)

---

# AWS Redshift connector

Connect Amazon Redshift to Scalekit with the Trusted IDP flow so agents run SQL over federated AWS credentials, with no long-lived keys stored.

**Authentication:** Trusted IDP
**Categories:** Analytics, Databases
Connect an Amazon Redshift database to Scalekit using the **Trusted IDP** flow. Once connected, agents built on the Scalekit Agent Connect SDK can run SQL, list tables, describe schemas, and manage queries against your Redshift cluster (provisioned or serverless) — **without you ever storing long-lived AWS credentials in Scalekit**.

Supports authentication: 

1. ### Install the SDK

   
     ### Node.js

```bash frame="terminal"
npm install @scalekit-sdk/node
```

     ### Python

```bash frame="terminal"
pip install scalekit
```

   

   Full SDK reference: [Node.js](/agentkit/sdks/node/) | [Python](/agentkit/sdks/python/)

2. ### Set your credentials

   Add your Scalekit credentials to your `.env` file. Find values in **[app.scalekit.com](https://app.scalekit.com)** > **Developers** > **API Credentials**.

```sh showLineNumbers=false title=".env"
SCALEKIT_ENVIRONMENT_URL=<your-environment-url>
SCALEKIT_CLIENT_ID=<your-client-id>
SCALEKIT_CLIENT_SECRET=<your-client-secret>
```

## How it works

Scalekit acts as an OIDC identity provider that AWS IAM trusts. No long-lived AWS access key is ever stored. When a tool call needs credentials — on the first call, on a cache miss, or when the cached credentials are near expiry — Scalekit runs this exchange:

1. Scalekit mints a short-lived JWT signed with your environment's OIDC signing key.
2. Scalekit calls AWS STS `AssumeRoleWithWebIdentity` with that JWT. AWS validates the signature against Scalekit's public JWKS and issues temporary credentials (about a 1-hour lifetime).
3. Scalekit uses those temporary credentials to call the Redshift Data API on your behalf.

Between exchanges, Scalekit reuses the cached temporary credentials and refreshes them proactively before they expire, so most tool calls skip the STS round-trip.

You keep the IAM role and trust policy in your own AWS account. Scalekit never sees a long-lived AWS access key.

## Prerequisites

- An **AWS account** where your Redshift cluster or serverless workgroup runs.
- **IAM permissions** in that account to create OIDC providers and roles: `iam:CreateOpenIDConnectProvider`, `iam:CreateRole`, and `iam:PutRolePolicy`.
- A **Scalekit workspace** with an environment provisioned and admin access to the dashboard.
- A **Redshift target**, either:
  - **Provisioned cluster** — cluster identifier, database name, and a database user.
  - **Serverless workgroup** — workgroup name, namespace name, and database name.

> note: Redshift connector not visible?
>
> If the AWS Redshift connector isn't available in your dashboard yet, contact your Scalekit account team to enable it.

## Gather your Scalekit details first

Before you touch AWS, collect two values from the Scalekit dashboard. You paste both into AWS during the AWS-side setup.

- **Environment URL** (becomes the JWT `iss` claim) — Go to **Settings > Environment**, copy the **environment domain** (for example `acme-prod.scalekit.cloud`), and prefix it with `https://` when AWS asks for the full URL: `https://acme-prod.scalekit.cloud`.
- **Connection ID** (becomes the JWT `aud` claim) — Go to **AgentKit > Connectors > AWS Redshift**, click **Create connection**, save it, and copy the **Connection ID** (for example `conn_128516460753453607`).

> note: What these values mean for AWS
>
> Scalekit mints a JWT for every Redshift call with `iss = <environment URL>` and `aud = `. AWS validates **both**: the OIDC provider you register has to match the issuer, and its registered audience list has to contain your Connection ID. Collect them once, paste them in two places.

> caution: Local development issuers must be publicly reachable
>
> The issuer AWS validates is your Scalekit environment URL, and AWS must be able to reach its JWKS endpoint. A `*.localhost` domain won't work. For local development, use your staging Scalekit environment URL. A tunnel such as ngrok only works if it fronts your Scalekit issuer domain — an arbitrary tunnel hostname can't stand in for the issuer, because AWS matches the JWT `iss` against the registered OIDC provider.

## Part 1 — Set up AWS

### Register Scalekit as an OIDC provider in AWS IAM

Register Scalekit's environment URL as a trusted OIDC issuer in your AWS account, and register your Connection ID as the audience. This is a one-time setup per Scalekit environment.

1. Sign in to the [AWS Management Console](https://console.aws.amazon.com/) and open the **IAM** service.
2. In the left navigation pane, click **Identity providers**, then **Add provider**.
3. For **Provider type**, select **OpenID Connect**.
4. For **Provider URL**, paste your full Scalekit environment URL including `https://`, for example `https://acme-prod.scalekit.cloud`.
5. For **Audience**, paste your **Connection ID**, for example `conn_128516460753453607`. AWS checks this against the JWT's `aud` claim.
6. (Optional) Add tags for cost allocation or ownership tracking.
7. Click **Add provider**.

> caution: Do not enter sts.amazonaws.com as the audience
>
> Entering `sts.amazonaws.com` is a common mistake copied from generic OIDC guides. It causes `InvalidIdentityToken` errors later. The audience must be your Scalekit Connection ID.

After the provider is created, open it and copy the **ARN** from the top of the page. You reference this ARN in the trust policy in the next step.

```text
arn:aws:iam:::oidc-provider/
```

> note: Adding a second Connection ID later
>
> If you add another Redshift connection in the same Scalekit environment, don't create a new OIDC provider — add the new Connection ID to this provider's audience list. Updating the OIDC provider alone isn't enough if you reuse the same IAM role: its trust policy `aud` condition still accepts only the original Connection ID. Either add the new ID to that condition (`":aud": ["", ""]`) or create a separate role for the new audience.

### Create the IAM role

This is the role Scalekit assumes on every Redshift tool call. Its trust policy conditions on `aud = ` — the same Connection ID you registered as the audience above.

1. In the IAM console, click **Roles**, then **Create role**.
2. For **Trusted entity type**, select **Web identity**.
3. For **Identity provider**, pick the provider you created above. It appears as ``.
4. For **Audience**, pick your Connection ID (for example `conn_128516460753453607`).
5. Click **Next**.
6. Leave **Permissions policies** empty for now. You attach an inline policy in the next step. Click **Next**.
7. For **Role name**, enter `ScalekitRedshiftAccess` (or any name — keep a note of it for the connected account).
8. (Optional) Add a description, for example "Federated access for Scalekit Agent Connect to Redshift".
9. Click **Create role**.

Because you picked your Connection ID as the audience, the wizard generates a correct trust policy with `":aud": ""`. After the role is created, copy its **Role ARN** — you paste it into Scalekit later.

```text
arn:aws:iam:::role/ScalekitRedshiftAccess
```

#### Trust policy reference

The wizard generates the policy below. If you used the wizard, it's already in place.

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam:::oidc-provider/"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          ":aud": ""
        }
      }
    }
  ]
}
```

| Placeholder | Example | What it is |
| --- | --- | --- |
| `` | `166424725243` | Your 12-digit AWS account number |
| `` | `acme-prod.scalekit.cloud` | Scalekit environment domain, without `https://` |
| `` | `conn_128516460753453607` | The Connection ID from the Scalekit dashboard |

#### Optional: restrict the role to one organization

By default the trust policy lets **any** connected account backed by this connection assume the role. To restrict it to **one specific** organization or identifier, add a `sub` condition to the `StringEquals` block:

```json
"Condition": {
  "StringEquals": {
    ":aud": "",
    ":sub": ""
  }
}
```

`` is the value you set as the connected account's identifier. It must match exactly. This value becomes the JWT `sub` claim and is exposed through AWS federation and CloudTrail, so use an opaque identifier such as an organization ID — avoid personal data like an email address.

### Attach the permission policy

The trust policy lets Scalekit **assume** the role. The permission policy controls what the role can do inside AWS. Attach one of the following as an inline policy on the role, depending on your Redshift target.

  ### Serverless workgroup

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RedshiftDataAPI",
      "Effect": "Allow",
      "Action": [
        "redshift-data:ExecuteStatement",
        "redshift-data:DescribeStatement",
        "redshift-data:GetStatementResult",
        "redshift-data:CancelStatement",
        "redshift-data:ListStatements",
        "redshift-data:ListTables",
        "redshift-data:ListSchemas",
        "redshift-data:DescribeTable"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RedshiftServerlessAuth",
      "Effect": "Allow",
      "Action": "redshift-serverless:GetCredentials",
      "Resource": "arn:aws:redshift-serverless:::workgroup/"
    }
  ]
}
```

  ### Provisioned cluster

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RedshiftDataAPI",
      "Effect": "Allow",
      "Action": [
        "redshift-data:ExecuteStatement",
        "redshift-data:DescribeStatement",
        "redshift-data:GetStatementResult",
        "redshift-data:CancelStatement",
        "redshift-data:ListStatements",
        "redshift-data:ListTables",
        "redshift-data:ListSchemas",
        "redshift-data:DescribeTable"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RedshiftProvisionedAuth",
      "Effect": "Allow",
      "Action": "redshift:GetClusterCredentials",
      "Resource": [
        "arn:aws:redshift:::dbname:/",
        "arn:aws:redshift:::dbuser:/"
      ]
    }
  ]
}
```

| Placeholder | Example |
| --- | --- |
| `` | `us-east-1` |
| `` | `166424725243` |
| `` (serverless) | `93725977-d43f-423a-8908-d5a64caff6ba` — the workgroup UUID, not its name |
| `` (provisioned) | `prod-analytics` |
| `` | `analytics` |
| `` (provisioned) | `analytics_reader` |

> caution: Scope the serverless action to a workgroup ARN
>
> Scope `redshift-serverless:GetCredentials` to a specific workgroup ARN. A wildcard `*` is documented but not reliable in practice — use the exact workgroup ARN, including its UUID. `` is the workgroup's ID (a UUID), not its name. Copy the workgroup ARN from the AWS console (**Amazon Redshift Serverless > Workgroup configuration**), or read `workgroupId` from `aws redshift-serverless get-workgroup`, and use its final segment.

## Part 2 — Set up your Redshift database

### Serverless workgroup (recommended)

Serverless workgroups authenticate the IAM identity directly, so you don't need to create a database user. On the first IAM connection, AWS resolves the IAM role to an `IAMR:<role-name>` database role automatically.

That database role still needs privileges. Authentication can succeed while queries fail with authorization errors if you skip this step. Connect as an admin and grant the role the access the agent needs:

```sql
-- Grant the access the agent needs to the auto-created IAM database role.
-- The role name is IAMR: followed by your IAM role name.
GRANT USAGE ON SCHEMA public TO "IAMR:ScalekitRedshiftAccess";
GRANT SELECT ON ALL TABLES IN SCHEMA public TO "IAMR:ScalekitRedshiftAccess";
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO "IAMR:ScalekitRedshiftAccess";
```

### Provisioned cluster

Connect to your cluster as a superuser (psql, JDBC, or Query Editor v2), then create the database user the IAM role maps to and grant it the access you want the agent to have.

```sql
-- Create the user the IAM role maps to. No password: it authenticates via IAM.
CREATE USER analytics_reader WITH PASSWORD DISABLE;

-- Grant only the read access the agent needs.
GRANT USAGE ON SCHEMA public TO analytics_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO analytics_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO analytics_reader;
```

> note: Keep the username consistent
>
> The username (`analytics_reader` here) must match `` in the permission policy and the `db_user` field on the connected account.

## Part 3 — Create a connection and connected account in Scalekit

A **connected account** binds one organization (or tenant) in your app to one AWS Redshift target. You already created the connection itself in [Gather your Scalekit details first](#gather-your-scalekit-details-first) — its Connection ID is what you registered in AWS. Here you reopen that connection to add a connected account.

1. In the Scalekit dashboard, go to **AgentKit > Connectors** and click **AWS Redshift**.
2. Open the connection you created earlier (the one whose Connection ID you used in the trust policy).
3. Click **Add connected account** and fill in the fields below.
4. Save. Scalekit creates the connected account in `ACTIVE` status. The first STS exchange happens lazily on the first tool call.

| Field | Required | Notes |
| --- | --- | --- |
| **Identifier** |  | Becomes the JWT `sub` claim, which is exposed through AWS federation and CloudTrail. Use an opaque, stable value such as your organization's ID — avoid personal data like an email address. If you used the `sub` condition in the trust policy, this must match exactly. |
| **Role ARN** |  | The IAM role ARN you created in Part 1. |
| **Region** |  | AWS region, for example `us-east-1`. |
| **Database** |  | Redshift database name. |
| **Cluster identifier** | One of | For provisioned clusters. |
| **Workgroup name** | One of | For serverless workgroups. |
| **Namespace name** | With workgroup | Serverless namespace name. |
| **DB user** | Provisioned only | The username from Part 2 (for example `analytics_reader`); ignored for serverless. |

> caution: Cluster identifier and workgroup name are mutually exclusive
>
> Set exactly one of **Cluster identifier** or **Workgroup name**. Leave the other empty.

### API equivalent (optional)

To create the connected account programmatically instead of using the dashboard, read your API token from an environment variable. The payload shape differs slightly between serverless and provisioned targets.

> caution: Never inline the API token
>
> The API token grants access to connected-account credentials. Read it from an environment variable so it doesn't leak into shell history or source control. Never paste it as a literal.

  ### Serverless workgroup

```bash frame="terminal"
# Export the token first: export SCALEKIT_API_TOKEN=...
curl -X POST "https:///api/v1/connected_accounts" \
  -H "Authorization: Bearer $SCALEKIT_API_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
    "identifier": "acme-org-id",
    "connector": "redshift-",
    "connected_account": {
      "api_config": {
        "role_arn": "arn:aws:iam::166424725243:role/ScalekitRedshiftAccess",
        "region": "us-east-1",
        "database": "analytics",
        "workgroup_name": "analytics-wg",
        "namespace_name": "analytics-ns"
      }
    }
  }'
```

  ### Provisioned cluster

```bash frame="terminal"
# Export the token first: export SCALEKIT_API_TOKEN=...
curl -X POST "https:///api/v1/connected_accounts" \
  -H "Authorization: Bearer $SCALEKIT_API_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
    "identifier": "acme-org-id",
    "connector": "redshift-",
    "connected_account": {
      "authorization_details": {
        "trusted_idp": { "db_user": "analytics_reader" }
      },
      "api_config": {
        "role_arn": "arn:aws:iam::166424725243:role/ScalekitRedshiftAccess",
        "region": "us-east-1",
        "database": "analytics",
        "cluster_identifier": "prod-analytics"
      }
    }
  }'
```

The serverless payload omits `trusted_idp.db_user` (serverless resolves the IAM identity directly), while the provisioned payload includes it and uses `cluster_identifier` instead of `workgroup_name` / `namespace_name`.

## What you can do

Connect this agent connector to let your agent:

- **Execute SQL** — run a SQL statement against Redshift via the Data API and get back a statement ID.
- **Fetch query results** — poll a statement and retrieve rows once it finishes.
- **Cancel a query** — stop a running statement by its statement ID.
- **Discover schema** — list schemas, list tables, and describe a table's columns and types.
- **Review query history** — list previously submitted statements for the AWS account.

## Execute tools

Use `execute_tool` / `executeTool` to run a named Redshift tool for a specific user. Scalekit selects the connected account from the user `identifier` plus the connection, or from a `connected_account_id`.

Redshift runs statements asynchronously: `redshift_execute_sql` returns a `statement_id`, and you poll `redshift_get_query_result` until the statement reaches a terminal state. Poll in a bounded loop and handle the `FAILED` and `ABORTED` states as errors so a stuck query can't loop forever.

  ### Node.js

```typescript
// Submit a SQL statement. Returns a statement ID you poll for results.
const submit = await scalekit.actions.executeTool({
  toolName: 'redshift_execute_sql',
  identifier: 'acme-org-id',
  connector: 'redshift',
  toolInput: { sql: 'SELECT count(*) FROM orders' },
});
const statementId = submit.data.statement_id;

// Poll until the statement reaches a terminal state, with a bounded number of attempts.
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));
let result;
for (let attempt = 0; attempt < 30; attempt++) {
  result = await scalekit.actions.executeTool({
    toolName: 'redshift_get_query_result',
    identifier: 'acme-org-id',
    connector: 'redshift',
    toolInput: { statement_id: statementId },
  });
  const status = result.data.status;
  if (status === 'FINISHED') break;
  // Treat FAILED and ABORTED as errors rather than retrying forever.
  if (status === 'FAILED' || status === 'ABORTED') {
    throw new Error(`Statement ${statementId} ended as ${status}`);
  }
  await sleep(1000); // still SUBMITTED / PICKED / STARTED — wait and re-check.
}
if (result.data.status !== 'FINISHED') {
  throw new Error(`Statement ${statementId} did not finish in time`);
}
console.log(result.data.rows); // [[12345]]
```

  ### Python

```python

# Submit a SQL statement. Returns a statement ID you poll for results.
submit = actions.execute_tool(
    tool_name="redshift_execute_sql",
    identifier="acme-org-id",
    connection_name="redshift",
    tool_input={"sql": "SELECT count(*) FROM orders"},
)
statement_id = submit.data["statement_id"]

# Poll until the statement reaches a terminal state, with a bounded number of attempts.
result = None
for _ in range(30):
    result = actions.execute_tool(
        tool_name="redshift_get_query_result",
        identifier="acme-org-id",
        connection_name="redshift",
        tool_input={"statement_id": statement_id},
    )
    status = result.data["status"]
    if status == "FINISHED":
        break
    # Treat FAILED and ABORTED as errors rather than retrying forever.
    if status in ("FAILED", "ABORTED"):
        raise RuntimeError(f"Statement {statement_id} ended as {status}")
    time.sleep(1)  # still SUBMITTED / PICKED / STARTED — wait and re-check.

if not result or result.data["status"] != "FINISHED":
    raise TimeoutError(f"Statement {statement_id} did not finish in time")
print(result.data["rows"])  # [[12345]]
```

## Troubleshoot common errors

| Error | Cause | Fix |
| --- | --- | --- |
| `InvalidIdentityToken` | AWS can't reach your Scalekit issuer URL (likely a `*.localhost` domain). | Use a publicly reachable Scalekit environment URL, such as your staging environment, as the issuer. |
| `Not authorized to perform sts:AssumeRoleWithWebIdentity` | The trust policy `aud` doesn't match the Scalekit Connection ID. | Verify `` in the trust policy matches the dashboard exactly. |
| `not authorized to perform: redshift-serverless:GetCredentials` | Permission policy is missing the serverless auth action or is scoped to the wrong workgroup. | Check the workgroup ARN in the policy — it must be exact, including the UUID. |
| `db_user is required for provisioned Redshift clusters` | Cluster identifier is set but `db_user` is empty on the connected account. | Add `db_user` matching the Redshift user you created in Part 2. |
| `must specify exactly one of cluster_identifier or workgroup_name` | Both fields are set, or neither is. | Edit the connected account so exactly one is populated. |
| `region is required` | `region` is missing or empty. | Set `region` on the connected account. |

### Verify the round-trip in CloudTrail

A tool call typically produces two kinds of CloudTrail events, though the exact event names and counts vary by which tool ran:

1. An `AssumeRoleWithWebIdentity` event (`eventSource: sts.amazonaws.com`) from a `userIdentity` of type `WebIdentityUser`, with your Scalekit environment as the issuer. This appears only when Scalekit exchanges credentials — a cached-credential call skips it.
2. A Redshift Data API event (`eventSource: redshift-data.amazonaws.com`, `eventName: ExecuteStatement` for a query, or the corresponding name for other tools) from the assumed role.

The `RoleSessionName` matches the connected account's identifier (sanitized — `+` becomes `-`, and so on), so CloudTrail attributes activity per organization out of the box.

## Reference

### JWT claims Scalekit mints

The JWT is signed with the active OIDC signing key of your Scalekit environment — the same key that signs your Scalekit OIDC tokens. Public keys are exposed at `https:///.well-known/jwks.json`.

| Claim | Value |
| --- | --- |
| `iss` | `https://` |
| `aud` | `` (for example `conn_128516460753453607`) |
| `sub` | The connected account's identifier |
| `exp` | Now + 5 minutes |
| `iat` | Now |
| `jti` | Random UUID |

### Trust policy claim names

AWS forms the condition keys from your OIDC provider URL hostname:

```text
:aud
:sub
```

There is **no `:iss` condition key**. AWS validates the issuer implicitly through the OIDC provider ARN in `Principal.Federated`.

### Where credentials live

No long-lived AWS credentials are ever stored. Temporary STS credentials are cached for about an hour and proactively refreshed by the connector's pre-run hook before expiry.

| Field | Where it's stored | Encrypted? |
| --- | --- | --- |
| `role_arn`, `region`, `database`, `cluster_identifier` / `workgroup_name` | `connected_account.api_config` | No (per-tenant target config) |
| `db_user` | `connected_account.authorization_details.trusted_idp` | Yes |
| Cached STS credentials (access key, secret, session token, expiry) | `connected_account.authorization_details.trusted_idp` | Yes |

### Refresh and rotation

- **STS credentials** — cached on the connected account and refreshed by a pre-run hook about 60 seconds before expiry. No customer action needed.
- **Scalekit JWT signing key** — rotates per your environment's signing-key policy. AWS picks up new keys automatically via JWKS. No customer action needed.
- **AWS IAM role** — rotate only if you change the role's permissions or want to revoke Scalekit's access.

### Revoke access

To block Scalekit from obtaining **new** credentials, do any one of the following:

- Delete the IAM role, or
- Remove the `Federated` principal from the trust policy, or
- Remove the OIDC provider entry in AWS IAM.

Any of these causes the next `AssumeRoleWithWebIdentity` call to fail with `AccessDenied`.

> caution: Blocking new sessions doesn't revoke active ones
>
> These changes stop future credential exchanges, but temporary credentials Scalekit already holds stay valid until they expire (up to about an hour). For an immediate cut-off, also revoke active sessions: attach AWS's [`AWSRevokeOlderSessions` deny policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) to the role (it denies all actions for sessions issued before a cutoff time), or delete the role, which invalidates its active sessions.

## Tool list

Use the exact tool names from the **Tool list** below when you call `execute_tool`. If you're not sure which name to use, list the tools available for the current user first.

## Tool list

### `redshift_cancel_query`

Cancel a running Amazon Redshift SQL statement using its statement ID.

Parameters:

- `statement_id` (`string`, required): The ID of the statement to cancel. Must be non-empty.

### `redshift_describe_table`

Describe the schema of a table in Amazon Redshift using the Redshift Data API, including column names, types, and metadata.

Parameters:

- `table` (`string`, required): Name of the table to describe. Must be non-empty.
- `connected_database` (`string`, optional): Override the connected account's default database for this request.
- `max_results` (`integer`, optional): Maximum number of columns to return per page.
- `next_token` (`string`, optional): Pagination cursor from a previous redshift_describe_table response.
- `schema` (`string`, optional): Schema name that contains the table.

### `redshift_execute_sql`

Execute a SQL statement against Amazon Redshift using the Redshift Data API. Returns a statement ID that can be used with redshift_get_query_result to fetch results.

Parameters:

- `sql` (`string`, required): SQL statement to execute. Must be non-empty.
- `statement_name` (`string`, optional): Optional label for the statement, echoed back by DescribeStatement for tracking purposes.
- `with_event` (`boolean`, optional): If true, AWS publishes an EventBridge event when the statement completes.

### `redshift_get_query_result`

Retrieve the results of a previously executed Redshift SQL statement using the statement ID returned by redshift_execute_sql. Supports pagination via next_token.

Parameters:

- `statement_id` (`string`, required): The statement ID returned by redshift_execute_sql. Must be non-empty.
- `next_token` (`string`, optional): Pagination token from a prior redshift_get_query_result response when results spanned multiple pages.

### `redshift_list_schemas`

List schemas in an Amazon Redshift database using the Redshift Data API. Supports filtering by schema name pattern with pagination.

Parameters:

- `connected_database` (`string`, optional): Override the connected account's default database for this request.
- `max_results` (`integer`, optional): Maximum number of schemas to return.
- `next_token` (`string`, optional): Pagination cursor from a previous redshift_list_schemas response.
- `schema_pattern` (`string`, optional): LIKE pattern to filter schemas (e.g., public, my_schema%).

### `redshift_list_statements`

List previously executed SQL statements in Amazon Redshift using the Redshift Data API. Supports filtering by name, status, and role level with pagination.

Parameters:

- `max_results` (`integer`, optional): Maximum number of statements to return.
- `next_token` (`string`, optional): Pagination cursor from a previous redshift_list_statements response.
- `role_level` (`boolean`, optional): When true, lists all statements run by the IAM role rather than just the current session.
- `statement_name` (`string`, optional): Filter statements by name label.
- `status` (`string`, optional): Filter by execution status (e.g., FINISHED, FAILED, ABORTED, PICKED, STARTED, SUBMITTED).

### `redshift_list_tables`

List tables in an Amazon Redshift database using the Redshift Data API. Supports filtering by schema and table name patterns with pagination.

Parameters:

- `connected_database` (`string`, optional): Override the connected account's default database for this request.
- `max_results` (`integer`, optional): Maximum number of tables to return.
- `next_token` (`string`, optional): Pagination cursor from a previous redshift_list_tables response.
- `schema_pattern` (`string`, optional): LIKE pattern to filter schemas (e.g., public, my_schema%).
- `table_pattern` (`string`, optional): LIKE pattern to filter tables (e.g., orders, user%).


---

## More Scalekit documentation

| Resource | What it contains | When to use it |
|----------|-----------------|----------------|
| [/llms.txt](/llms.txt) | Structured index with routing hints per product area | Start here — find which documentation set covers your topic before loading full content |
| [/llms-full.txt](/llms-full.txt) | Complete documentation for all Scalekit products in one file | Use when you need exhaustive context across multiple products or when the topic spans several areas |
| [sitemap-0.xml](https://docs.scalekit.com/sitemap-0.xml) | Full URL list of every documentation page | Use to discover specific page URLs you can fetch for targeted, page-level answers |