Filtering & Parameters

Overview

The Activity API provides flexible filtering capabilities to help you retrieve specific subsets of transaction data. Filters can be combined to create precise queries.

Available Filters

Status Filtering

Filter transactions by their current status using the statuses query parameter.

statuses

string[]

Filter by transaction status. Can be provided multiple times to include multiple statuses.

Available Status Values

ACTIVE

status

Transactions that are currently in progress or open positions.Examples:

Active staking positions
Open loan positions
Pending withdrawals
Unfilled or partially filled trade orders

COMPLETED

status

Transactions that have been successfully completed and closed.Examples:

Completed deposits
Executed trades
Closed staking positions
Fully repaid loans

CANCELED

status

Transactions that were canceled before completion.Examples:

Rejected withdrawal requests
Canceled trade orders
Declined admin approvals

Status Filter Examples

Single Status

GET /activity?statuses=COMPLETED

Multiple Statuses

GET /activity?statuses=ACTIVE&statuses=COMPLETED

All Non-Canceled Transactions

GET /activity?statuses=ACTIVE&statuses=COMPLETED

Transaction Type Filtering

Filter by transaction type using the fullTypes query parameter. Use the % wildcard to match all subtypes.

fullTypes

string[]

Filter by transaction type and subtype. The % wildcard matches all variations of a type.

Available Transaction Types

DEPOSIT%

transaction type

All deposit transactions.Subtypes:

DEPOSIT.ADMIN - Admin-approved deposits
DEPOSIT.CRYPTO - Blockchain deposits

Use Case: Track all incoming funds to user accounts.

WITHDRAWAL%

transaction type

All withdrawal transactions.Subtypes:

WITHDRAWAL.ADMIN - Admin-approved withdrawals
WITHDRAWAL.CRYPTO - Blockchain withdrawals

Use Case: Monitor outgoing funds and withdrawal requests.

STAKING%

transaction type

All staking operations.Full Type: STAKINGUse Case: View all staking positions including fixed and flexible staking.

TRADE%

transaction type

All trading operations.Subtypes:

TRADE.CONVERSION - Currency swaps/conversions
TRADE - Other trading activity

Use Case: Analyze trading history and executed orders.

TRADE.CONVERSION%

transaction type

Specifically currency conversion/swap operations.Use Case: Track currency exchanges separate from other trading activity.

LOAN%

transaction type

All loan-related operations.Full Type: LOANUse Case: Monitor borrowing activity and loan positions.

TRANSFER%

transaction type

Internal platform transfers between users.Full Type: TRANSFERUse Case: Track peer-to-peer transfers within the platform.

Transaction Type Filter Examples

Single Type

GET /activity?fullTypes=STAKING%

Multiple Types

GET /activity?fullTypes=DEPOSIT%&fullTypes=WITHDRAWAL%

Specific Subtype

GET /activity?fullTypes=TRADE.CONVERSION%

All Financial Activity (Excluding Staking/Loans)

GET /activity?fullTypes=DEPOSIT%&fullTypes=WITHDRAWAL%&fullTypes=TRADE%

Combining Filters

You can combine status and type filters to create very specific queries.

Active Staking Positions

GET /activity?statuses=ACTIVE&fullTypes=STAKING%

Completed Deposits and Withdrawals

GET /activity?statuses=COMPLETED&fullTypes=DEPOSIT%&fullTypes=WITHDRAWAL%

Active and Completed Trades

GET /activity?statuses=ACTIVE&statuses=COMPLETED&fullTypes=TRADE%

Canceled Withdrawals Only

GET /activity?statuses=CANCELED&fullTypes=WITHDRAWAL%

Pagination Parameters

page

number

default:"1"

required

The page number to retrieve. Pages are 1-indexed.Constraints:

Minimum value: 1
No maximum (continues until no more results)

size

number

default:"10"

Number of transactions to return per page.Constraints:

Default: 10
Maximum: 10 (enforced by the API)

Currently, the API enforces a maximum page size of 10 transactions per request.

Pagination Examples

First Page (Default)

GET /activity?page=1

Second Page

GET /activity?page=2

Third Page with Filters

