Overview
The "Jupiter Recurring" node integrates with the Jupiter Recurring API to manage recurring token swap orders on a blockchain platform. It supports creating, canceling, executing, and querying recurring orders, as well as handling price-based deposits and withdrawals.
This node is beneficial for users who want to automate periodic token swaps or manage recurring trading strategies programmatically. For example, a user can set up a recurring order to swap a fixed amount of one token to another at regular intervals or based on price triggers, without manual intervention.
Practical examples:
- Creating a recurring order to swap SOL tokens to USDC every day.
- Canceling an existing recurring order if market conditions change.
- Executing a signed transaction related to a recurring order.
- Retrieving active or historical recurring orders for a specific account.
- Managing deposits and withdrawals for price-based recurring orders.
Properties
| Name | Meaning |
|---|---|
| Base URL | The base URL for the Jupiter Recurring API endpoint (default: https://lite-api.jup.ag/recurring/v1). |
| Recurring Type | Type of recurring order; options are: time (based on time intervals) or price (based on price triggers). |
| Input Mint | The mint address of the input token (token to be swapped from). |
| Output Mint | The mint address of the output token (token to be swapped to). |
| Amount | The amount to swap, specified in the smallest unit of the token (e.g., lamports or atoms). |
| Maker | The wallet address of the maker initiating the order. |
| Slippage BPS | Slippage tolerance expressed in basis points (default is 50 bps, i.e., 0.5%). |
These properties are used when creating a new recurring order.
Output
The node outputs JSON data corresponding to the response from the Jupiter Recurring API for the selected operation. The structure varies depending on the operation but generally includes details about the created order, canceled order confirmation, executed transaction result, or lists of recurring orders.
If the operation involves transactions (like execute), the node handles signed transaction data encoded in Base64 but does not output binary data directly.
Output example for "Create Order" might include fields such as order ID, status, and other metadata returned by the API.
Dependencies
- Requires access to the Jupiter Recurring API, which may require an API key credential configured in n8n.
- Optional API key authentication header (
x-api-key) is added if credentials are provided. - No other external dependencies are required.
Troubleshooting
Common issues:
- Invalid or missing token mint addresses can cause API errors.
- Incorrect wallet addresses or malformed amounts may lead to request failures.
- Missing or invalid API key will result in authorization errors.
- Network connectivity issues to the specified Base URL.
Error messages:
"Unknown operation": Occurs if an unsupported operation is selected; ensure the operation name matches supported ones.- HTTP errors from the API (e.g., 400 Bad Request, 401 Unauthorized) indicate issues with request parameters or authentication.
Resolutions:
- Verify all required fields are correctly filled with valid values.
- Ensure the API key credential is properly configured if needed.
- Check network connectivity and correct Base URL.
- Use the node's "Continue On Fail" option to handle errors gracefully during batch processing.
Links and References
- Jupiter Recurring API Documentation (Base URL reference)
- General Solana Token Mint Addresses documentation (for understanding mint addresses)
- n8n HTTP Request Node documentation (for understanding how requests are made)