Integration Overview

At a high-level, integration with the AUTH product follows these steps:

1. Configuration of platform & product, including retrieval of API key
2. Authentication to retrieve client access token
3. Instantiation of an AUTH-compatible zerohash SDK, such as the Account Funding SDK
4. Consumption of webhook events for transactional statuses & alerts

Pre-requisities & Setup

Configure Platform

Follow the steps in the Get Platform Access guide to receive your credentials.

Configure AUTH

Your zerohash team can configure your Platform with the following settings:

1. Supported assets: See supported assets here

2. Transfer methods: There are three categories of transfer methods to choose from within the AUTH network.

   • Custodial wallets
   • Non-custodial Wallets
   • Manual Transfers

3. public_key: A public key from a cryptographic key-pair is required for use in signature validation of API requests.

4. Asset precision by network

   By default, AUTH accepts transfer amounts at the full on-chain precision of the source asset (up to 18 decimal places for chains like Ethereum). If your platform's ledger, CLOB, or downstream accounting system supports fewer decimal places, this can result in sub-precision "dust" amounts on your side with no clean place to land.

   You can configure a maximum decimal precision per asset and network. Any AUTH deposit or withdrawal submitted with more decimal places than the configured value is rejected with a 400 — the transfer is not silently truncated.

   Why you might want this:

   • Match AUTH transfer precision to your internal ledger's precision, avoiding dust and reconciliation gaps

   • Enforce a tighter precision ceiling than the asset's native chain precision (e.g. cap ETH at 8 decimals when your ledger only tracks 8)

   1. Set different precision rules per asset — the configuration is per asset and network

5. Per-participant exchange visibility (production QA)

   When you want to validate a new AUTH integration in production before making it available to all of your users, you can restrict the exchange to a defined list of your participant codes. Only those participants will see the exchange in the AUTH Partner menu; every other participant on your platform will not see it.

   Why you might want this:

   • Run end-to-end production tests against a new exchange with your QA participants before general availability
   • Progressively roll out a new exchange to specific user cohorts
   • Restrict a exchange for internal risk or compliance reasons

   How it works:

   You provide zerohash with the exchange and the list of participant codes that should retain access. Participants on the list see the exchange; all other participants do not. Once you're ready to make the exchange generally available, the restriction is removed and all participants see the exchange in their menu.

6. Transaction limits

   The AUTH configuration system is flexible and can accommodate many types of limit configurations. Notably, here are the most common:

   • Maximum and Minimum per-transaction limits: Define the smallest and largest allowable amounts (denominated in fiat) for a single transaction. AUTH will enforce these limits for each individual transaction request.
   • Maximum daily limits: Set a cap on the total transaction volume allowed per user within a 24-hour period. This helps manage risk and comply with regulatory or internal policy requirements.

Configure Webhooks

Provide zerohash with the callback URL that Auth will emit event updates to. You can review webhook documentation along with supported event domains here including specific events related to Deposits & Withdrawals webhook statuses.

Authentication

Authentication can be obtained to initialize a flow with AUTH SDK begins with Generate a client access token. This request requires a participant_code from a successfully onboarded customer before the token can be minted. You can review our Onboarding solutions here.

Additionally, all API calls require HMAC signing as described in our API Authentication overview.

Integrating with Auth

Once Auth has been configured for your platform and desired product, you can use the existing integration guides.

The web SDKs that currently support AUTH are:

1. Fund SDK - Integration Guide
2. Fund Withdrawals SDK - Integration Guide
3. Crypto Deposits SDK - Integration Guide
4. Crypto Withdarwals SDK - Integration Guide

To enable AUTH on mobile, reference our native iOS and Android SDK guides.

Note: usage of our native iOS and Android SDKs is required for access to all AUTH features in mobile.

Webhooks Reference

Webhooks for the AUTH-supported products can be found here, or in the Webhooks Overview section.

1. Account Funding Webhooks
2. Deposit Webhooks
3. Withdrawal Webhooks

Both AUTH and standard Deposits/Withdrawal webhooks are triggered for a given transaction. Certain attributes, such as integration information, will only exist on the webhook events in the AUTH domain. It is advised to listen to both Deposits/Withdrawal webhooks as well as AUTH to discern which customers are using which flows, and to capture the richest detail about the user journey.

Here is a comparison table between the AUTH and Deposit domains: