# Integration guide

This is continued from the previous page.

TIP

  • 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
    • To make several API endpoints
  • Frontend integration
    • (Market only) To install our frontend SDK into your frontend (Android, iOS, and/or web).

# 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
  • Offer evaluation API endpoint
    • This is used when end-users make a consent for data sharing
  • Encryption claims API endpoint
    • This is used for e2e encryption when Service Providers access the data from Market systems
  • Offer filtering API endpoint
    • This is used when frontend serviceX SDK fetches available offers

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


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)

The repositories are not public as of May 2022. Please let us know if you need access.

# 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: 5/5/2022, 5:29:54 AM