GET /activity?page=3&statuses=COMPLETED&fullTypes=TRADE%

Filter Behavior

Default Behavior

When no filters are provided:

GET /activity?page=1

Returns all transaction types
Returns all statuses (ACTIVE, COMPLETED, CANCELED)
Returns the first 10 transactions
Ordered by openedAt timestamp (newest first)

Multiple Values (OR Logic)

When you provide multiple values for the same parameter, they are combined with OR logic:

GET /activity?statuses=ACTIVE&statuses=COMPLETED

Returns: Transactions that are ACTIVE OR COMPLETED (excludes CANCELED)

GET /activity?fullTypes=DEPOSIT%&fullTypes=WITHDRAWAL%

Returns: DEPOSIT transactions OR WITHDRAWAL transactions

Multiple Parameters (AND Logic)

When you provide different parameters, they are combined with AND logic:

GET /activity?statuses=COMPLETED&fullTypes=DEPOSIT%

Returns: Transactions that are COMPLETED AND are DEPOSIT type

Common Filter Patterns

Portfolio Monitoring

View all current active positions:

GET /activity?statuses=ACTIVE&fullTypes=STAKING%&fullTypes=LOAN%

Audit Trail

View all completed financial transactions:

GET /activity?statuses=COMPLETED&fullTypes=DEPOSIT%&fullTypes=WITHDRAWAL%

Trading History

View all completed trades:

GET /activity?statuses=COMPLETED&fullTypes=TRADE%

Pending Actions

View transactions requiring attention:

GET /activity?statuses=ACTIVE&fullTypes=WITHDRAWAL%

Failed Transactions

View all canceled transactions:

GET /activity?statuses=CANCELED

Implementation Best Practices

Use specific filters to reduce payload size and improve performance. Only fetch the data you need.

Wildcard matching with % is required for the fullTypes parameter. Omitting it will result in no matches.

Correct: fullTypes=DEPOSIT%
Incorrect: fullTypes=DEPOSIT

URL Encoding: The % character in query parameters must be URL-encoded as %25 in some HTTP clients.Example: fullTypes=DEPOSIT%25 instead of fullTypes=DEPOSIT%

Client-Side Implementation

JavaScript/TypeScript Example

// Building filter URLs with multiple parameters
const buildActivityUrl = (filters: {
  page?: number;
  statuses?: string[];
  types?: string[];
}) => {
  const params = new URLSearchParams();
  
  // Add page
  params.append('page', (filters.page || 1).toString());
  params.append('size', '10');
  
  // Add status filters
  filters.statuses?.forEach(status => {
    params.append('statuses', status);
  });
  
  // Add type filters (% is automatically encoded)
  filters.types?.forEach(type => {
    params.append('fullTypes', `${type}%`);
  });
  
  return `/activity?${params.toString()}`;
};

// Usage examples
const activeStaking = buildActivityUrl({
  statuses: ['ACTIVE'],
  types: ['STAKING']
});
// Result: /activity?page=1&size=10&statuses=ACTIVE&fullTypes=STAKING%25

const completedTrades = buildActivityUrl({
  page: 2,
  statuses: ['COMPLETED'],
  types: ['TRADE']
});
// Result: /activity?page=2&size=10&statuses=COMPLETED&fullTypes=TRADE%25

Python Example

from urllib.parse import urlencode, quote

def build_activity_url(page=1, statuses=None, types=None):
    params = [
        ('page', str(page)),
        ('size', '10')
    ]
    
    # Add status filters
    if statuses:
        for status in statuses:
            params.append(('statuses', status))
    
    # Add type filters
    if types:
        for tx_type in types:
            params.append(('fullTypes', f'{tx_type}%'))
    
    return f'/activity?{urlencode(params)}'

# Usage examples
active_staking = build_activity_url(
    statuses=['ACTIVE'],
    types=['STAKING']
)
# Result: /activity?page=1&size=10&statuses=ACTIVE&fullTypes=STAKING%25

