> ## Documentation Index
> Fetch the complete documentation index at: https://holder.docs.fiskil.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Testing in Postman

> Validate your integration end‑to‑end using our Postman collection, your mock users, and Request Logs.

This guide shows how to test your Data Provider integration **end‑to‑end** using **Postman**. You will initiate a hosted consent flow, obtain tokens, and call your Resource Server endpoints. You’ll also learn how to verify results in **Request Logs** and where to find additional tools for regulated profiles (e.g., CDR).

***

## Overview

* **Primary tool**: Postman collection provided by Fiskil
* **What you’ll test**: consent → token → Resource Server calls
* **What you provide**: mock users, accounts, and sample data in your own systems
* **Validation**: use Console → Request Logs to confirm success and investigate errors

***

## Prerequisites

* A **staging** instance configured in the Console
* Your **Resource Server** live on a public HTTPS URL
* Required endpoints implemented:
  * `GET /v1/auth/customer/search`
  * `GET /v1/auth/customer/{customerId}/accounts`
  * `GET /v1/auth/customer/{customerId}`
  * At least one data endpoint (e.g., `GET /v1/customer/{customerId}/accounts/{accountId}/balances`)
* Access to the **Authorization** and **Token** endpoints, and **JWKS URL**
  *(All available in Console → **Settings → Domains**.)*

> We recommend setting up several **mock users** and **mock accounts** in your systems to test a range of scenarios (single vs joint accounts, different account types, low/no data cases, etc.).

***

## Get the Postman Collection

1. Download the Fiskil **Postman collection** and **environment** (link provided in Console or by your Fiskil contact).
2. Import both into Postman.
3. Open the environment and populate variables (see next section).

***

## Configure Postman Environment

Set the following variables in your Postman **environment**:

* `base_url` — Your Data Provider staging environment base URL
* `jwks_url` — As shown in Console → **Settings → Domains**
* `client_id` — Provided during onboarding (or created in Console)
* `client_secret` — Provided during onboarding (or created in Console)
* `scopes` — Space-delimited list (e.g., `accounts.read balances.read`)

> All domain and endpoint values are available in the Console under **Settings → Domains** or **Settings → Resource Server**.

***

## Authorize and Obtain a Token (Postman)

Use Postman’s built‑in OAuth 2.0 flow:

1. In the collection, open **Authorization** on a request that uses OAuth 2.0.
2. Set:
   * **Auth URL**: `{{base_url}}/connect/authorize`
   * **Access Token URL**: `{{base_url}}/connect/token`
   * **Client ID**: `{{client_id}}`
   * **Client Secret**: `{{client_secret}}` (if applicable)
   * **Scopes**: `{{scopes}}`
   * **Grant Type**: Authorization Code (PKCE if required)
3. Click **Get New Access Token**.
4. Complete the **hosted consent screen** (Fiskil) as the test user.
5. Postman will exchange the code and store the **access token**.
6. Click **Use Token** to attach it to subsequent requests.

***

## Call Your Resource Server Endpoints

With the token set in Postman, you can fetch some data:

* `GET {{base_url}}/api/v1/accounts/{{account_id}}/balances`
* Expect balance data scoped by the consent.

> Ensure your Resource Server validates the JWT (signature, `exp`, `iss/sub`, `aud`, `jti`).

***

## Use Request Logs for Validation

Open **Console → Request Logs** to verify:

* **Successful calls** (200s) to your endpoints after consent
* **Scopes** attached to the token and used in each request
* **Error responses** (401/403) when scopes are missing or tokens are invalid/expired
* **Payload inspection** for troubleshooting

***

## Creating Mock Users and Data

You own the user and account data surfaced by your Resource Server. For robust testing:

* Create **multiple test users** that reflect realistic personas:
  * Single user with one account
  * User with multiple accounts of different types
  * Joint/organization accounts (if supported)
* Seed **edge cases**:
  * Empty datasets (no transactions yet)
  * Restricted scopes (e.g., balances only)
  * Large pagination cases
* Keep a mapping of test users → accounts → expected results to speed up test review.

***

## Common Errors

* **401 Unauthorized** — Missing or invalid token. Validate signature and token lifetime.
* **400/422** — Request validation errors (missing params, malformed IDs).
* **429** — Rate limits (if configured).
* **5xx** — Upstream or Resource Server errors.

***

## Running the Collection as a Suite

* Use a **Collection Runner** with a data file (CSV/JSON) of test users/accounts.
* Add **pre‑request scripts** to inject account IDs from prior responses.
* Add **tests** in Postman (e.g., `pm.expect(response.code).to.eql(200)`) to assert status codes and shapes.

***

## Additional Tools for Regulated Profiles

If you are implementing a **Compliance Profile** (e.g., **CDR**), additional test tools and checklists are available.

* See: [Compliance & Certification Tools](/docs/testing/compliance-tools)

> These tools complement the Postman collection with profile‑specific validation, payload rules, and certification workflows.

***

## Next Steps

* Review **Authentication** to confirm JWT validation and JWKS usage.
* Confirm **Consent** lifecycle and hosted screens.
* Build out additional **Resource Server** endpoints and scopes.
* Monitor **Request Logs** during ongoing development and before go‑live.