SahamatiNet
  • Background
  • SahamatiNet POC
    • Introduction
    • Applications
    • Observability
    • Integration Steps
      • Sandbox Onboarding
      • IAM APIs
      • CR APIs
      • Integration with Router
        • Sample Code Snippets
          • Python
          • Java
          • JavaScript
          • GoLang
          • C#
        • Router APIs Specifications
          • FIU API Specification
          • AA API Specification
          • FIP API Specification
      • ReBIT Workflows using Router
        • Account Discovery & Linking
        • Consent Workflow
        • FI Request Workflow
    • Integration with Simulators
      • AA Simulator
      • FIP Simulator
      • FIU Simulator
    • Validation of Integration
  • Glossary
  • Guidelines
  • Frequently Asked Questions
  • How To Guides
    • How To Onboard to Sandbox ?
    • How To Decide on an Entity ID ?
    • How To Generate a Certificate ?
    • How To Generate Tokens ?
Powered by GitBook
LogoLogo

Copyright © 2025 - Sahamati Foundation

On this page
  • Overview
  • OTP Scenario:

Was this helpful?

Export as PDF
  1. SahamatiNet POC

Integration with Simulators

PreviousFI Request WorkflowNextAA Simulator

Was this helpful?

Overview

SahamatiNet has developed Response Simulators for each type of entity in the AA ecosystem. These simulators replicate the behaviour of AA, FIU, or FIP while interacting with ReBIT APIs for Router integration, enabling seamless testing and validation.

By mimicking real Entity Protocol APIs, the Response Simulator provides a controlled environment where developers can test the router service independently without relying on a live entity.

The sample workflow diagram below illustrates the usage of the Response Simulator by including a simulated response with the expected response.

The following two details are required in the request to use the APIs with Response Simulator:

  • recipient-id: This is specified in the x-request-meta header through which the router that will route the request to the respective response simulator.

    • Based on the respective use case you can use the following Entity ID as recipient-id, which are mapped to the respective Response Simulators in Sandbox environment,

      • AA-SIMULATOR

      • FIU-SIMULATOR and

      • FIP-SIMULATOR

  • x-simulate-res: This header should contain a hint for the expected response from the response simulator. It can be any of the options listed in the specific entity tables. If this is not included, the response simulator will default to returning a 200 OK response.

Sample Request Headers:

x-request-meta: [Base64 of {"recipient-id": "AA-SIMULATOR"}]
x-simulate-res: DataGone

OTP Scenario:

The FIP's Accounts/link/verify API is the only one that utilizes the OTP received from the customer. This API is responsible for submitting the token/OTP back to the FIP to complete the account linkage process. The Response Simulator is set up to accept a predefined list of OTPs for successful account linkage. If an OTP outside of this list is used, the account linkage will fail. This is the default behavior of the Response Simulator, functioning without the need for the x-simulate-res header.

List of OTPs accepted by Response Simulator

1234

123456

654321

999999

223344

567890

456789

234567

345678

555444

222333

The sample workflow diagram below illustrates the usage of the valid OTP

The sample workflow diagram below illustrates the usage of the invalid OTP

Entity Integration with Router using "Response Simulator"