This document is intended for the partner's technical specialists (backend / platform / integrations).

The goal is to guide you step-by-step from obtaining access to full Go-Live, including mandatory testing in Sandbox.

0. What you'll need before starting

Before beginning integration, make sure you have:

a backend service that can:

execute HTTP(S) requests

generate JWT (RS256)

receive incoming webhooks

cryptography:

RSA key pair (for JWT signing)

JWE support (RSA-OAEP + AES-GCM)

understanding of:

how you identify users

what data relates to KYC / KYB

1. Obtaining access and keys

After RemiDe onboarding, you receive:

partnerId

partnerSigningKeyKid

your partnerPrivateKey

RemiDe public key (remidePublicKey) — for JWE

Base URLs:

Core API

Sandbox API

It's recommended to set up two environments immediately:

sandbox

production

2. Checking API availability (Health)

Start by checking service availability.

GET /health

Expected result:

HTTP 200

If the health check fails — further steps cannot be performed.

3. Partner authentication (JWT, RS256)

All requests to the Core API must be signed with JWT.

3.1 Generating JWT

JWT:

algorithm: RS256

signed with partnerPrivateKey

contains standard claims (iss, sub, aud, exp)

header must include kid = partnerSigningKeyKid

3.2 Using JWT in requests

Authorization: Bearer <jwt>
Content-Type: application/json

3.3 Verification request

GET /partners/balance

Expected result:

HTTP 200

partner balance

Common errors:

incorrect kid

expired exp

time synchronization issue

4. User model integration

RemiDe works with users that you create and update.

4.1 User identifiers

For each user, the following must be defined:

uid — your internal ID

tag — external identifier (email / reference)

type: individual | business

blockchain context:

network

address

4.2 Bulk upsert users

POST /users

Recommendations:

use upsert

consider the request idempotent

store mapping uid ↔ remideUserId

4.3 Verification

GET /users/:tag

5. Encrypting sensitive data (JWE)

Sensitive data is never transmitted in plain text.

5.1 What gets encrypted

KYC / KYB → encryptedKycKybData

user transfer data → userData

5.2 How to encrypt

format: JWE

encrypt with remidePublicKey

result — compact JWE string

5.3 Where it's used

POST /users

POST /transfers

6. Webhooks

Webhooks are the main mechanism for asynchronous statuses.

6.1 Setting webhook URL

PATCH /partners/webhook

Webhook endpoint must:

respond within ≤ 5 seconds

return 2xx on successful processing

be idempotent

6.2 Signature verification

Each webhook contains:

X-Signature

X-Timestamp

Signature verification is mandatory.

6.3 Obtaining RemiDe signing keys

GET /partners/:partnerId/remide-signing-keys

7. Creating transfers

7.1 Initiating a transfer

POST /transfers

You specify:

user

amount and currency

network and address

if needed — userData (JWE)

In response:

transferId

initial status

7.2 Status tracking

GET /transfers/:id

Or via webhooks (recommended).

8. Linking on-chain transaction

After receiving txHash:

POST /transactions

Links:

transferId ↔ txHash

9. Sandbox — mandatory stage

Sandbox is an isolated environment for testing complete E2E without real money.

Sandbox allows you to:

simulate KYC / balance / chain

manage scenarios

test webhook delivery and replay

9.1 Sandbox Banks

Emulation of banks / payment providers.

POST /sandbox/banks
GET  /sandbox/banks
PATCH /sandbox/banks/:bankId
POST  /sandbox/banks/:bankId/reset

9.2 Sandbox Flows

Flow is a step-by-step business process scenario.

Starting a flow

POST /sandbox/flows/start

Execution

POST /sandbox/flows/:runId/run
POST /sandbox/flows/:runId/step

Inspection and export

GET /sandbox/flows/:runId/inspect
GET /sandbox/flows/:runId/export

9.3 Sandbox Sim (Admin)

Manual state simulation.

POST /sandbox/sim/balance
POST /sandbox/sim/kyc
POST /sandbox/sim/chain

Used for:

approve / reject KYC

changing balance

generating on-chain events

9.4 Sandbox Webhooks

Forced sending

POST /sandbox/webhooks/send

Delivery history

GET /sandbox/webhooks/deliveries

Replay

POST /sandbox/webhooks/deliveries/:deliveryId/replay

9.5 Recommended Sandbox E2E scenario

Create sandbox bank

Start flow

Create user (Core API)

Simulate KYC approve

Set balance

Create transfer

Simulate on-chain event

Receive webhook transfer_completed

Replay webhook

10. Go-Live preparation

Before production:

JWT and JWE are covered with tests

webhooks:

are validated

are idempotent

are logged

monitoring and alerts are in place

key rotation process is defined

11. Common mistakes

testing only happy-path

no webhook replay

lack of idempotency

sandbox hack in production code

Summary

Sandbox is a mandatory part of integration.

Integration is considered ready when the scenario user → transfer → tx → completed consistently passes in Sandbox and production-ready environment.

Ready to talk?

Book a consultation to discuss how Stablecoin Clearing fits your needs.
Book Discovery Call

Questions? Reach out to Anton | CEO @ RemiDe
anton@remide.xyz

RemiDe API

0. What you'll need before starting#

1. Obtaining access and keys#

2. Checking API availability (Health)#

3. Partner authentication (JWT, RS256)#

3.1 Generating JWT#

3.2 Using JWT in requests#

3.3 Verification request#

4. User model integration#

4.1 User identifiers#

4.2 Bulk upsert users#

4.3 Verification#

5. Encrypting sensitive data (JWE)#

5.1 What gets encrypted#

5.2 How to encrypt#

5.3 Where it's used#

6. Webhooks#

6.1 Setting webhook URL#

6.2 Signature verification#

6.3 Obtaining RemiDe signing keys#

7. Creating transfers#

7.1 Initiating a transfer#

7.2 Status tracking#

8. Linking on-chain transaction#

9. Sandbox — mandatory stage#

9.1 Sandbox Banks#

9.2 Sandbox Flows#

Starting a flow#

Execution#

Inspection and export#

9.3 Sandbox Sim (Admin)#

9.4 Sandbox Webhooks#

Forced sending#

Delivery history#

Replay#

9.5 Recommended Sandbox E2E scenario#

10. Go-Live preparation#

11. Common mistakes#

Summary#

Ready to talk?#