completed_deposits = build_activity_url(
    page=3,
    statuses=['COMPLETED'],
    types=['DEPOSIT', 'WITHDRAWAL']
)
# Result: /activity?page=3&size=10&statuses=COMPLETED&fullTypes=DEPOSIT%25&fullTypes=WITHDRAWAL%25

Filter Response Validation

Empty Results

If no transactions match your filters, the API returns an empty array:

{
  "data": [],
  "status": 200
}

This is a valid response, not an error. It means no transactions match your filter criteria.

Invalid Filter Values

If you provide invalid filter values, the API may:

Ignore invalid values and return results for valid filters only
Return an empty result set if all filters are invalid
Return a 400 error if the parameter format is malformed

Always validate filter values on the client side before sending requests to avoid unnecessary API calls.

Performance Considerations

Filter early, filter often. Using specific filters reduces:

Network bandwidth
Response parsing time
Client-side filtering overhead
Server load

Optimal Query Patterns

Good: Specific, targeted queries

GET /activity?statuses=ACTIVE&fullTypes=STAKING%

Better: Even more specific

GET /activity?page=1&statuses=ACTIVE&fullTypes=STAKING%

Avoid: Fetching all data and filtering client-side

# Don't do this and then filter in JavaScript
GET /activity?page=1

Caching Recommendations

Completed transactions rarely change → cache for longer periods (5-15 minutes)
Active transactions change frequently → cache for shorter periods (30-60 seconds)
Real-time updates → implement polling with appropriate intervals

const CACHE_DURATIONS = {
  COMPLETED: 5 * 60 * 1000, // 5 minutes
  ACTIVE: 30 * 1000,        // 30 seconds
  CANCELED: 10 * 60 * 1000  // 10 minutes
};

Transaction History

Complete API reference for the transaction history endpoint

Staking API

Dedicated endpoints for staking operations

Authentication

Portfolio

Trading

Staking

Credit

Activity

Overview

Available Filters

Status Filtering

Available Status Values

Status Filter Examples

Transaction Type Filtering

Available Transaction Types

Transaction Type Filter Examples

Combining Filters

Filter Behavior

Default Behavior

Multiple Values (OR Logic)

Multiple Parameters (AND Logic)

Common Filter Patterns

Portfolio Monitoring

Audit Trail

Trading History

Pending Actions

Failed Transactions

Implementation Best Practices

Client-Side Implementation

JavaScript/TypeScript Example

Python Example

Filter Response Validation

Empty Results

Invalid Filter Values

Performance Considerations

Optimal Query Patterns

Caching Recommendations

Transaction History

Staking API

Build docs developers (and LLMs) love

Authentication

Portfolio

Trading

Staking

Credit

Activity

​Overview

​Available Filters

​Status Filtering

​Available Status Values

​Status Filter Examples

​Transaction Type Filtering

​Available Transaction Types

​Transaction Type Filter Examples

​Combining Filters

​Pagination Parameters

​Pagination Examples

​Filter Behavior

​Default Behavior

​Multiple Values (OR Logic)

​Multiple Parameters (AND Logic)

​Common Filter Patterns

​Portfolio Monitoring

​Audit Trail

​Trading History

​Pending Actions

​Failed Transactions

​Implementation Best Practices

​Client-Side Implementation

​JavaScript/TypeScript Example

​Python Example

​Filter Response Validation

​Empty Results

​Invalid Filter Values

​Performance Considerations

​Optimal Query Patterns

​Caching Recommendations

​Related Resources

Transaction History

Staking API

Build docs developers (and LLMs) love

Overview

Available Filters

Status Filtering

Available Status Values

Status Filter Examples

Transaction Type Filtering

Available Transaction Types

Transaction Type Filter Examples

Combining Filters

Pagination Parameters

Pagination Examples

Filter Behavior

Default Behavior

Multiple Values (OR Logic)

Multiple Parameters (AND Logic)

Common Filter Patterns

Portfolio Monitoring

Audit Trail

Trading History

Pending Actions

Failed Transactions

Implementation Best Practices

Client-Side Implementation

JavaScript/TypeScript Example

Python Example

Filter Response Validation

Empty Results

Invalid Filter Values

Performance Considerations

Optimal Query Patterns

Caching Recommendations

Related Resources