Skip to main content

Before you start

A pledge is created on the customer’s behalf, so you need a customer scoped OAuth2 access token before you touch any pledge endpoint. If you already have one and it still carries the pledge scopes you need, skip to step 1. Getting that token means walking through the OAuth2 authorization code flow once. Here’s the brief version of what you’re doing and where to go for each part: 1. Generate PKCE values. Your backend creates a fresh code_verifier, its derived code_challenge, and a CSRF state value for this specific authorization attempt. Never reuse these across attempts.
Full detail on why PKCE matters is in Security best practices. 2. Send the customer to authorize your app. Build the authorization URL with your client_id, redirect_uri, the pledge scopes you need, and the code_challenge and state from step 1. The customer logs in and consents on Busha’s own screen, then gets redirected back to you with a code. See Quick start: Step 2 for the exact URL shape. 3. Exchange the code for tokens. Your backend swaps the code for an access_token and refresh_token, using the code_verifier from step 1. See Quick start: Step 4. 4. Check the token has the pledge scopes you need. The response’s scope field lists what was actually granted. If pledges:liquidate isn’t there and you’ll need it later, request it now rather than re running this whole flow later, see Scopes. Don’t have an OAuth2 app yet, or need your client_id/client_secret? Start at Get access.
Codes are single use and expire in 10 minutes. Access tokens expire in about an hour, refresh tokens rotate on every use. If a pledge request suddenly returns 401, refresh rather than restarting the whole flow, see Token handling.

1. Create a pledge quote

Before locking anything, preflight the request. This confirms the customer’s assets are available to lock without moving funds.
Check can_create and each item’s can_lock before proceeding. A false value means that asset can’t currently be locked for this customer.

2. Create the pledge

Using the quote’s id, lock the assets.
The customer’s USDT is now locked. Save the pledge id, you’ll need it for every subsequent call.
Activate the pledge immediately after creating it. The pledge inherits its quote’s expires_at, and activate will reject once that window closes.

3. Activate the pledge

Once you’ve disbursed the credit to the customer, confirm the agreement is live.

4. Add pledge items

Grow a pledge into a multi asset pledge, or add more of an asset already on the pledge.

5. Release collateral as the customer repays

Each time the customer makes a repayment, release the corresponding share of collateral. Set full_release: true once the agreement is fully repaid.

6. List and get pledges

Use GET /v1/pledges/{id} when you need the full items array. GET /v1/pledges (list) is best for browsing and filtering across many pledges.

7. Request and cancel liquidation

If the customer defaults, request liquidation. This requires the pledges:liquidate scope, requested separately from pledges:write and pledges:read at authorization time.
The liquidation does not execute immediately. It sits in pending_execution until execute_after, giving the customer time to resolve the default.

Errors

Pledge endpoints return the standard Busha error envelope. See OAuth2 Errors for authorization layer failures like invalid_grant or insufficient_scope.