# Integration models

This is continued from the previous page.


  • Once you integrate Credify as Market, you can provide users on your platform with diverse services without extra efforts.
  • Once you integrate Credify as Service Provider, you can approach your potential users on a lot of platforms without extra efforts.

You need to do the following for the integration

  • Backend integration
    • (Service Provider) To make several API endpoints
    • (Market who provide custom data) To make several API endpoints
  • Frontend integration
    • (Market only) To install our frontend SDK into your frontend (Android, iOS, and/or web).


If you are Market and will not provide any data, then you can skip this backend integration.

# Backend integration

The goal of the backend integration is to build API endpoints we need for serviceX.

For Service Provider

  • Redirection URLs
    • The URLs that will be used once users complete OIDC flow.
  • Logout URLs
    • The URLs that will be used when users log out.
  • OIDC setup URL
    • The URL required to kick off OIDC with Credify. This may generate an ephemeral encryption key to securely deal with claims.
  • [Deprecated] User existence API endpoint
    • Please provide it as empty.

For Market

  • User counts API endpoint
    • This is used when Service Providers create a new offer
    • If you don't provide any data, then this endpoint is not necessary
  • Offer evaluation API endpoint
    • This is used when end-users make a consent for data sharing
    • If you don't provide any data, then this endpoint is not necessary
  • Encryption claims API endpoint
    • This is used for e2e encryption when Service Providers access the data from Market systems
    • If you don't provide any data, then this endpoint is not necessary
  • Offer filtering API endpoint
    • This is used when frontend serviceX SDK fetches available offers
    • If you don't provide any data, then this endpoint is not necessary

These API endpoints need to be registered on Dashboard, thus please update your organization information on Dashboard once you deploy the API.


We are in migration to remove this explicit endpoint registration. If you are going to use BNPL on your platform, you will need to provide an API base URL as well. You will need to provide the API base URL, and we will add a suffix to point to each endpoint.

We have 3 approaches to complete the backend integration.

Approaches Characteristics Pros Cons
SDK model We develop SDK (API wrapper with some functionalities) and our partner develops the rest Flexible Much development effort
Skeleton model We create boilerplate implementation to minimize the partner's development workload Minimal development effort Not flexible about deployment strategy
Adaptor model Our partner provides us with their API for us to connect their system We can leverage existing systems Available only if our partner has API

# SDK model

SDK model

In this approach, you will have much flexibility but involve much development workload. Skeleton model has encapsulated common business logic already, so if you do not have specific requirements, using Skeleton model instead of this SDK model will be easier and simpler.

We support the following platforms:

# Skeleton model

Skeleton model

We have implemented most of the logic using our SDK for the easier integration work, thus this approach is our recommendation. This is called Skeleton service. We have Node.js, Java, and .NET Skeleton service. The detail flow is described in the Skeleton repositories.

What We need you to do is

  1. Clone the project
  2. Complete the implementation following the comments in the repository
  3. Deploy the server
  4. Update the domain and path on serviceX Dashboard
  5. Move to integration test (we will support this step)

Only Node.js Market Skeleton is public as of July 2022.

# Adaptor model

Adaptor model

Some partners have implemented API for external clients already. In this case, we will make most of it by writing the Adaptor service. If you have your API in place, all you have to do is 1. Give us your API access, 2. Host the adaptor service in your infrastructure. In other words, we will do the actual development using your API, and yet we will have you host the adaptor service to ensure we have no access to the data you obtain through serviceX.

The detailed information about the API specs are here

# Frontend integration

# Service Provider

If you are Service Provider, all you are required to do in terms of frontend is to handle OIDC callback for user onboarding. This depends on your business requirements of your onboarding process.

This OIDC callback should be implemented on web frontend. You can reference the sample implementation in the Skeleton service described above.

# Market

Market will have more work for the frontend integration. If you would like to present serviceX flow on both mobile and web, you will need to install our frontend SDK on each platform.

We support Android (Kotlin), iOS (Swift), React Native, and Web.

Our frontend SDK allows you to

  • fetch available offers for users on your platform
  • render the serviceX flow and let users enjoy specified products
  • get notified of the result of the serviceX flow

serviceX will handle all the interaction with Service Provider. You don't have to worry about the API of the Service Providers. You can simply embed our SDK into your app and customize the theme to fit your app. Please follow README in each repository.

# Integration test

Since serviceX needs 2 sides (Service Provider & Market), you will need to have the other side for testing. Our support team will configure the counterparty demo organization account for your integration test. Besides, we have developed a simple testing tool with Cypress, so we will give you access to this tool.

Last Updated: 9/15/2022, 4:28:07 AM