Testing in Postman

​

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

• 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)

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

• 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

• 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

• 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

• See: Compliance & Certification 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.