Skip to main content

Overview

This guide covers critical considerations and best practices for integrating the Fibrous Router API into your application. Following these guidelines will ensure a robust, secure, and user-friendly integration.

Critical Considerations

0. Integrator Features - API Key Requirement ⚠️

API Key Required for Integrator Features: To use integrator features (fee or surplus sharing), you MUST obtain an API key from Fibrous. Generate and manage your API keys at the Fibrous Partnership Portal. Without an API key, integrator parameters will be ignored and normal swap functionality will be used.Contract Function Selection:
  • Normal Swap (no API key) → Use swap() function
  • Integrator Swap (with API key) → Use swapIntegrator() function
See Integrator Features section for detailed implementation.

1. Understanding min_received Calculation ⚠️🔴

Critical: Understanding min_received calculation is essential for proper slippage protection, especially when using integrator features. This is one of the most important concepts to understand before integrating.
What is min_received? min_received is the minimum amount of output tokens the user will receive after accounting for:
  1. Integrator fees (if applicable)
  2. Slippage tolerance
Calculation Formula:

Without Integrator Fee (Normal Swap)

Where:
  • amount_out = Expected output amount from route
  • slippage_amount = amount_out × (slippage / 100)
Example:

With Integrator Fee

Important: When integrator fee is applied, min_received is calculated AFTER deducting the fee.
Complete Formula:
Where:
  • amount_out = Expected output amount from route
  • fee_amount = amount_out × (integratorFeePercentageBps / 10000)
  • slippage_amount = amount_out_after_fee × (slippage / 100)
Detailed Example:
Visual Example:
Why This Matters:
  1. User Protection: min_received ensures users get at least this amount, protecting against:
    • Price movements (slippage)
    • Integrator fees
    • Both combined
  2. Transaction Reversion: If the actual output is less than min_received, the transaction will revert, protecting the user.
  3. Display to Users: Always show users the min_received amount so they know the minimum they’ll receive.
  4. Fee Transparency: Users should see:
    • Expected output amount
    • Fee amount (if applicable)
    • Amount after fee
    • Minimum received (with slippage)
Implementation:

2. Slippage Management

Setting Appropriate Slippage: Best Practice:
Important:
  • Never set slippage to 0% - transactions will likely fail
  • Higher slippage increases success rate but may result in worse prices
  • Monitor price impact in route responses
  • Consider showing slippage warning to users for values > 1%

3. Error Handling

Always implement comprehensive error handling:
Key Error Scenarios:
  1. Token Same Error: User selected same token for input and output
  2. Rate Limit: Too many requests - implement exponential backoff
  3. Invalid Route: Route expired or invalid - fetch new route
  4. Network Error: Connection issues - retry with backoff
  5. Validation Error: Invalid parameters - show user-friendly message

4. Rate Limiting

Default Limits:
  • 200 requests per minute (shared across all endpoints)
  • Rate limits reset every minute
Best Practices:
For Higher Limits:

5. Token Approvals

Token Approvals Required: For ERC-20 token swaps, users must approve the Fibrous Router contract to spend their tokens before executing swaps.
Approval Flow:
Important Notes:
  • Native tokens (ETH, MON) don’t require approval
  • Check allowance before every swap
  • Consider approving max amount for better UX
  • Show clear approval UI to users

6. Gas Estimation

Always add gas buffer:
Best Practices:
  • Use estimated gas from API response as baseline
  • Add 10-20% buffer for safety
  • Monitor gas prices and adjust accordingly
  • Consider using maxFeePerGas and maxPriorityFeePerGas for EIP-1559

7. Network-Specific Considerations

EVM Networks (Base, HyperEVM, Citrea, Monad):
  • Use standard EVM transaction format
  • Native tokens: 0x0000000000000000000000000000000000000000 or 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE
  • Gas estimation required
  • Token approvals needed for ERC-20 tokens
Starknet:

9. Integrator Features and API Key Requirements

API Key Required: Integrator features (fee or surplus sharing) require an API key from Fibrous. Generate and manage your API keys at the Fibrous Partnership Portal. If you don’t have an API key, use normal swap functionality.
Two Swap Modes:

Normal Swap (No API Key)

If you don’t have an API key or don’t want to use integrator features:

Integrator Swap (With API Key)

If you have an API key and want to monetize your integration:
Critical Points:
  1. API Key Required: Integrator features only work with a valid API key
  2. Function Selection:
    • Normal swap → Use swap() function
    • Integrator swap → Use swapIntegrator() function
  3. Integrator Data: When using integrator features, the calldata includes integrator_data which must be passed to swapIntegrator()
Contract Functions:

10. V1 vs V2 API

When to use V1:
  • Existing integrations that work well
  • Simple use cases without integrator features
  • When you need backward compatibility
When to use V2:
  • New integrations
  • Need integrator features (fee/surplus)
  • Want enhanced metadata tracking
  • Prefer clearer endpoint names
See V2 Migration Guide for detailed comparison and migration steps.
Endpoint Mapping:
  • V1 /calldata → V2 /routeAndCalldata (GET)
  • V1 /execute → V2 /calldata (POST)

11. Security Best Practices

Input Validation:
Security Checklist:
  • ✅ Always validate user inputs
  • ✅ Sanitize addresses (lowercase, checksum)
  • ✅ Verify route freshness
  • ✅ Check minimum received amounts
  • ✅ Never trust client-side calculations
  • ✅ Use HTTPS only
  • ✅ Implement request signing for sensitive operations
  • ✅ Rate limit user requests on your side

12. User Experience Considerations

Loading States:
User Feedback:
  • Show clear loading states
  • Display route information (output amount, price impact)
  • Warn about high slippage
  • Show transaction status
  • Provide clear error messages
  • Estimate gas costs

13. Testing Recommendations

Test Scenarios:
  1. Happy Path:
    • Successful swap with fresh route
    • Token approval flow
    • Transaction confirmation
  2. Error Cases:
    • Same token addresses
    • Invalid addresses
    • Insufficient balance
    • Rate limiting
    • Network errors
  3. Edge Cases:
    • Very small amounts
    • Very large amounts
    • Low liquidity pairs
    • High volatility tokens
  4. Integration Tests:
    • Test on testnets first
    • Test with small amounts on mainnet
    • Monitor transaction success rate
    • Test error recovery
Example Test:

14. Monitoring and Analytics

Key Metrics to Track:
  • Route fetch success rate
  • Transaction success rate
  • Average route calculation time
  • Average transaction gas cost
  • Error rates by type
  • User slippage preferences
  • Most popular token pairs
Implementation:

Complete Integration Example

Here’s a complete, production-ready integration example:

Checklist

Before going to production, ensure you’ve covered:
  • Route freshness validation
  • Appropriate slippage settings
  • Comprehensive error handling
  • Rate limiting implementation
  • Token approval flow
  • Gas estimation with buffer
  • Input validation
  • Network-specific handling
  • User feedback and loading states
  • Testing on testnets
  • Error monitoring
  • Analytics tracking
  • Integrator Features (if using):
    • API key from the Fibrous Partnership Portal
    • swapIntegrator() function used instead of swap()
    • integrator_data passed to contract function
    • min_received calculation verified (amount_out - fee - slippage)
    • Fee amounts displayed correctly to users

Additional Resources


Support

Need help with integration?