Docs - API Cripto

Crypto-as-a-service. Enable buy, sell, and transfer of crypto with one simple API integration

## Sections
• [Introduction](https://docs.manteca.dev/cripto/introduction-1/introduction.md): Our API is designed to streamline cryptocurrency trading, providing businesses with the infrastructure needed to simplify a wide range of operations. It supports the seamless receipt of user funds from an expanding selection of blockchains and financial institutions, facilitates trading of cryptocurrencies (both cross-pair and against fiat currencies), and enables secure fund transfers to external wallets or bank accounts. What is the API version 2? Alongside our cryptocurrency trading API, we provide additional APIs for stock trading and fiat exchange, with other finance-related projects currently in development. To simplify and unify these different systems, we underwent a standardization process, which required changing the structure of certain interfaces as well as many endpoints. We've implemented these changes to minimize the adaptation burden on our clients.
• [Authentication](https://docs.manteca.dev/cripto/introduction-1/authentication.md): Manteca uses API keys to authenticate requests. These keys must be included in the md-api-key header. The credentials grant full access, so they must be stored securely. For environments with special security requirements, we can enable additional network control measures: IP whitelisting VPN access
• [Dashboard](https://docs.manteca.dev/cripto/introduction-1/dashboard.md): The Dashboard is a centralized interface that allows businesses to monitor and manage processes integrated through our API. From this platform, users can view user status, review uploaded documentation, and monitor operations in real time. Access is available at: Production environment: https://dashboard.manteca.dev Sandbox environment: https://dashboard-qa.manteca.dev Access to the platform requires user credentials and is protected by two-factor authentication (2FA) to ensure an additional layer of login security.
• [Exchanges (Multi-Country)](https://docs.manteca.dev/cripto/key-concepts/exchanges-multi-country.md): All orders will be executed on a particular exchange, an exchange represents a logical separation between certain countries jurisdictions. For the most part you can onboard users on multiple exchanges, so you could for example have half your users on the Argentina exchange, a quarter on the Chile exchange and the rest on the Brazil exchange. A single User will always belong to one and only one exchange, that is because during the onboarding process the users provide their legal id, which corresponds to only one country and therefore one exchange. The real person however can have multiple users on multiple exchanges and even multiple companies. The Argentina exchange has extra onboarding requirements to operate and is treated as a separate entity for accounting, meaning debt generated in that exchange will be displayed separately than debt generated in other exchanges. For more information read Accounting . Available Exchanges Title Description Exchange Country Supported FIAT Assets ARGENTINA ARS, USD, BRL (QR pix payments) CHILE CLP BRAZIL BRL COLOMBIA COP PANAMA PUSD COSTA_RICA CRC GUATEMALA GTQ MEXICO MXN PHILIPPINES PHP BOLIVIA BOB PERU PEN Differences in accounting between exchanges For companies that generate credit through the profit system or operate against debt, as described in the Accounting section, it is important to explain that all debt/credit generated on any exchange except the Argentina exchange will be converted to it's USDT value and expected to be settled in that asset or any alternative USD-pegged stable coin that we support like USDC. The only exchange that allows for debt in local currency as of right now is Argentina in which case debt/credit can be in either ARS, USD or USDT, depending on the particular operation. How we determine the exchange for an operation The exchange for an operation is determined at the moment of creation of the corresponding entity and it depends on the exchange the User belongs to. For example, if you have users that belong on different exchanges, and then you request to create an Order for one User, then the exchange for that particular Order will match with the exchange for the corresponding User. The same goes for any other entity, although not shown, withdraws and deposits also happen on a particular exchange for the purposes of accounting, meaning that if for example a User from Argentina withdraws funds to the deposit address of a User from Brazil, then the Withdraw will affect the accounting for Argentina whilst the Deposit will affect the accounting for Brazil.
• [Different types of IDs](https://docs.manteca.dev/cripto/key-concepts/different-types-of-ids.md): Entities can have multiple types of IDs, these are: ID and numberId These are always present and are generated by us at the time of entity creation. The ID is a 24-character hexadecimal string that is globally unique across all entity types. The numberId is a positive integer that is only unique within its specific entity type. External ID The externalId is optional and managed by your company. If provided, it must be unique within the same entity type. This ID must not follow the format of a 24-character hexadecimal string or a positive integer, to ensure it can be clearly distinguished from the other ID types. Session ID You may provide a sessionId when creating entities. This ID can be used to group entities based on any logic your company defines. We impose no constraints on this value. It is simply stored with the entities, allowing you to later query them using that ID. We also offer endpoints that simplify querying multiple entities by sessionId. Example For this example let's assume we have 2 Orders, 1 Withdraw and 1 Deposit. Then the possible IDs would look like this: Title Description Entity Entity Type ID Number ID External ID (Optional) Session ID (Optional) First Order Order 67628c55a62ffdc40a97e023 1 example-external-id-1 example-session-id-1 Second Order Order 67628c5bfd69ee89f9f6fccc 2 example-external-id-2 example-session-id-1 First Withdraw Withdraw 67628c61f2ba1bdc029919d4 1 example-external-id-1 example-session-id-1 First Deposit Deposit 67628c669c53fa98f505a714 1 example-external-id-1 example-session-id-1
• [People, not Users](https://docs.manteca.dev/cripto/key-concepts/people-not-users.md): Our compliance system monitors activity at the person level, not just at the individual user level. This means that if the same person creates multiple users across different companies using our system, those users will share the same operational limits. For example, if a person reaches their transaction limit while operating through an account under Company A, they will not be able to continue transacting through another account under Company B. The same logic applies to fraud-related restrictions: if fraudulent behavior is detected, the block is applied to the person, regardless of which user or company the behavior originated from. In summary, limits and restrictions are enforced at the person level, regardless of how many users or accounts they may have across different entities.
• [Error handling](https://docs.manteca.dev/cripto/key-concepts/error-responses.md): API Cripto uses standard HTTP response codes to indicate the success or failure of requests. In general: 2xx codes indicate a successful operation. 4xx codes indicate a client error, typically related to the provided input (e.g., missing or invalid parameters). 5xx codes indicate an unexpected server error on Manteca's side. In the case of an error, additional details can be found in the response body. All error responses follow a consistent format, which includes: internalStatus : a string-based internal error code. message : a more detailed description of the issue. All endpoints may return error responses with HTTP status codes in the 400–499 range. These responses follow a consistent structure, as shown below: JSON { "internalStatus": "INTERNAL_STATUS", "message": "Message explaining the error.", "errors": [ "Optional array of messages with details about the error." ] } Common Errors 400 - BAD_REQUEST These are errors in how the request was formatted, it will include an array of messages with details about what field had a wrong value and why it was wrong. For example: JSON { "internalStatus": "BAD_REQUEST", "message": "Bad request.", "errors": [ "asset has wrong value INVALID_ASSET. Possible values are DAI,USDT,BUSD,USDC,USDCB,UST,ETH,BNB,AUST,BTC,LUNA,LUNA2,SOL,MATIC,NUARS,WLD,USDL,SDAI,AXS,MANA,ENJ,SAND,PSG,ATM,BAR,CITY,POL.", "against has wrong value INVALID_AGAINST. Possible values are ARS,USD,CLP,COP,BRL,GTQ,CRC,PUSD.", "assetAmount has wrong value non-number-amount. Value should be valid number string using dot (.) as decimal separator and without trailing dot. So 100 or 100.0 but not 100. Adding - at the beginning like -100.10 is not allowed..", "One of these fields needs to be provided [assetAmount, againstAmount].", "withdrawAddress has wrong value non-valid-address. Value should be a valid ethers address or ICAP address.", "withdrawAddress has wrong value non-valid-address. Value should be a valid terra address.", "withdrawAddress has wrong value non-valid-address. Value should be keyword any-available.", "withdrawNetwork has wrong value INVALID_NETWORK. Possible values are ETHEREUM,BINANCE,TERRA,TERRA2,POLYGON,OPTIMISM,WORLDCHAIN,BASE,ARBITRUM,INTERNAL,BIND,COINAG,VITA,KOYWE,LOCALPAYMENT,MANTECA,TRANSFERO,SUPEFINA." ] } 404 - NOT_FOUND A not found error means the requested entity could not be found. This error can appear on POST requests as well if for example during the creation of an Order you provide an userAnyId with valid syntax but but no user with that ID can be found. JSON { "internalStatus": "USER_NF", "message": "User not found." } 403 - FORBIDDEN A forbidden error can mean multiple things, like for example either your Company does not have enough permissions to perform a certain operation, or the User is missing some compliance requierements or your Company has reached their debt limit, and so on. JSON { "internalStatus": "PERMISSIONS", "message": "Company has no such permission." } 409 - CONFLICT A conflict error means the request was valid, but some aspect of the current state of the entities involved does not allow for such an operation to be performed. For example, asking to pause a Synthetic that is already in a COMPLETED status, or creating an entity with an external ID that already exists. JSON { "internalStatus": "SYNTHETIC_STATUS", "message": "Synthetic status does not allow this operation." } 500 - SERVER ERROR A server error is rare, but if encountered then it means we are experiencing a temporary issue.
• [Networks](https://docs.manteca.dev/cripto/key-concepts/networks.md): Both deposits and withdrawals can be made through different networks, depending on the asset being transferred. In this context, a network refers to either a blockchain or a banking system. Below you will find a list of all supported networks, along with the assets available on each. FIAT - Deposits Title Description Country Network Supported assets Account Type Argentina Bank Transfer ARS, USD Static account Brazil PIX BRL Static account Mexico SPEI MXN Static account Chile Bank Transfer CLP Static account FIAT - Withdrawals Title Description Country Network Supported assets Execution Time (GMT-3) Argentina Bank transfer ARS, USD Instant Brazil PIX BRL Instant Mexico SPEI MXN Instant Colombia Transfiya / Nequi COP Every 10 minutes (24/7) Chile Bank transfer CLP Batch (12:00 / 15:00) Guatemala Bank transfer GTQ Batch (12:00 / 15:00) Panama Bank transfer PUSD Batch (12:00 / 15:00) Costa Rica Bank transfer CRC Batch (12:55–13:00) Philippines Instapay PHP Instant Bolivia Bank transfer BOB Batch (15:00) Peru Bank transfer PEN Instant Crypto - Deposits & Withdrawals Title Description Network Supported assets Account type ETH DAI, ETH, USDT, USDC Wallet address per user BSC DAI, BNB, ETH, BTC, SOL, USDT, USDC, POL Wallet address per user POLYGON USDT, USDC, POL Wallet address per user OPTIMISM WLD, USDCB, ETH Wallet address per user WORLDCHAIN WLD, USDCB Wallet address per user BASE USDC, ETH Wallet address per user ARBITRUM USDC Wallet address per user INTERNAL USDT, USDC Wallet address per user TRON TRX, USDT Wallet address per user
• [Pagination](https://docs.manteca.dev/cripto/key-concepts/pagination.md): Some endpoints return arrays in the response. In cases where the data set can grow dynamically, the response will include pagination metadata, and the following query parameters are supported for paginated requests: Parameters page : The current page number (default: 1 ) limit : The number of items per page (default: 10 )
• [Your Company](https://docs.manteca.dev/cripto/company-setup/your-company.md): The first step to start using our API is to create your company account. To do this, please reach out to us at info@manteca.dev. We'll review your company’s requirements and guide you through the integration process. During onboarding, we’ll create your company entity and provide you with the API keys required to access our sandbox environment, where you can begin testing your integration. This entity will include all relevant configurations, such as: Accounting setup: defines which addresses are authorized to settle debts and/or receive profits Webhook configuration: allows you to define how your company will receive event notifications from our system Fee configuration: allows you to specify markup fees charged on top of the base price Company entity interface TypeScript interface ICompany { // Id of your company, a 24 hex string. id: string // The name of your company. name: string // Optional contact email for your company. email?: string // Your accounting information where you can whitelist settlement and collector addresses. accounting: { // Here we hold the settlement addresses. // These are CVU/CBU, crypto addresses, etc that if we detect a deposit to accounting address from one of these addresses we consider that deposit a settlement for this company's debt. settlementAddresses: string[] // Here we hold the collector addresses. // These are CVU/CBU, crypto addresses, etc that are authorized to be selected to collect profits or outstanding credit. collectorAddresses: string[] } // Your notification information where you can configure how you want your company to be notified of system events. notificationInfo: { // The notification type determines how we notify your company of system events like an order being completed. type: COMPANY_NOTIFICATION_TYPE // The url where we are going to send webhooks if no other more specific webhook was set up. // Required for WEBHOOK notification type and ignored for NONE. generalWebhook?: string // Here the company can configure more specific webhooks, in case they want for example order status update to be sent to a different url than the rest. // Required for WEBHOOK notification type and ignored for NONE. webhooks?: { // Mapping of event names to webhook url. [event: string]: string } // Possible values are “STABLE” meaning all debt is converted to USD-Pegged stable, even supported fiat debt, and must be cancelled sending some USD-Pegged stable. // Or “MATCHING” meaning debt in supported fiat (like “ARS”, or “BRL”) will not be converted and must be cancelled sending the corresponding fiat. settlementPreference: string } // Time of the creation of your company entity as an ISO 8601 Date string. creationTime: string // Time your company entity was last updated at as an ISO 8601 Date string. updatedAt: string } Example company JSON { "id": "675e629f4582a7f05c68f841", "name": "Manteca company", "email": "dev@example.com", "accounting": { "settlementAddresses": [ "some crypto address", "some bank address" ], "collectorAddresses": [ "some crypto address", "some bank address" ] }, "notificationInfo": { "type": "WEBHOOK", "generalWebhook": "https://www.example.com/general/webhook/listener", "webhooks": { "ORDER_STATUS_UPDATE": "https://www.example.com/order/webhook/listener/override", "DEPOSIT_STATUS_UPDATE": "https://www.example.com/deposit/webhook/listener/override" } }, "creationTime": "2024-12-13T12:22:54.290-03:00", "updatedAt": "2024-12-13T12:22:54.290-03:00", }
  • [Get company](https://docs.manteca.dev/cripto/company-setup/your-company/get-company.md): This endpoint allows you to retrieve all information associated with your company. It returns the full configuration, including: General company details Operational parameters Fee preferences Limits Other specific settings
• [Fees and Profit](https://docs.manteca.dev/cripto/company-setup/fees-and-profit.md): In API Crypto, we don't charge platform fees. In our pricing model, all prices provided already include a spread that covers Manteca’s revenue. As such, they can be used directly for operations without requiring any additional adjustments. If your company wishes to charge an additional fee to end users, this must be configured on top of our base prices. Any extra amount collected will be treated as your company’s revenue and can be managed and monitored through our accounting system. Types of fees In API Crypto, we currently offer one type of fee: the Base Fee (or Platform Fee). Our other API solutions may include additional fee types. The Base Fee is the percentage of each Order taken to cover service costs and generate profit for your company to be collected later. This value is determined during onboarding based on your company's specific needs. It works in conjunction with the Base Split, which determines what percentage goes to Manteca versus your company. Example : If the Base Fee is 0.05 (5%) and the Base Split is 0.7 (70% to your company) on an Order of $10,000 ARS: $500 ARS is taken as fees (5% of $10,000) $350 ARS goes to your company (70% of the $500 fee) $150 ARS goes to Manteca (30% of the $500 fee) $9,500 ARS is converted to the crypto asset specified in the Order Fee interface TypeScript interface IFeeInfo { // The id of the fee info, used for queries and to assign Users later. id: string // Flag that determines if this is the main fee info that will act as the default. main: boolean // The values of the fees and split for this Fee Info. All values are numbers between 0 and 1 and represent a percentage, so “0.5” means 50% structure: { // The base fee is the fee to use our platforms, this is the fee that can be split between Manteca and your Company. In CRIPTO all of this fee is for your Company. baseFee: string // This is the percentage of the base fee that goes to your company. In CRIPTO baseSplit is usually 1, because we don't have platform fees. baseSplit: string } // Time of the creation of your company entity as an ISO 8601 Date string. creationTime: string // Time your company entity was last updated at as an ISO 8601 Date string. updatedAt: string } Example fee configuration JSON { "id": "6789b7effcd21f313bb24477", "main": true, "structure": { "baseFee": "0.05", "baseSplit": "0.5" }, "creationTime": "2024-12-13T12:22:54.290-03:00", "updatedAt": "2024-12-13T12:22:54.290-03:00" }
  • [Configure fees](https://docs.manteca.dev/cripto/company-setup/fees-and-profit/configure-fees.md): To be implemented.
• [Accounting](https://docs.manteca.dev/cripto/company-setup/accounting.md): For companies that need to operate with credit or manage debt settlements, we provide a comprehensive accounting system that tracks all financial obligations and presents them through simple endpoints for easy management. Our flexible accounting system supports different operational models: User balance Operations : Standard operations where users maintain a balance within your platform. Credit-based Operations : Allow users to operate on credit and settle accumulated debt at scheduled intervals. Pre-funded Overdraft : For scenarios requiring credit operations with pre-funding to cover potential exposure. Our accounting system gives you the flexibility to choose the operational model that best fits your business requirements, whether you need real-time settlements or periodic debt reconciliation. Settlements Settlements are records of all instances where your company and Manteca have settled outstanding debts. These settlements are triggered either manually or automatically when funds are sent from your settlement addresses to one of our bank accounts or when your company withdraws company credit or profit to one of your collector addresses. Settlement interface TypeScript interface ISettlement { // Id of the settlement, a 24 hex string. id: string // The platform that relates to the settlement. This can be: CRIPTO, BROKER or CAMBIO. platform: PLATFORM // The type of settlement, read enum below for more details. type: ACCOUNTING_SETTLEMENT_TYPE // The money being sent, always in positive values and the type determines if it is treated as credit or debt. payment: IBalance // How many debt slips were eliminated during this settlement. // Remember debt slips and net balance (credit - debt) are different things. debtSettled: IBalance // How many credit slips (not profit slips) were eliminated during this settlement. creditSettled: IBalance // How many profit slips (not credit slips) were eliminated during this settlement. profitSettled: IBalance // Time of the creation of the settlement entity as ISO 8601 Date String. creationTime: string // Time the settlement entity was last updated at as ISO 8601 Date String. updatedAt: string } enum ACCOUNTING_SETTLEMENT_TYPE { // Your company sent money to manteca and that resulted on this settlement. COMPANY_TO_MANTECA = 'COMPANY_TO_MANTECA', // Your company withdrew credit or manteca sent money to your company some other way and that resulted on this settlement. MANTECA_TO_COMPANY = 'MANTECA_TO_COMPANY', // Your company withdrew accumulated profit and that resulted on this settlement. PROFIT_SETTLEMENT = 'PROFIT_SETTLEMENT', } interface IBalance { // Keys are assets, like "ARS" or "USDT" and value is decimal amounts, like "10.0" or "0.000005". [asset: string]: string } Example settlement JSON { "id": "675fc843f5763f6f70e832b0", "platform": "CRIPTO", "type": "COMPANY_TO_MANTECA", "payment": { "USDT": "1480.35894572" }, "debtSettled": { "USDT": "6480.35894572" }, "creditSettled": { "USDT": "5000.00" }, "profitSettled": {}, "creationTime": "2024-12-13T12:22:54.290-03:00", "updatedAt": "2024-12-13T12:22:54.290-03:00" }
  • [Get Accounting Summary](https://docs.manteca.dev/cripto/company-setup/accounting/get-accounting-summary.md): This endpoint provides the company’s accounting summary. It includes key information such as: Accumulated debt Available credit Net balance Generated profit It is useful for monitoring the overall financial status and validating the correct allocation of operations within the system. If no query parameter is provided, the accounting data returned represents the combined summary of both Argentina and Global (everything except Argentina). To retrieve accounting data for a specific group, you can use the group query parameter: ?group=ARGENTINA ?group=GLOBAL
• [Webhooks](https://docs.manteca.dev/cripto/company-setup/notifications.md): Webhooks are one of the ways in which a system event can be notified to a company. Read Configure Webhooks section to view the endpoint used to configure your notification settings. Webhooks—both in the sandbox and production environments—will be sent from the fixed IP address: 18.229.68.94 . This static IP allows your team to adjust firewall or security policies accordingly to ensure secure and controlled reception of webhook events. Webhooks signature To ensure the integrity of data sent via webhooks, we use an HMAC-based validation system. Each webhook includes a signature in the md-webhook-signature HTTP header. This signature, combined with the shared secret between your company and Manteca, allows you to verify the authenticity of incoming messages. The verification process involves generating an HMAC signature on your side using: The raw request body, and The shared secret The generated signature must exactly match the one received in the header. To guarantee consistency and make sure the HMAC calculation is deterministic, the JSON body must be serialized in a stable way—with keys sorted alphabetically. In our implementation, we use the fast-json-stable-stringify library to handle this serialization. We recommend applying a similar approach on your side to ensure consistent results during verification. TypeScript import crypto from 'crypto'; export const verifyWebhookSignature = (body: any, header: string, secret: string): boolean => { // First you need to stringify the body using JSON.stringify const dataString: string = JSON.stringify(body); // Then you need to generate the HMAC signature using SHA-256 algorithm, we recommend using crypto package if on Node environment const hmac = crypto.createHmac('sha256', secret); const signature = hmac.update(dataString, 'utf8').digest('hex'); // Finally you need to verify that the value is the same return header === signature; } Webhooks payload The payload for an event and the payload sent in a webhook are not the same, since webhook payloads will contain extra information. At continuation we will show the basic structure of a webhook payload: TypeScript interface IWebhookPayload { // The name for the event, for example “WITHDRAW_STATUS_UPDATE”. Used to allow for parsing if using a single HTTP endpoint for more than one event. event: string // The actual payload, for example IWithdraw for event “WITHDRAW_STATUS_UPDATE”. Read System Events section for more interfaces. data: unknown } Webhooks failure handling When delivering webhooks, we implement an exponential backoff strategy to handle failures gracefully. If the receiving server does not respond with a successful HTTP status code (2xx), we will not drop the request immediately. Instead, we will automatically retry the delivery multiple times over the course of several hours, gradually increasing the delay between each attempt. This approach ensures resilience against temporary outages or network issues on the receiving end. System Events ORDER_STATUS_UPDATE This system event is emitted every time an Order changes status. The payload for the event will be the updated Order. Read Orders section for the IOrder interface. TypeScript { "data": { "against": "ARS", "asset": "WLD", "assetAmount": "10.00000000", "creationTime": "2025-07-22T09:32:41.656-03:00", "effectivePrice": "1640.35", "exchange": "ARGENTINA", "feeInfo": { "companyProfit": "0", "custodyFee": "0", "platformFee": "0", "totalFee": "0.00000000000000000000" }, "filledAmount": "10.00000000", "finalClaimInfo": { "asset": "ARS", "base": "16403.50", "companyProfit": "0", "platformFee": "0.00", "total": "16403.50", "totalFees": "0.00" }, "finalCreditInfo": { "asset": "WLD", "base": "10.00000000", "companyProfit": "0", "platformFee": "0", "total": "10.00000000", "totalFees": "0" }, "id": "687f84e9c536d39525e68ab5", "numberId": "100011648", "price": "1640.35", "referencePrices": { "assetArsPrice": "1640.35", "assetLocalCurrencyPrice": "1640.35", "assetUsdPrice": "0.001", "usdtLocalCurrencyPrice": "1315.00" }, "sessionId": "TestWebhookV2-478", "side": "BUY", "status": "COMPLETED", "type": "DIRECT", "updatedAt": "2025-07-22T09:32:41.656-03:00", "userId": "685eba4842d304517432f6c5", "userNumberId": "100009791" }, "event": "ORDER_STATUS_UPDATE" } WITHDRAW_STATUS_UPDATE This system event is emitted every time a Withdraw changes status. The payload for the event will be the updated Withdraw. Read Withdraws section for the IWithdraw interface. TypeScript { "data": { "amount": "9.910418", "asset": "WLD", "creationTime": "2025-07-22T09:32:44.985-03:00", "destination": "0x4cD0820ca71Bda1A6cEfe1A6D5a2F6E50D4370f2", "id": "687f84ecc536d39525e68ad8", "network": "WORLDCHAIN", "networkId": "0xf71216cd6a63cbcfbff3a6c37216aa4a6729240331eacb8e4c88fc71b5e529eb", "numberId": "100008493", "sessionId": "TestWebhookV2-478", "status": "EXECUTED", "updatedAt": "2025-07-22T09:33:17.603-03:00", "userId": "685eba4842d304517432f6c5", "userLegalId": "20345048104", "userNumberId": "100009791" }, "event": "WITHDRAW_STATUS_UPDATE" } [Deprecated] USER_STATUS_UPDATE It is recommended to use USER_ONBOARDING_UPDATE instead of this event, since it provides more comprehensive information. This system event is emitted every time an User changes status. The payload for the event will be the updated User. Read Users section for the IUser interface. TypeScript { "data": { "addresses": { "depositAddresses": {}, "knownAddresses": [] }, "banking": { "accounts": [ { "cbu": "03235495436", "currency": "BRL", "description": "Cta BRL" } ] }, "creationTime": "2025-07-11T00:13:51.612-03:00", "email": "onboardingapicryptobrar003@manteca.dev", "exchange": "BRAZIL", "externalId": "onboardingApiCryptoBRAr003", "id": "6870816f0cfddba4e3730dfc", "numberId": "100010067", "onboarding": { "BANK_ACCOUNT_DEFINITION": { "required": false, "status": "PENDING" }, "BASIC_PERSONAL_DATA_DEFINITION": { "required": true, "status": "COMPLETED" }, "EMAIL_VALIDATION": { "required": false, "status": "PENDING" }, "FEP_DOCUMENTATION_VALIDATION": { "required": false, "status": "PENDING" }, "IDENTITY_DECLARATION": { "required": true, "status": "COMPLETED" }, "IDENTITY_VALIDATION": { "required": false, "status": "PENDING" }, "PEP_DOCUMENTATION_VALIDATION": { "required": false, "status": "PENDING" }, "POLITICAL_CONSTRAINTS_VALIDATION": { "required": true, "status": "COMPLETED" }, "SECURITY_VALIDATION": { "required": true, "status": "COMPLETED" }, "SELFIE_VALIDATION": { "required": false, "status": "PENDING" }, "TYC_ACCEPTANCE": { "required": false, "status": "PENDING" } }, "status": "ACTIVE", "type": "INDIVIDUAL", "updatedAt": "2025-07-11T00:13:55.852-03:00" }, "event": "USER_STATUS_UPDATE" } USER_ONBOARDING_UPDATE This system event is emitted every time an onboarding task of a User changes status. The payload for the event will specify which onboarding task has been updated and the updated User. Read Users section for the IUser interface and Onboarding tasks to know more about them. TypeScript { "data": { "updatedTasks": [ "IDENTITY_VALIDATION" ], "user": { "addresses": { "depositAddresses": {}, "knownAddresses": [] }, "banking": { "accounts": [] }, "creationTime": "2025-10-28T10:53:27.534-03:00", "email": "testemoanteca+20402103591@gmail.com", "exchange": "ARGENTINA", "externalId": "Test-ARG-20402103591", "id": "6900cad749625a48f48b8285", "numberId": "100013461", "onboarding": { "BANK_ACCOUNT_DEFINITION": { "required": false, "status": "PENDING" }, "BASIC_PERSONAL_DATA_DEFINITION": { "required": true, "status": "COMPLETED" }, "EMAIL_VALIDATION": { "required": false, "status": "PENDING" }, "FEP_DOCUMENTATION_VALIDATION": { "required": false, "status": "PENDING" }, "IDENTITY_DECLARATION": { "required": true, "status": "COMPLETED" }, "IDENTITY_VALIDATION": { "required": true, "status": "COMPLETED" }, "PEP_DOCUMENTATION_VALIDATION": { "required": false, "status": "PENDING" }, "POLITICAL_CONSTRAINTS_VALIDATION": { "required": true, "status": "COMPLETED" }, "SECURITY_VALIDATION": { "required": true, "status": "COMPLETED" }, "SELFIE_VALIDATION": { "required": false, "status": "PENDING" }, "TYC_ACCEPTANCE": { "required": false, "status": "COMPLETED" } }, "sessionId": "ab00e262-e86d-4241-971e-df7500f77a7e", "status": "ACTIVE", "type": "INDIVIDUAL", "updatedAt": "2025-10-28T12:51:47.219-03:00" } }, "event": "USER_ONBOARDING_UPDATE" } SYNTHETIC_STATUS_UPDATE This system event is emitted every time a Synthetic changes status. The payload for the event will be the updated Synthetic. Read Synthetics section for the ISynthetic interface. TypeScript { "data": { "creationTime": "2025-07-22T09:27:07.506-03:00", "currentStage": 4, "details": { "againstAmountOperated": "16403.5", "assetAmountOperated": "10.00000000", "depositAddress": "4310001343800000045110", "depositAlias": "TIENDACRYPTO.ARS", "price": "1637.70", "priceExpireAt": "2025-07-22T09:30:06.533-03:00", "withdrawCostInAgainst": "147.09", "withdrawCostInAsset": "0.089815" }, "id": "687f839bc536d39525e68a6e", "numberId": "5987", "sessionId": "TestWebhookV2-478", "stages": { "1": { "asset": "ARS", "depositIds": [ "687f84e8c536d39525e68a9f" ], "detectedAmount": "16377.00", "expireAt": "2025-07-22T12:57:07.484Z", "stageType": "DEPOSIT", "thresholdAmount": "16377.00", "useOverflow": true }, "2": { "against": "ARS", "asset": "WLD", "assetAmount": "10.00000000", "orderId": "687f84e9c536d39525e68ab5", "price": "1637.70", "priceCode": "48ea405f-4e21-4c35-977b-2b18e6fbb4e8", "side": "BUY", "stageType": "ORDER", "type": "MARKET" }, "3": { "amount": "10.0", "asset": "WLD", "destination": { "address": "0x4cD0820ca71Bda1A6cEfe1A6D5a2F6E50D4370f2", "network": "WORLDCHAIN" }, "network": "WORLDCHAIN", "stageType": "WITHDRAW", "to": "0x4cD0820ca71Bda1A6cEfe1A6D5a2F6E50D4370f2", "withdrawId": "687f84ecc536d39525e68ad8" } }, "status": "COMPLETED", "type": "RAMP_OPERATION", "updatedAt": "2025-07-22T09:33:19.701-03:00", "userId": "685eba4842d304517432f6c5", "userNumberId": "100009791" }, "event": "SYNTHETIC_STATUS_UPDATE" } DEPOSIT_DETECTED This system event is emitted every time a Deposit is confirmed. The payload for the event will be the Deposit. Read Deposits section for the IDeposit interface. TypeScript { "data": { "amount": "16377.00", "asset": "ARS", "creationTime": "2025-07-22T09:32:40.556-03:00", "id": "687f84e8c536d39525e68a9f", "network": "BANK_TRANSFER", "numberId": "4843", "sessionId": "TestWebhookV2-478", "updatedAt": "2025-07-22T09:32:40.556-03:00", "userId": "685eba4842d304517432f6c5", "userLegalId": "20345048104", "userNumberId": "100009791" }, "event": "DEPOSIT_DETECTED" } WIDGET_FINISHED This sytem event is emitted every time a Widget finishes regardless of success. Interface of the event is as follows, although it what fields are present depends on the widget: TypeScript { "data": { "sessionId": "example-s15ession-id-1", "signature": "cb6f315b-2299-4242-b2e4-81f214724718", "success": true, "userExternalId": "example-e15xternal-id-1", "userId": "687fcd43160b638a204c9efe", "userNumberId": "100010419", "widget": "ONBOARDING" }, "event": "WIDGET_FINISHED" } SYSTEM_NOTICE This system event is emitted whenever a recoverable error is detected or some other issue that is outside the normal flow of operations is detected. For example, if a Withdraw fails to be sent to the Network but can be attempted again then a system notice event is emitted to notify your company of the possible delay of said Withdraw until one of our administrators resolves the issue, and if the issue is not solvable then a proper status change of the Withdraw to a CANCELLED status would occur and the corresponding WITHDRAW_STATUS_UPDATE even will be emitted. No action is required to be taken upon a system notice event, it simply exists to allow companies to notify their users of possible delays if the wish to do so. TypeScript { "data": { "entity": { "creationTime": "2025-07-25T12:04:35.546-03:00", "currentStage": 1, "details": { "depositAddress": "0x862Acf26956DCEf54F4726CF88709bFE9128e500", "merchant": { "category": "AGRICULTURAL_SERVICES", "categoryCode": "0448", "legalId": "92100195918315522042", "name": "CESAR TACURI INGA" }, "paymentAgainstAmount": "6.00961539", "paymentAgainstAsset": "USDT", "paymentAsset": "PEN", "paymentAssetAmount": "20", "paymentPrice": "3.328", "price": "3.328", "priceExpireAt": "2025-07-25T12:09:28.738-03:00", "qrType": "PERU_QR" }, "id": "68839d03d36679d15b33cac4", "numberId": "6363", "stages": { "1": { "asset": "USDT", "expireAt": "2025-07-25T15:09:28.738Z", "stageType": "DEPOSIT", "thresholdAmount": "6.00961539" }, "2": { "against": "PEN", "asset": "USDT", "assetAmount": "6.00961539", "price": "3.328", "priceCode": "446466ae-05c9-4eb1-a491-1085aed0767c", "side": "SELL", "stageType": "ORDER", "type": "MARKET" }, "3": { "amount": "20", "asset": "PEN", "destination": { "address": "PEN-.-20-.-CESAR TACURI INGA-.-PER-.-92100195918315522042-.-000201010211263700028001039030220250424092119905530665204482953036045802PE5917CESAR TACURI INGA6004Lima80550003ID10144suGASdIEsZFzlFh4eZ/UMQRNdpSojGNBwPiV0Punz2o=6304FA5B-.-eyJpbnN0cnVjdGlvbklkIjoiMjAyNTA3MjUxMDA0MjYwOTIxNDExNTAxNTQwNiIsImlkUXIiOiIyNTA0MjQwOTIxMTk5MDU1MzA2NiJ9", "network": "PERU_QR" }, "network": "PERU_QR", "stageType": "WITHDRAW", "to": "PEN-.-20-.-CESAR TACURI INGA-.-PER-.-92100195918315522042-.-000201010211263700028001039030220250424092119905530665204482953036045802PE5917CESAR TACURI INGA6004Lima80550003ID10144suGASdIEsZFzlFh4eZ/UMQRNdpSojGNBwPiV0Punz2o=6304FA5B-.-eyJpbnN0cnVjdGlvbklkIjoiMjAyNTA3MjUxMDA0MjYwOTIxNDExNTAxNTQwNiIsImlkUXIiOiIyNTA0MjQwOTIxMTk5MDU1MzA2NiJ9" } }, "status": "ACTIVE", "type": "PERU_QR_PAYMENT", "updatedAt": "2025-07-25T12:05:54.115-03:00", "userId": "6880e11fbdf81c92fc54e8b6", "userNumberId": "100010488" }, "entityType": "SYNTHETIC", "message": "Synthetic expired before detecting a deposit, either reactivate with a new price lock or it will be cancelled automatically.", "type": "SYNTHETIC_EXPIRED" }, "event": "SYSTEM_NOTICE" } COMPLIANCE_NOTICE This compliance event is emitted whenever the compliance data of a user is altered. The event will be triggered with different event types depending on what caused the notice: Title Description Type Trigger Condition CLOSE_TO_OPERATION_LIMIT When a user performs an operation that leaves them at 10% or less of their ANNUAL or MONTHLY operational limit. OPERATION_LIMIT_UPDATED When operational limits are modified for a user (increase, decrease, etc.). TypeScript { "data": { "exchange": "ARGENTINA", "legalId": legalId, "message": "The operation limit for the user with CUIT legalId has been updated.", "payload": { "expirationTime": "2025-09-11T16:52:54.583-03:00", "limitAction": "LOWER", "newLimit": 7000000, "timeframe": "MONTH", "updateReason": "MANUAL_LIMIT_CHANGE" }, "type": "OPERATION_LIMIT_UPDATED", "event": "COMPLIANCE_NOTICE" } } /////////////////////// { "data": { "exchange": "ARGENTINA", "legalId": legalId, "message": "The user with CUIT legalId has operated $910000 in the last year, approaching their annual limit of $1000000.", "payload": { "limit": 1000000, "operatedAmount": 910000, "timeframe": "YEAR" }, "type": "CLOSE_TO_OPERATION_LIMIT", "event": "COMPLIANCE_NOTICE" } } PAYMENT_REFUND This event is emitted when a payment refund is made. Plain text { "data": { "amount": "6.61", "asset": "BRL", "networkId": "56308f7a-26ec-4c51-b9ce-04b0dbcfc9dd", "partial": false, "paymentNumberId": "5277", "refundReason": "Manual refund", "refundedAt": "2025-07-11T13:29:19.061Z", "userId": "684b95e0017d29431c2cadb0", "userNumberId": "100009361" }, "event": "PAYMENT_REFUND" }
  • [Configure webhooks](https://docs.manteca.dev/cripto/company-setup/notifications/configure-webhooks.md): To receive event notifications, there are two ways to configure the endpoints: generalWebhook : allows you to receive all events through a single endpoint. Event-specific webhooks: you can define a specific endpoint for each event type, in case you want to handle them differently. In both cases, a field called secret is used. This acts as a shared secret to generate an HMAC signature, which allows you to verify the authenticity of the received messages.
• [The Onboarding Process](https://docs.manteca.dev/cripto/onboarding-users/the-onboarding-process.md): In Manteca's B2B platform, user onboarding serves as the foundational layer of the system. To complete onboarding, users can follow one of two integration paths. The API-based approach , allowing full control over each step. Alternatively, we offer a pre-built onboarding widget that can be embedded into your product with minimal effort. The onboarding state of a user is defined by two core fields: Status : Indicates the current phase of the user's onboarding process. It can be set to ONBOARDING when the user is still completing the required steps, ACTIVE when onboarding is complete and the user can access production features, or INACTIVE when the account is blocked. OnboardingTasks : A list of tasks assigned based on the user's country. Each task includes a required flag (to indicate if it's mandatory for activation) and a status that reflects its progress — either PENDING , IN_PROGRESS , or COMPLETED . As long as the user's status is ONBOARDING , the platform restricts access to core functionality. The system uses the task list to track progress and determine when the user becomes eligible for activation. Once every ONBOARDING_TASK is completed, the user is automatically set to ACTIVE . You can subscribe to the USER_ONBOARDING_UPDATE webhook to receive a notification when an ONBOARDING_TASK changes status. In the expected happy flow, this happens once, from ONBOARDING to ACTIVE. If any step fail on our side, this webhook should notify you with pertinent data.
  • [Create user](https://docs.manteca.dev/cripto/onboarding-users/the-onboarding-process/create-user.md): Registering a user in the platform requires only a few API calls. Below is the recommended ( happy path ) flow for user creation and activation. While the full list of endpoints is available, in most cases it’s sufficient to use only three: 1 Create the user Use the Initial Onboarding endpoint to create the user and submit their declarative information. We recommend including as much data as possible from the start to increase the chances of automatic approval. → See how to create an initial user 2 Check for missing personal data Use the Missing Personal Data endpoint to verify which fields are still required to complete the Define Personal Datatask. If any fields are missing, complete them using the corresponding onboarding task endpoint (for example, Define Personal Data or Add Bank Account). → See how to complete missing personal data 3 Upload identity documentation Once all mandatory information is complete, upload the user’s identity images using the Upload Identity Image endpoint. This step validates the user’s identity and finalizes the onboarding process. → See how to upload identity documentation 4 Monitor user status After all onboarding tasks have been processed, the user’s status will automatically change to ACTIVE. You can monitor these updates through the USER_ONBOARDING_UPDATE webhook, which provides real-time notifications for each verification stage. → See how to receive updates via webhooks Once the user reaches the ACTIVE status, they can start operating on the platform using any payment flow.
    • [Initial onboarding](https://docs.manteca.dev/cripto/onboarding-users/the-onboarding-process/create-user/create-user.md): Use this endpoint to create a new user and submit all available information in a single request. While sending a complete dataset is not mandatory — since the onboarding process supports incremental updates through individual tasks — we strongly recommend including as much data as possible from the start. Providing a full set of user information significantly increases the chances of instant approval, reducing the need for manual review or follow-ups. You can optionally include an externalId to link your internal user record with the one created in Manteca’s platform. ID images must still be uploaded separately using the Upload Identity Image endpoint . Common Errors BAD_REQUEST.PARAMS: Invalid parameters BAD_REQUEST.INVALID_EMAIL: Invalid email BAD_REQUEST.INVALID_ID_OR_COUNTRY: Either invalid legalId or wrong country BAD_REQUEST.EXTERNAL_ID: The externalId cannot be a purely numeric value CONFLICT.USER_EXISTS: User already exists BAD_REQUEST.INVALID_BANK_ACCOUNT: Invalid bank account BAD_REQUEST.INACTIVE_ADDRESS: The provided bank account is not active BAD_REQUEST.CUIT_MISMATCH: Bank account legalId differs from user legalId BAD_REQUEST.COIN_MISMATCH: Bank account currency differs from submitted currency CONFLICT.BANK_ACCOUNT_EXISTS: Bank account already exists
    • [Declare User Identity](https://docs.manteca.dev/cripto/onboarding-users/the-onboarding-process/create-user/declare-user-identity.md): This task allows you to declare or update a user’s legal identifier (for example, their national tax ID or personal identification number). It’s typically required when the legal ID was not provided during initial onboarding Once declared, the legal ID is used to perform compliance validations and identity checks as part of the onboarding process. A 204 No Content response indicates that the declaration was successfully processed. Monitor onboarding progress through the User Status Update webhook instead of polling.
    • [Define Personal Data](https://docs.manteca.dev/cripto/onboarding-users/the-onboarding-process/create-user/define-personal-data.md): This endpoint is use in conjunction with the onboarding stat endpoint to obtain the fields that are missing from the personal data.
    • [Upload Identity Image](https://docs.manteca.dev/cripto/onboarding-users/the-onboarding-process/create-user/upload-identity-image.md): In this step, you are required to upload the front and back images of the user's national ID. Both images must meet the following criteria: Clearly visible and well-lit Free of glare, cropping, or obstructions All text must be fully legible Must be in valid formats (preferably JPG or PNG) Once the request returns the signed URL, you must upload the document via an HTTP PUT request to that URL. The file must be sent in binary format
    • [Declare Political Constraints](https://docs.manteca.dev/cripto/onboarding-users/the-onboarding-process/create-user/declare-political-constraints.md): Declare a user’s political or regulatory exposure status . This endpoint records whether a user is classified under any political or financial compliance categories (such as FEP, FATCA, or PEP).
    • [Upload FEP Documentation](https://docs.manteca.dev/cripto/onboarding-users/the-onboarding-process/create-user/upload-uif-documentation.md): Read Uploading Documentations section for instructions on how to properly utilize this endpoint. For users subject to UIF regulations, the following documentation is required to proceed with compliance approval: Signed Affidavit (UIF DDJJ) – a sworn statement declaring compliance with AML regulations. UIF Compliance Certificate – official certificate confirming registration and compliance status.
    • [Upload PEP Documentation](https://docs.manteca.dev/cripto/onboarding-users/the-onboarding-process/create-user/upload-pep-documentation.md): Read Uploading Documentations section for instructions on how to properly utilize this endpoint. For users identified as Politically Exposed Persons, the following documentation is required to proceed with compliance approval: Signed Affidavit (PEP DDJJ) – a sworn statement declaring their PEP status. Proof of Source of Funds – supporting documents showing the origin of fund.
  • [Onboarding tasks](https://docs.manteca.dev/cripto/onboarding-users/the-onboarding-process/onboarding-tasks.md): Onboarding tasks define the compliance checks and data validations needed for a user to reach ACTIVE status. Most tasks are completed automatically via backend verifications, with minimal user input. Individual users The following tasks are typically required for individual users, which represent the majority of use cases on the platform: IDENTITY_DECLARATION Declaration of the user's legalId. This information is required to initiate the onboarding process and validate the user's tax identity. BASIC_PERSONAL_DATA_DEFINITION Definition of the user's personal information. Includes details such as name, gender, phone number, and other relevant personal data. WORK_DEFINITION Submission of the user's employment information. This task is usually completed automatically. POLITICAL_CONSTRAINTS_VALIDATION Automatic validation to determine if the user is classified as a Politically Exposed Person (PEP). This task is normally completed automatically. SECURITY_VALIDATION Compliance checks and security validations related to sanctions, watchlists, and other regulated sources. This task is completed automatically. BANK_ACCOUNT_DEFINITION Definition of the user's bank accounts. This information may be preloaded from the initial endpoint. PEP_DOCUMENTATION_VALIDATION Submission and validation of additional documentation required for users identified as Politically Exposed Persons (PEP). This task is not required if the user does not fall under this classification. FEP_DOCUMENTATION_VALIDATION Submission and validation of additional documentation required for users identified as obligated subjects under UIF regulations. This task is not required if the user does not fall under this classification. IDENTITY_VALIDATION Identity verification through images of the national ID (front and back). Once the images are successfully uploaded and validated, this task is marked as complete. The process is generally automatic and immediate.
• [Country requirements](https://docs.manteca.dev/cripto/onboarding-users/country-requirements.md): Onboarding requirements are quite similar across countries; however, certain data fields may be optional in some jurisdictions and mandatory in others. As a general rule, we recommend always providing as much information as possible, even though we have access to systems that allow us to retrieve additional details based on the legal IDs you provide.
  • [Argentina](https://docs.manteca.dev/cripto/onboarding-users/country-requirements/argentina.md): The legalId field can have either a CUIT/CUIL or a DNI as its value. If a DNI is provided, the value returned in this field will be the corresponding CUIT/CUIL. Users must upload images of their DNI (front and back) as acceptable indentity documentation. Some fields — such as legalId , sex , isPep , isFep , isFatca , phoneNumber , nationality , maritalStatus , and street — are required and must be submitted explicitly. Other fields may be auto-completed through integration with our third-party data providers. However, we strongly recommend providing all fields to ensure a smoother and more reliable onboarding process. The legalId field must match the CUIT format, validated using the following regular expression: /^\d{2}-?\d{8}-?\d{1}$/ , or the DNI format using /^[\d]{1,3}\.?[\d]{3}\.?[\d]{3}$/ . Here’s an example of a user creation request when using a CUIT: JSON { "externalId": "onboardingApiCryptoARG", "email": "onboardingapicryptoarg@manteca.dev", "legalId": "27284237728", "type": "INDIVIDUAL", // Optional (INDIVIDUAL Default) "exchange": "ARGENTINA", "personalData": { "name": "SABRINA PAULA", // Optional (This field might be automatically filled in) "surname": "SPAGNOLO", // Optional (This field might be automatically filled in) "sex": "F", // Optional (This field might be automatically filled in) "work": "SERVICIOS RELACIONADOS CON LA SALUD HUMANA N.C.P.", // Optional "birthDate": "1980-06-18", // Optional (This field might be automatically filled in) "isPep": false, // Required "isFatca": false, // Required "isFep": false, // Required "phoneNumber": "1155051018", // Required "nationality": "Argentina", // Required "maritalStatus": "Soltero", // Required "address": { "street": "SALALA 544", // Optional (This field might be automatically filled in) "postalCode": "1752", // Optional "locality": "LOMAS DEL MIRAD", // Optional "province": "BUENOS AIRES", // Optional "numeration": "1", // Optional "floor": "-", // Optional "apartment": "" // Optional } }, "banking": { // not required to complete onboarding "accounts": [ { "cbu": "1430001714039384360025", "currency": "USD", "description": "Cta USD" }, { "cbu": "1430001713039384360017", "currency": "ARS", "description": "Cta ARS" } ] } } }
  • [Brazil](https://docs.manteca.dev/cripto/onboarding-users/country-requirements/brazil.md): We admit the CPF as a valid legalId value. Image uploads are optional for operations totaling up to 1000 USD. Once they run out, if they must upload their identity card (Registro Geral). All subsequent operations will require the images, and missing them will trigger an error. Fields such as: legalId , sex , phoneNumber , maritalStatus , and street are required. Other fields may be auto-completed through integration with our third-party data providers. While they're optional to send, it's strongly recommended to provide all requested information to ensure a faster and smoother onboarding process. The legalId must be a CPF, validated using the regular expression /^[0-9]{3}[.]?[0-9]{3}[.]?[0-9]{3}-?[0-9]{2}$/ , or a CNPJ for companies, validated using /^[0-9]{2}[.]?[0-9]{3}[.]?[0-9]{3}\\/?[0-9]{4}-?[0-9]{2}$/ . Here’s an example of a user creation request: JSON { "externalId": "onboardingApiCryptoBRA", "email": "onboardingapicryptobra@manteca.dev", "legalId": "403.608.938-21", "type": "INDIVIDUAL", // Optional (INDIVIDUAL Default) "exchange": "BRAZIL", "personalData": { "name": "MARCOS PAULO", // Optional (This field might be automatically filled in) "surname": "ANDRADE PEDREIRA", // Optional (This field might be automatically filled in) "sex": "F", // Required "work": "SERVICIOS RELACIONADOS CON LA SALUD HUMANA N.C.P.", // Optional "birthDate": "1980-06-18", // Optional (This field might be automatically filled in) "isPep": false, // Optional (This field might be automatically filled in) "isFacta": false, // Optional (This field might be automatically filled in) "isFep": false, // Optional (This field might be automatically filled in) "phoneNumber": "511110442893", // Required "nationality": "Brasil", // Optional (This field might be automatically filled in) "maritalStatus": "Soltero", // Required "address": { "street": "PARAPUA", // Required "postalCode": "02831000", // Optional "locality": "SAO PAULO", // Optional "province": "SAO PAULO", // Optional "numeration": "854", // Optional "floor": "", // Optional "apartment": "" // Optional } }, "banking": { // not required to complete onboarding "accounts": [ { "cbu": "40360893821", "currency": "BRL", "description": "Cta BRL" } ] } }
  • [Chile](https://docs.manteca.dev/cripto/onboarding-users/country-requirements/chile.md): We admit the RUT as a valid legalId value. Image uploads are optional fore operations totalling up to 1000 USD. Once they run out, they must upload their identity card. All subsequent operations will require the images, and missing them will trigger an error. Fields such as: legalId , name , surname , sex , work , birthDate , isPep , isFep , isFatca , phoneNumber , nationality , maritalStatus , and street are required. Other fields may be auto-completed from the uploaded images. While they're optional to send, it is strongly recommended to provide all requested information to ensure a faster and smoother onboarding process. The legalId must be a RUT, validated using the regular expression /^\d{1,2}[.]?\d{3}[.]?\d{3}-?[0-9K]$/i . Here’s an example of a user creation request: JSON { "externalId": "onboardingApiCryptoCHL", "email": "onboardingapicryptochl@manteca.dev", "legalId": "248027371", "type": "INDIVIDUAL", // Optional (INDIVIDUAL Default) "exchange": "CHILE", "personalData": { "name": "MARTHA", // Required "surname": "ECHEVERRY PULGARIN", // Required "sex": "F", // Required "work": "SERVICIOS RELACIONADOS CON LA SALUD HUMANA N.C.P.", // Required "birthDate": "1980-06-18", // Required "isPep": false, // Required "isFacta": false, // Required "isFep": false, // Required "phoneNumber": "1155051019", // Required "nationality": "Chile", // Required "maritalStatus": "Soltero", // Required "address": { // Required "street": "Godoy 128", "postalCode": "5300000", "locality": "", "province": "Metropolitana de Santiago", "numeration": "1", "floor": "-", "apartment": "" } }, "banking": { // not required to complete onboarding "accounts": [ { "cbu": "17730024192", "currency": "CLP", "description": "Cta ARS" } ] } }
  • [Colombia](https://docs.manteca.dev/cripto/onboarding-users/country-requirements/colombia.md): We admit the CC as a valid legalId value. Images can be omitted for operations up to a total amount of 1000 USD. Once they run out, if they must upload their identity card (Cédula de ciudadanía / Cédula de extranjería / Permiso de protección temporal). Every subsequent user operation will trigger an error, requiring image uploads. Fields such as: legalId , name , surname , sex , birthDate , phoneNumber , nationality , maritalStatus, and street are required. While the remaining fields may be completed automatically, it is strongly recommended to provide all requested information — regardless of whether it is mandatory — to ensure a smoother onboarding process. The legalId must be a NUIP, validated using the regular expression /^\d{6,10}$/ . Here’s an example of a user creation request: JSON { "externalId": "onboardingApiCryptoCOL", "email": "onboardingapicryptocol@manteca.dev", "legalId": "31250162", "type": "INDIVIDUAL", // Optional (INDIVIDUAL Default) "exchange": "COLOMBIA", "personalData": { "name": "JAVIER", // Required "surname": "NAVAS", // Required "sex": "F", // Required "work": "SERVICIOS RELACIONADOS CON LA SALUD HUMANA N.C.P.", // Optional "birthDate": "1980-06-18", // Required "isPep": false, // Optional (This field might be automatically filled in) "isFacta": false, // Optional (This field might be automatically filled in) "isFep": false, // Optional (This field might be automatically filled in) "phoneNumber": "511110442880", // Required "nationality": "Colombia", // Required "maritalStatus": "Soltero", // Required "address": { "street": "Cra 93#129c-91", // Required "postalCode": "", // Optional "locality": "Bogotá ", // Optional "province": "Bogotá", // Optional "numeration": "1", // Optional "floor": "-", // Optional "apartment": "" // Optional } }, "banking": { // not required to complete onboarding "accounts": [ { "cbu": "24091034803", "currency": "COP", "description": "Cta COP" } ] } }
  • [Mexico](https://docs.manteca.dev/cripto/onboarding-users/country-requirements/mexico.md): We admit the CURP as a valid legalId value. Images are optional for operations up to a cumulative total of 1000 USD. Once they run out, if they must upload their voter identification card. Any new operation will return an error unless the corresponding images are uploaded. Fields such as legalId , name , surname , sex , birthDate , phoneNumber , nationality , maritalStatus , and street are required. The remaining fields may be completed automatically. However, to ensure a smoother onboarding experience, we strongly recommend providing all available data upfront — even if not strictly required. The legalId must be either a CURP, validated using the regular expression /^[A-Za-z]{4}[0-9]{6}[HMhm][A-Za-z]{5}[A-Za-z0-9][0-9]$/ or an RFC, validated using /^[A-Za-zÑñ&]{4}\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])[A-Za-z0-9]{3}|[A-Za-zÑñ&]{3}\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\d|3[01])[A-Za-z0-9]{3}$/ . Here’s an example of a user creation request: JSON { "externalId": "onboardingApiCryptoMEX", "email": "onboardingapicryptomex@manteca.dev", "legalId": "hecj720131hdfrnv00", "type": "INDIVIDUAL", // Optional (INDIVIDUAL Default) "exchange": "MEXICO", "personalData": { "name": "MARTHA", // Required "surname": "ECHEVERRY PULGARIN", // Required "sex": "F", // Required "work": "SERVICIOS RELACIONADOS CON LA SALUD HUMANA N.C.P.", // Optional (This field might be automatically filled in) "birthDate": "1980-06-18", // Optional (This field might be automatically filled in) "isPep": false, // Optional (This field might be automatically filled in) "isFacta": false, // Optional (This field might be automatically filled in) "isFep": false, // Optional (This field might be automatically filled in) "phoneNumber": "511110442881", // Required "nationality": "Mexico", // Required "maritalStatus": "Soltero", // Required "address": { "street": "Alfeñique 32 180", // Required "postalCode": "01549", // Optional "locality": "Álvaro Obregón", // Optional "province": "Ciudad de México", // Optional "numeration": "1", // Optional "floor": "-", // Optional "apartment": "" // Optional } }, "banking": { // not required to complete onboarding "accounts": [ { "cbu": "638180000132628778", "currency": "MXN", "description": "Cta MXN" } ] } }
  • [Costa rica](https://docs.manteca.dev/cripto/onboarding-users/country-requirements/costa-rica.md): We admit the CI / DIMEX (Cédula de identidad / DIMEX) as a valid legalId value. Images are optional for operations up to a cumulative total of 1000 USD. Once they run out, users must upload images of the document issued by the superior court of elections (front and back) as acceptable identity documentation. Any new operation will return an error unless the corresponding images are uploaded. Fields such as legalId , name , surname , sex , birthDate , phoneNumber , nationality , maritalStatus , and street are required. While the remaining fields may be completed automatically, we strongly recommend providing all requested information — even if optional — to ensure a smoother onboarding experience. The legalId must be a CI, validated using /^[1-9]{1}-?\d{4}-?\d{4}$/ , a CJ for companies, validated using /^[1-9]{1}-?\d{3}-?\d{6}$/ , or a DIMEX for foreign residents, validated using /^[1-2]\d{10,11}$/ . Here’s an example of a user creation request: JSON { "externalId": "onboardingApiCryptoCTR", "email": "onboardingapicryptoctr@manteca.dev", "legalId": "119210765", "type": "INDIVIDUAL", // Optional (INDIVIDUAL Default) "exchange": "COSTA_RICA", "personalData": { "name": "LUAN", // Required "surname": "ALMEIDA DOS SANTOS", // Required "sex": "F", // Required "work": "SERVICIOS RELACIONADOS CON LA SALUD HUMANA N.C.P.", // Required "birthDate": "1980-06-18", // Required "isPep": false, // Optional "isFacta": false, // Optional "isFep": false, // Optional "phoneNumber": "50671234567", // Required "nationality": "Costa rica", // Required "maritalStatus": "Soltero", // Required "address": { "street": "calle 22", // Required "postalCode": "10101", // Optional "locality": "", // Optional "province": "", // Optional "numeration": "854", // Optional "floor": "", // Optional "apartment": "" // Optional } }, "banking": { // not required to complete onboarding "accounts": [ { "cbu": "CR10015202001232143681", "currency": "CRC", "description": "Cta CRC" ] } }
  • [Panama](https://docs.manteca.dev/cripto/onboarding-users/country-requirements/panama.md): We admit the CIP (Cédula de Identidad Personal) as a valid legalId value. Images are optional for operations up to a cumulative total of 1000 USD. Once they run out, users must upload images of the document Issued by the electoral tribunal (front and back) as acceptable identity documentation. Any new operation will return an error unless the corresponding images are uploaded. Fields such as legalId , name , surname , sex , work , birthDate , phoneNumber , nationality , maritalStatus , and street are required. While the rest of the fields may be auto-completed, we strongly recommend submitting all available information to ensure a smooth and seamless onboarding process. The legalId must be a RUC, validated using the regular expression /^[1-9enEN]{1}-?\d{1,4}-?\d{1,5}$/ . Here’s an example of a user creation request: JSON { "externalId": "onboardingApiCryptoPAN", "email": "onboardingapicryptopan@manteca.dev", "legalId": "17601100", "type": "INDIVIDUAL", // Optional (INDIVIDUAL Default) "exchange": "PANAMA", "personalData": { "name": "Jhonnyel", // Required "surname": "Yosimar", // Required "sex": "F", // Required "work": "SERVICIOS RELACIONADOS CON LA SALUD HUMANA N.C.P.", // Required "birthDate": "1980-06-18", // Required "isPep": false, // Optional (This field might be automatically filled in) "isFacta": false, // Optional (This field might be automatically filled in) "isFep": false, // Optional (This field might be automatically filled in) "phoneNumber": "511110442883", // Required "nationality": "Panama", // Required "maritalStatus": "Soltero", // Required "address": { "street": "15", // Required "postalCode": "95366", // Optional "locality": "", // Optional "province": "Panamá", // Optional "numeration": "1", // Optional "floor": "-", // Optional "apartment": "" // Optional } }, "banking": { // not required to complete onboarding "accounts": [ { "cbu": "0415977065902", "currency": "PUSD", "description": "Cta PUSD" } ] } }
  • [Guatemala](https://docs.manteca.dev/cripto/onboarding-users/country-requirements/guatemala.md): We admit the CUI (Código único de identificación) as a valid legalId value. Images are optional for operations up to a cumulative total of 1000 USD. Once they run out, users must upload images of their DPI - Documento personal de identidad (front and back) as acceptable identity documentation. Any new operation will return an error unless the corresponding images are uploaded. Fields such as name , surname , sex , birthDate , phoneNumber , nationality , maritalStatus , and street are required. While the rest of the fields may be completed automatically, we strongly recommend providing all requested information — even if not strictly mandatory — to ensure a smoother onboarding experience. The legalId must be a CUI, validated using the regular expression /^\d{4}-?\d{5}-?\d{4}$/ . Here’s an example of a user creation request: JSON { "externalId": "onboardingApiCryptoGUA", "email": "onboardingapicryptogua@manteca.dev", "legalId": "3531848020101", "type": "INDIVIDUAL", // Optional (INDIVIDUAL Default) "exchange": "GUATEMALA", "personalData": { "name": "Madelyn", // Required "surname": "Salay", // Required "sex": "F", // Required "work": "SERVICIOS RELACIONADOS CON LA SALUD HUMANA N.C.P.", // Optional (This field might be automatically filled in) "birthDate": "1980-06-18", // Required "isPep": false, // Optional (This field might be automatically filled in) "isFacta": false, // Optional (This field might be automatically filled in) "isFep": false, // Optional (This field might be automatically filled in) "phoneNumber": "511110442886", // Required "nationality": "Guatemala", // Required "maritalStatus": "Soltero", // Required "address": { "street": "50-16 colonia santafaz zona 6", // Required "postalCode": "01006", // Optional "locality": "Chinautla", // Optional "province": "Guatemala", // Optional "numeration": "1", // Optional "floor": "-", // Optional "apartment": "" // Optional } }, "banking": { // not required to complete onboarding "accounts": [ { "cbu": "4600121380", "currency": "GTQ", "description": "Cta GTQ" } ] } }
  • [Philippines](https://docs.manteca.dev/cripto/onboarding-users/country-requirements/philippines.md): We admit the PhilID (Philippine National ID), license card, passport or PhilHealth as a valid legalId value. Images can be omitted for operations up to a total amount of 1000 USD. Once they run out, if they must upload their PhilID / license card. Every subsequent user operation will trigger an error, requiring image uploads. Fields such as name , surname , sex , birthDate , phoneNumber , nationality , maritalStatus , and street are required. While the remaining fields may be completed automatically, we strongly recommend providing all requested information — even if not strictly mandatory — to ensure a smoother onboarding experience. The legalId may be a Passport number, validated using /^[A-Za-z]{1,2}\d{6,7}[A-Za-z]?$/ , a PCN using /^\d{4}-?\d{4}-?\d{4}-?\d{4}$/ , a UMID using /^\d{4}-?\d{7}-?\d$/ , or a Driver’s License using /^[A-Za-z]{1}\d{2}-?\d{2}-?\d{6}$/ . Here’s an example of a user creation request: JSON { "externalId": "onboardingApiCryptoPHI", "email": "onboardingapicryptophi@manteca.dev", "legalId": "011197736998", "type": "INDIVIDUAL", // Optional (INDIVIDUAL Default) "exchange": "PHILIPPINES", "personalData": { "name": "ANIFLOR", // Required "surname": "FAJARDO", // Required "sex": "F", // Required "work": "SERVICIOS RELACIONADOS CON LA SALUD HUMANA N.C.P.", // Optional "birthDate": "1980-06-18", // Required "isPep": false, // Optional (This field might be automatically filled in) "isFacta": false, // Optional (This field might be automatically filled in) "isFep": false, // Optional (This field might be automatically filled in) "phoneNumber": "511110442887", // Required "nationality": "Samoa", // Required "maritalStatus": "Soltero", // Required "address": { "street": "BLK LOT 30 BALINGKIT ST", // Required "postalCode": "01006", // Optional "locality": "MALATE MANILA", // Optional "province": "PHL", // Optional "numeration": "1", // Optional "floor": "-", // Optional "apartment": "" // Optional } }, "banking": { // not required to complete onboarding "accounts": [ { "cbu": "09121631704", "currency": "PHP", "description": "Cta PHP" } ] } } We admit the PhilID (Philippine National ID), license card, passport or PhilHealth as a valid legalId value.
  • [Bolivia](https://docs.manteca.dev/cripto/onboarding-users/country-requirements/bolivia.md): We admit Bolivian national ID (cédula de identidad) as a valid legalId value. Images can be omitted for operations up to a total amount of 1000 USD. Once they run out, users must upload images of their national ID (front and back) as acceptable identity documentation. Any new operation will return an error unless the corresponding images are uploaded. Some fields — such as legalId , sex , birthDate , isPep , isFep , isFatca , phoneNumber , nationality , maritalStatus , and street — are required and must be submitted explicitly. Other fields can be auto-filled based on the information extracted from the ID, so they're optional to send. However, we strongly recommend providing all fields to ensure a smoother and more reliable onboarding process. The legalId must be a CI, validated using the following patterns: a pure numeric format /^\d{7,10}$/ , a prefix format with a departmental code /^[A-Z]{2}\d{7,10}$/ , or a suffix format /^\d{7,10}[A-Z]{2}$/ , where the department code must be one of BE, CB, CH, LP, OR, PD, PT, SC, TJ . JSON { "externalId": "onboardingApiCryptoBOB", "email": "onboardingapicryptobob@manteca.dev", "legalId": "7794988", "type": "INDIVIDUAL", "exchange": "BOLIVIA", "personalData": { "name": "SABRINA PAULA", "surname": "SPAGNOLO", "sex": "F", "work": "SERVICIOS RELACIONADOS CON LA SALUD HUMANA N.C.P.", "birthDate": "1980-06-18", "isPep": false, "isFatca": false, "isFep": false, "phoneNumber": "1155051020", "nationality": "Bolivia", "maritalStatus": "Soltero", "address": { "street": "SANCHEZ LIMA", "postalCode": "2520", "locality": "ANDRES IBAÑEZ", "province": "SANTA CRUZ DE LA SIERRA", "numeration": "2520", "floor": "-", "apartment": "" } }, "banking": { "accounts": [ { "cbu": "1566987425", "currency": "BOB", "description": "Cta BOB", "bank": { "code": "001" }, "accountType": "SAVINGS" } ] } }
  • [Peru](https://docs.manteca.dev/cripto/onboarding-users/country-requirements/peru.md): We admit Peruvian National ID (DNI) as a valid legalId value. Images can be omitted for operations up to a total amount of 1000 USD. Once they run out, users must upload images of their DNI (front and back) as acceptable identity documentation. Any new operation will return an error unless the corresponding images are uploaded. Some fields — such as legalId , sex , birthDate , isPep , isFep , isFatca , phoneNumber , nationality , maritalStatus , and address.street — are required and must be submitted explicitly. Other fields can be auto-filled from the ID OCR (so they’re optional to send). However, we strongly recommendproviding them to ensure a smoother and more reliable onboarding process. The type field is optional and defaults to INDIVIDUAL. Banking information is optional at onboarding time and can be added later. The legalId must be a DNI, validated using the regular expression /^\d{8}(\d|-\d)?$/ JSON { "externalId": "onboardingApiCryptoPeru", "email": "onboardingapicryptoperu@manteca.dev", "legalId": "47646968", "type": "INDIVIDUAL", "exchange": "PERU", "personalData": { "name": "HERNAN", "surname": "ACOSTA", / "sex": "X", "work": "SERVICIOS RELACIONADOS CON LA SALUD HUMANA N.C.P.", "birthDate": "1980-06-18", "isPep": false, "isFatca": false, "isFep": false, "phoneNumber": "+51912345678", "nationality": "Perú", "maritalStatus": "Soltero", "address": { "street": "SALALA", "postalCode": "1752", "locality": "LUCMA", "province": "GRAN CHIMU", "numeration": "544", "floor": "-", "apartment": "" } }, "banking": { "accounts": [ { "cbu": "00230005123456789021", "currency": "PEN", "description": "Cta PEN" } ] } }
• [Manual Operation](https://docs.manteca.dev/cripto/start-operating/manual-operation.md): We call manual operation to the process of manually creating the price locks, orders and withdraws with individual HTTP requests to separate endpoints, as opposed to, for example, doing it through a Synthetic or through a Widget . Read the Common Entities section to gain a better understading of what the entities look like.
  • [Locking a price](https://docs.manteca.dev/cripto/start-operating/manual-operation/locking-a-price.md): Locking a price allows you to reserve a certain price of a given operation for a few seconds or up to a few minutes depending on various factors, but mostly on the assets being operated, with stable coins against fiat allowing for longer time locks and trades of volatile assets requiring shorter time locks. Common Errors BAD_REQUEST.PARAMS: Invalid parameters NOT_FOUND.USER: User not found CONFLICT.USER_NOT_VALIDATED: User not able to operate CONFLICT.OPERATION_BLOCKED: Operation blocked FORBIDDEN.PERMISSIONS: Company has no such permission
  • [Creating an order](https://docs.manteca.dev/cripto/start-operating/manual-operation/creating-an-order.md): Creates an executes an exchange of one asset for another asset based on the current market price (or the price of the provided price lock), updating the corresponding User balance and performing all relevant accounting, compliance and notification operations. Common Errors BAD_REQUEST.PARAMS: Invalid parameters BAD_REQUEST.DUPLICATE_REQUEST: Same request executed too many times BAD_REQUEST.FUNDS: Insufficient funds BAD_REQUEST.EXPIRED_PRICE: Expired prices BAD_REQUEST.MICROOPERATIONS: Order cancelled due to microoperations (6 orders totaling less than $100). BAD_REQUEST.MIN_ORDER_SIZE: Invalid order size (min) BAD_REQUEST.EXTERNAL_ID: The externalId cannot be a purely numeric value BAD_REQUEST.INVALID_COIN: Invalid coin BAD_REQUEST.INVALID_COIN_COUNTRY: Invalid coin for user country FORBIDDEN.PERMISSIONS: Company has no such permission FORBIDDEN.MAX_CREDIT_REACHED: Max credit reached NOT_FOUND.USER: User not found NOT_FOUND.PRICE: Price not found CONFLICT.USER_BLOCKED: User blocked CONFLICT.USER_NOT_VALIDATED: User not able to operate CONFLICT.EXTERNAL_ID_ORDER_EXISTS: An order with the same external id already exists CONFLICT.USER_STATUS: User status does not allow this operation CONFLICT.OPERATION_BLOCKED: Operation blocked BAD_REQUEST.BLOCKED_UIF: User blocked due to missing fund origin or required ID documentation BAD_REQUEST.IS_PEP: User is a Politically Exposed Person (PEP); PEP documentation required BAD_REQUEST.IS_FACTA: User is a US national and cannot operate BAD_REQUEST.IS_UAF: User is classified as UAF and cannot operate BAD_REQUEST.IS_IN_LISTS: User is considered high risk and cannot operate BAD_REQUEST.IS_DEAD: User is considered high risk (deceased) and cannot operate BAD_REQUEST.IS_UNDER_AGE: User is underage and cannot operate BAD_REQUEST.HIGH_RISK: User is high risk and cannot operate CONFLICT.USER_NEEDS_EXTRA_DOC: User needs to provide additional documentation CONFLICT.USER_BLOCKED_FUNDS: User has blocked funds
  • [Requesting a withdraw](https://docs.manteca.dev/cripto/start-operating/manual-operation/requesting-a-withdraw.md): Withdrawals allow users to move funds from the platform to an external destination, either a fiat account or a blockchain address. While the interface remains the same for all withdrawal types, the required fields and validations vary depending on the destination country and the type of asset being withdrawn. The structure for initiating a withdrawal is unified, but depending on the context, certain fields—such as network, account type, or bank code—may be mandatory, optional, or ignored altogether. These variations are handled dynamically based on the country or asset involved. In most cases, withdrawal minimums are low — typically equivalent to 1 USD. Common errors BAD_REQUEST.VALIDATION: Validation error in input fields BAD_REQUEST.FUNDS: Insufficient funds BAD_REQUEST.INVALID_ADDRESS: Invalid withdraw address BAD_REQUEST.INVALID_ASSET: Asset not allowed for withdraw BAD_REQUEST.INVALID_COMPANY: Company not allowed for withdraw BAD_REQUEST.LIMIT: Withdraw limit exceeded CONFLICT.OPERATION_BLOCKED: Withdrawals are currently blocked for this asset/company CONFLICT.BALANCE_LOCKED: User balance is locked FORBIDDEN.USER_BLOCKED: User is blocked for withdrawals FORBIDDEN.COMPLIANCE: Compliance restriction for this operation NOT_FOUND.USER: User not foun
    • [Defining the destination](https://docs.manteca.dev/cripto/start-operating/manual-operation/requesting-a-withdraw/defining-the-destination.md): For FIAT payouts, field requirements depend heavily on the country. Some countries require specific network identifiers (such as PIX in Brazil or SPEI in Mexico), while others rely on more generic bank transfer rails. In certain jurisdictions, specifying the account type (e.g., checking or savings) is mandatory, whereas in others it may be inferred from the bank code or considered irrelevant. The bankCode field is typically used to identify the receiving institution. This field is mandatory in countries like Chile, and the expected format may vary depending on the local provider ecosystem. In most countries, the supported account types are limited to checking and savings. However, others introduce additional formats. For example, Mexico supports debit card numbers and phone-based accounts for some withdrawal networks, while Colombia supports phone-based transfers through Transfiya. Each country has a predefined set of accepted networks and account types. These are automatically enforced during validation and may evolve as banking infrastructure and local requirements change. In contrast to FIAT, crypto withdrawals are determined by the selected network rather than by country. Each supported blockchain network (such as Ethereum, Polygon, or Tron) can have its own address format and operational constraints. Fields like accountType or bankCode are not relevant in this context, but the network must always be explicitly defined. Country-specific requirements The structure and required fields for a withdrawal may vary depending on the country and payout method. Below is a breakdown of the country-specific rules, including which fields are required, what formats are accepted, and any relevant local nuances. For a full reference of the supported values used during validation—such as accepted networks, account types, and field requirements—you can refer to the Withdraw Constants Reference . Country Required fields Address Transfer speed Argentina - CBU / CVU / ALIAS Instant Brazil - PIX key (CPF, phone, email or random-key) Instant Chile bankCode , accountType Account number Instant Colombia network , bankCode , accountType Account number for BANK_TRANSFER (nequi) or phone number for TRANSFIYA Instant Mexico bankCode , accountType CLABE / card / phone Instant Panama bankCode , accountType Account number Up to 24hs Costa Rica bankCode , accountType Account number Up to 24hs Guatemala bankCode , accountType Account number Up to 24hs Philippines bankCode , accountType Account number Instant Crypto network Blockchain address Instant
    • [Withdrawal Examples](https://docs.manteca.dev/cripto/start-operating/manual-operation/requesting-a-withdraw/country-requirements-1.md): Here we’ll list a few example requests.
      • [Argentina](https://docs.manteca.dev/cripto/start-operating/manual-operation/requesting-a-withdraw/country-requirements-1/argentina.md): In this request, we initiate a withdrawal in Argentine pesos. The only required field is the address , which can be a CBU , CVU , or ALIAS . JSON { "externalId": "example-external-id-2475-2476", // Optional "sessionId": "<sessionId>-2475-2476", // Optional "userAnyId": "100009873", // Required "asset": "ARS", // Required "amount": "1000", // Required "destination": { "address": "1430001713039384360017" // Required } } Argentina – USD via BANK_TRANSFER Insert line topInsert line belowDeleteThis example shows a successful withdrawal of USD to an Argentine bank account using the BANK_TRANSFER network. JSON { "externalId": "example-external-id-1-usd", "sessionId": "example-session-id-1-usd", "userAnyId": "100008501", "network": "BANK_TRANSFER", "asset": "USD", "amount": "100", "destination": { "address": "0140420703690150418728" } }
      • [Brazil](https://docs.manteca.dev/cripto/start-operating/manual-operation/requesting-a-withdraw/country-requirements-1/brazil.md): In this request, we initiate a withdrawal in Brazilian reais. In this case, the only required field is the address , which must be a valid PIX key —either a CPF , phone number , email , or a random key . JSON { "externalId": "example-external-id-2459-2460", // Optional "sessionId": "<sessionId>-2459-2460", // Optional "userAnyId": "100009874", // Required "asset": "BRL", // Required "amount": "10", // Required "destination": { "address": "02103213262" // Required } }
      • [Chile](https://docs.manteca.dev/cripto/start-operating/manual-operation/requesting-a-withdraw/country-requirements-1/chile.md): In this request, we initiate a withdrawal in Chilean pesos. All three fields under destination are required: address , which must be a valid account identifier bankCode , identifying the receiving institution accountType , which in this case is RUT , used specifically with Banco Estado (code 317) JSON { "externalId": "example-external-id-2461-2462", // Optional "sessionId": "<sessionId>-2461-2462", // Optional "userAnyId": "100009875", // Required "asset": "CLP", // Required "amount": "10000", // Required "destination": { "address": "13033517", // Required "bankCode": "317", // Required "accountType": "RUT" // Required } }
      • [Colombia](https://docs.manteca.dev/cripto/start-operating/manual-operation/requesting-a-withdraw/country-requirements-1/colombia.md): In this request, we initiate a withdrawal in Colombian pesos. There are two supported payout routes: BANK TRANSFER : The funds are sent to a traditional bank account. If the bankCode corresponds to Bancolombia or Nequi (e.g. 1007 or 1507), the transaction will be routed through Nequi’s internal rails for faster delivery. The following fields are required: address : the destination account number bankCode : the receiving institution accountType : typically SAVINGS or CHECKING TRANSFIYA : The funds are delivered via phone number using Colombia’s phone-based transfer network. The required fields are: address : a valid Colombian phone number accountType : must be set to PHONE Both routes are supported and selected automatically based on the provided data. Examples follow. Bank transfer (nequi) JSON { "externalId": "example-external-id-2467-2468", // Optional "sessionId": "<sessionId>-2467-2468", // Optional "userAnyId": "100009876", // Required "asset": "COP", // Required "amount": "800.00", // Required "destination": { "address": "3172655787", // Required "bankCode": "1507", // Required "accountType": "SAVINGS" // Required } } Transfiya JSON { "externalId": "example-external-id-2467-2468", // Optional "sessionId": "<sessionId>-2467-2468", // Optional "userAnyId": "100009876", // Required "asset": "COP", // Required "amount": "800.00", // Required "destination": { "address": "+573203159329", // Required "accountType": "PHONE" // Required } }
      • [Mexico](https://docs.manteca.dev/cripto/start-operating/manual-operation/requesting-a-withdraw/country-requirements-1/mexico.md): In this request, we initiate a withdrawal in Mexican pesos. The required fields under destination include address , which in this case is a debit card number , bankCode identifying the institution, and accountType set to DEBIT to indicate a card-based payout. JSON { "externalId": "example-external-id-2467-2468", // Optional "sessionId": "<sessionId>-2467-2468", // Optional "userAnyId": "100009877", // Required "asset": "MXN", // Required "amount": "100", // Required "destination": { "address": "4189143297879093", // Required "bankCode": "002", // Required "accountType": "DEBIT" // Required } }
      • [Costa Rica](https://docs.manteca.dev/cripto/start-operating/manual-operation/requesting-a-withdraw/country-requirements-1/costa-rica.md): In this request, we initiate a withdrawal in Costa Rican colones. All three fields under destination are required: address , which must be a valid account number bankCode , identifying the receiving bank accountType , which in this case is set to SAVINGS JSON { "externalId": "example-external-id-2457-2458", // Optional "sessionId": "<sessionId>-2457-2458", // Optional "userAnyId": "100009881", // Required "asset": "CRC", // Required "amount": "500", // Required "destination": { "address": "CR14010200009650656758", // Required "bankCode": "0102", // Required "accountType": "SAVINGS" // Required } }
      • [Panama](https://docs.manteca.dev/cripto/start-operating/manual-operation/requesting-a-withdraw/country-requirements-1/panama.md): In this request, we initiate a withdrawal in Panamanian dollars (PUSD). All destination fields are required: address , representing the bank account number bankCode , identifying the receiving institution accountType , set to SAVINGS to specify the type of account JSON { "externalId": "example-external-id-2471-2472", // Optional "sessionId": "<sessionId>-2471-2472", // Optional "userAnyId": "100009878", // Required "asset": "PUSD", // Required "amount": "100", // Required "destination": { "address": "117353318", // Required "bankCode": "0026", // Required "accountType": "SAVINGS" // Required } }
      • [Guatemala](https://docs.manteca.dev/cripto/start-operating/manual-operation/requesting-a-withdraw/country-requirements-1/guatemala.md): In this request, we initiate a withdrawal in Guatemalan quetzales (GTQ). All destination fields are required: address , which must be a valid bank account number bankCode , identifying the receiving institution accountType , set to SAVINGS to indicate the account type used for the payout JSON { "externalId": "example-external-id-2465-2466", // Optional "sessionId": "<sessionId>-2465-2466", // Optional "userAnyId": "100009879", // Required "asset": "GTQ", // Required "amount": "100", // Required "destination": { "address": "32992083658602", // Required "bankCode": "049", // Required "accountType": "SAVINGS" // Required } }
      • [Philippines](https://docs.manteca.dev/cripto/start-operating/manual-operation/requesting-a-withdraw/country-requirements-1/philippines.md): In this request, we initiate a withdrawal in Philippine pesos (PHP). The payout is processed via Instapay , a real-time transfer network. All destination fields are required: address , which must be a valid account identifier bankCode , identifying the receiving institution (in this case, shopeepay ) accountType , set to SAVINGS to define the destination account type JSON { "externalId": "example-external-id-2469-2470", // Optional "sessionId": "<sessionId>-2469-2470", // Optional "userAnyId": "100009880", // Required "asset": "PHP", // Required "amount": "100", // Required "destination": { "address": "09931984160", // Required "bankCode": "shopeepay", // Required "accountType": "SAVINGS" // Required } }
      • [Crypto](https://docs.manteca.dev/cripto/start-operating/manual-operation/requesting-a-withdraw/country-requirements-1/crypto.md): In this request, we initiate a crypto withdrawal of USDC over the Ethereum network. Both network and address fields are required under destination : network specifies the blockchain to use, in this case ETHEREUM address must be a valid Ethereum wallet address compatible with ERC-20 tokens For crypto withdrawals, it is possible to lock the cost of the withdrawal for a short period of time. This is done via the lock withdraw endpoint, which returns a withdrawLockCode . To proceed with the withdrawal using the locked fee, you must include the withdrawLockCode field in your request to the withdraw endpoint. JSON { "externalId": "example-external-id-2581-2582", // Optional "sessionId": "<sessionId>-2581-2582", // Optional "userAnyId": "100009881", // Required "asset": "USDC", // Required "amount": "5", // Required "destination": { "network": "ETHEREUM", // Required "address": "0x4cD0820ca71Bda1A6cEfe1A6D5a2F6E50D4370f2" // Required }, "withdrawLockCode": "2223bb5b-0e48-4b8a-a908-30e475c1a50c" // Optional }
      • [Bolivia](https://docs.manteca.dev/cripto/start-operating/manual-operation/requesting-a-withdraw/country-requirements-1/bolivia.md): In this request, we initiate a withdrawal in Bolivian pesos (BOB). The required fields are the userAnyId, asset, amount, destination.address, destination.bankCode, and destination.accountType. The optional fields are externalId and sessionId. JSON { "externalId": "example-external-id-1-bob", // Optional "sessionId": "example-session-id-1-bob", // Optional "userAnyId": "100010879", // Required "asset": "BOB", // Required "amount": "1000", // Required "destination": { "address": "1566987425", // Required "bankCode": "001", // Required "accountType": "SAVINGS" // Required } }
      • [Peru](https://docs.manteca.dev/cripto/start-operating/manual-operation/requesting-a-withdraw/country-requirements-1/peru.md): In this request, we initiate a withdrawal in Peruvian soles (PEN). The required fields are userAnyId, asset, amount, destination.address, destination.bankCode, and destination.accountType. Optional fields include externalId and sessionId, which can be used for idempotency or internal tracking. JSON { "externalId": "example-external-id-1", // Optional "sessionId": "example-session-id-1", // Optional "userAnyId": "100011377", // Required "asset": "PEN", // Required "amount": "100", // Required "destination": { "address": "00304501310423639320", // Required "network": "BANK_TRANSFER", // Required "bankCode": "002", // Required "accountType": "SAVINGS" // Required } }
  • [Processing a deposit](https://docs.manteca.dev/cripto/start-operating/manual-operation/requesting-a-deposit.md): Deposits allow users to move funds from an external source into the platform, either from a fiat account or a blockchain address. While the interface remains consistent across all deposit types, the required fields and validations vary depending on the origin country and the type of asset being deposited. For details on the supported assets (both fiat and crypto), please refer to the networks section . For deposits through static accounts (the currently supported method), the flow is always the same: Use the endpoint below to obtain the correct account or address details. Once the deposit is made, a webhook notification will be sent confirming the transaction. In addition, deposits can be queried through the deposit endpoints . In all cases, balances are updated immediately once the transaction is confirmed, and the funds become available for use. This endpoint provides the required information to initiate a deposit on the platform. It must be called before submitting any deposit request, as it returns the appropriate account or address to which the funds should be sent, based on the requested asset. The information is generated dynamically according to the companyId associated with the authentication token.
• [Synthetics (Automatic Operation)](https://docs.manteca.dev/cripto/start-operating/synthetics-automatic-operation.md): We understand some flows are very common and companies would like a simplified version of said flows. In order to respond to this demand we developed some automatization tools, in particular what we call Synthetics, which will simplify and automate some common operations, like for example detect a deposit, create an order for the amount that was deposited and then withdraw the result of the order to a certain address, flow that we call a ramp operation. A Synthetic is an entity which consists of a series of stages that will be executed in order according to certain logic. One example of this would be a ramp operation, where it waits for a deposit to arrive, once it detects one it creates an order based on the received amount, and finally once the order is complete it withdraws the resulting amount to a given address. Handling Expired Synthetics Synthetics without overdraft (i.e., those with a deposit trigger waiting for a deposit to start) can expire. When that happens, they move to CANCELLED status. If the user makes the deposit after expiration, the deposit will not be executed.To safeguard against this issue, the synthetic can be recreated with the following parameters: JSON { "skipDeposit": true, "disallowDebt": true } This ensures the flow consumes the funds already available in the user's balance instead of waiting for new deposits. Common Errors BAD_REQUEST.PARAMS: Invalid parameters BAD_REQUEST.FUNDS: Insufficient funds BAD_REQUEST.EXPIRED_PRICE: Expired prices BAD_REQUEST.EXTERNAL_ID: The externalId cannot be a purely numeric value BAD_REQUEST.INVALID_COIN: Invalid coin BAD_REQUEST.INVALID_COIN_COUNTRY: Invalid coin for user country FORBIDDEN.PERMISSIONS: Company has no such permission NOT_FOUND.USER: User not found NOT_FOUND.PRICE: Price not found CONFLICT.USER_BLOCKED: User blocked CONFLICT.USER_NOT_VALIDATED: User not able to operate CONFLICT.SYNTHETIC_EXISTS: Synthetic with given ids already exists CONFLICT.SYNTHETIC_STATUS: Synthetic status does not allow this operation CONFLICT.SYNTHETIC_TYPE: Synthetic type does not allow this operation CONFLICT.OPERATION_BLOCKED: Operation blocked CONFLICT.QR_PAYMENT: QR-PAYMENT generic error CONFLICT.QR_STATUS: Given QR payment is already paid or expired CONFLICT.QR_AMOUNT: Given QR payment requires amount to be provided in order to acquire the lock BAD_REQUEST.QR_CODE: QR code seems to be invalid BAD_REQUEST.BLOCKED_UIF: User blocked due to missing fund origin or required ID documentation BAD_REQUEST.IS_PEP: User is a Politically Exposed Person (PEP); PEP documentation required BAD_REQUEST.IS_FACTA: User is a US national and cannot operate BAD_REQUEST.IS_UAF: User is classified as UAF and cannot operate BAD_REQUEST.IS_IN_LISTS: User is considered high risk and cannot operate BAD_REQUEST.IS_DEAD: User is considered high risk (deceased) and cannot operate BAD_REQUEST.IS_UNDER_AGE: User is underage and cannot operate BAD_REQUEST.HIGH_RISK: User is high risk and cannot operate CONFLICT.USER_NEEDS_EXTRA_DOC: User needs to provide additional documentation CONFLICT.USER_BLOCKED_FUNDS: User has blocked funds FORBIDDEN.RISKY_WITHDRAW_ADDRESS: Dest crypto address is risky
  • [Create a Ramp On Synthetic](https://docs.manteca.dev/cripto/start-operating/synthetics-automatic-operation/create-a-ramp-operation-synthetic.md): A Ramp On operation consists of sending fiat, buying a crypto asset with said fiat and then withdrawing those recently bought crypto assets to a given wallet.
  • [Create a Ramp Off Synthetic](https://docs.manteca.dev/cripto/start-operating/synthetics-automatic-operation/create-a-ramp-off-synthetic.md): A Ramp Off operation consists of sending crypto assets, selling said crypto assets against a certain fiat currency and then withdrawing the fiat amount to a bank account belonging to the User. For the examples of the destination field for each country, please refer to the Defining the destination section, as the structure is exactly the same.
  • [Create a Partial Ramp On Synthetic](https://docs.manteca.dev/cripto/start-operating/synthetics-automatic-operation/create-a-partial-ramp-on-synthetic.md): A partial Ramp On operation consists of sending fiat and then buying a crypto asset with said fiat.
  • [Create a Partial Ramp Off Synthetic](https://docs.manteca.dev/cripto/start-operating/synthetics-automatic-operation/create-a-partial-ramp-off-synthetic.md): A partial Ramp Off operation consists of sending crypto assets and then selling said crypto assets against a certain fiat currency.
  • [Create a QR Payment Synthetic](https://docs.manteca.dev/cripto/start-operating/synthetics-automatic-operation/create-a-pix-payment-synthetic.md): You need to Lock QR payment before using this endpoint. A QR Payment consists of two steps: a local currency conversion operation (typically to USDT), followed by the actual payment using a supported method. Currently, we support PIX payments (Brazil), QR 3.0 payments (Argentina), and QR payments Peru. Alternatively, the initial conversion step can be skipped if the user already holds the target settlement currency. For example, the user can prefund their balance with ARS or BRL, and the amount will be debited directly from that fiat balance. It’s also possible to use USDT directly, in which case USDT will be debited and the system will automatically convert it to the merchant’s settlement currency (ARS or BRL) before executing the payment. If the payment is successful, the synthetic will move to the COMPLETED status. If an error occurs, the synthetic will transition to CANCELLED , and a reversal of the operation will be performed (if applicable), returning the funds to the original balance from which they were deducted. Common Errors General synthetic errors may occur, and in particular, the following are specific to QR payments: CONFLICT.QR_PAYMENT: QR-PAYMENT generic error CONFLICT.QR_STATUS: Given QR payment is already paid or expired CONFLICT.OPERATION_BLOCKED: Operation is temporarily blocked BAD_REQUEST.NO_FUNDS: User has not funds to execute the operation BAD_REQUEST.EXPIRED_LOCK: Payment lock code already expired BAD_REQUEST.MIN_ORDER_SIZE: Occurs when the order amount is below the exchange’s minimum size — often after converting to USDT.
  • [Create a Bill Payment Synthetic](https://docs.manteca.dev/cripto/start-operating/synthetics-automatic-operation/create-a-bill-payment-synthetic.md): A bill payment consists of two steps: first, retrieving the service information and validating the amount to be paid, and second, executing the actual payment using a supported local method. Currently, we support bill payments in Argentina. If the user already holds the required settlement currency, the payment amount will be debited directly from that balance (e.g., ARS). Alternatively, the user may hold USDT, in which case USDT will be debited, and the system will automatically convert it to the biller’s settlement currency before executing the payment. If the payment is successful, the synthetic moves to the COMPLETED status. If an error occurs, the synthetic transitions to CANCELLED , and a reversal is performed when applicable, returning the funds to the original balance from which they were deducted. Common Errors General synthetic errors may occur, and in particular, the following are specific to QR payments: CONFLICT.QR_PAYMENT: QR-PAYMENT generic error CONFLICT.QR_STATUS: Given QR payment is already paid or expired CONFLICT.OPERATION_BLOCKED: Operation is temporarily blocked BAD_REQUEST.NO_FUNDS: User has not funds to execute the operation BAD_REQUEST.EXPIRED_LOCK: Payment lock code already expired BAD_REQUEST.MIN_ORDER_SIZE: Occurs when the order amount is below the exchange’s minimum size — often after converting to USDT.
• [Widgets (Front-end as a service)](https://docs.manteca.dev/cripto/start-operating/widgets-front-end-as-a-service.md): Widgets are our solution for those companies that do not desire to build a new user-facing interface to get integrated into our systems, and simply wish to redirect their users to one of our widgets to perform the necessary operations and then await for the response of said operation to continue. We have a few of these widgets available to perform complex operations like the onboarding of a new user, including the respective KYC requirements, or the creation of a ramp operation, as well as the possibility to chain widgets one after the other. The flow of a widget consists of 3 simple steps: 1 Generate a new widget URL With your company API Key you can requests a new widget url for a given flow, like for example onboarding or ramp operation or onboarding followed by a ramp operation, etc. In this first request you can provide the necessary configuration to determine the behaviour of the widget, like for example determining the return url (the url the user is redirected to after widget ends) or the externalId to assign the created user (in the onboarding widget) or the details of the ramp operation like the asset, amount, withdraw network, etc. 2 Redirect user to the URL Once you have generated the URL you simply need to redirect your user to that URL and they will be presented with the visual interface to perform the corresponding operation. The authentication is embedded into the URL so no other extra action is required. 3 Await for the response During the generation of the URL you defined a returnUrl, and optionally a failureUrl. A GET HTTP Request will be sent to that URL once the user finalized utilizing the widget, and in the query parameters of said url we will send you all the relevant information that was generated during the use of the widget. You can also listen to corresponding system events through our notification system (read Notifications for more information). Widgets can be chained together, meaning that you can create an Onboarding widget that once it ends redirects the newly created user to an Operation widget, and since the Onboarding widget instantly ends if User already exists you can use the same chain of widgets even for existing Users and they will all be redirected to an Operation widget. Onboarding Widget For details about the onboarding process read The Onboarding Process first. The onboarding widget guides the users through the whole onboarding process, from the creation of the initial user, the uploading of the required documentation and data to comply with the KYC requirements, and the validation of the user's identity. Operation Widget The operation widget runs as soon as the user is redirected to it, based on the initial configuration it will perform the required steps of obtaining and locking a price, validating all compliance requirements, setting up all automatic rules and then, based on the configuration, either immediately perform the operation against debt or present the user with a screen indicating where and how much to send funds in order to continue the operation. In the latter scenario once a deposit is detected it will perform the operation using the funds it received.
  • [Generate Onboarding Widget URL](https://docs.manteca.dev/cripto/start-operating/widgets-front-end-as-a-service/generate-onboarding-widget-url.md)
  • [Generate Operation Widget URL](https://docs.manteca.dev/cripto/start-operating/widgets-front-end-as-a-service/generate-operation-widget-url.md)
• [Users](https://docs.manteca.dev/cripto/common-entities/users.md): Read Onboarding Users section for more information about how the User entity is created and the onboarding tasks required to make the User active. After the onboarding process has been started, the user entity represents the account of that individual for your company. The same individual cannot have more than one user per company, although it is possible for the same individual to have more than one user under different companies, in which case it will share the same operation limits across all companies (Read People, not Users for more information). Interface TypeScript interface IUser { // The id of the user, a 24 hex string. id: string // The number id of the user, a positive integer. numberId: string // Company defined id for the user. externalId?: string // Session id associated with the user. sessionId?: string // Email address of the user email: string // The current status of the user. status: USER_STATUS // The type of user, only INDIVIDUAL for now but support for companies as users is in development. type: USER_TYPE // This is the exchange the user will operate in. exchange: EXCHANGE // Banking information of the user banking: { // Accounts associated with the user. accounts: IBankAccount[] } // Information about the associated crypto deposit addresses for this user. addresses: { // A transfer to a deposit address indicates the value of the transfer belongs to this user depositAddresses: { [network: string]: string } // A transfer from a known address to our shared deposit addresses indicates the transfer belongs to this user. knownAddresses: string[] } // The id to the corresponding Fee Info this user is bound by, if undefined then it would be the default main Fee Info. feeInfoId?: string // This property holds a summary of all the onboarding tasks the user has taken as well as their status. onboarding: IUserOnboarding // Time the user was created as an ISO 8601 Date String. creationTime: string // Time the user was last updated at as an ISO 8601 Date String. updatedAt: string } Bank Account Interface TypeScript interface IBankAccount { cbu: string currency: FIAT_ASSETS description: string } User Onboarding Interface TypeScript interface IUserOnboarding { // Email validation entails sending a confirmation link to the user email and having the user click on that link. Usually not required. emailValidation: IOnboardingTaskInfo // This task entails providing us with a valid legal ID number for the corresponding exchange the user is in (for example CUIT/CUIL in Argentina). Always required. identityDeclaration: IOnboardingTaskInfo // This task entails defining all the basic personal data we are mandated to collect from the user, in some cases this task is automatically completed during identityDeclaration task. Usually required. basicPersonalDataDefinition: IOnboardingTaskInfo // This task entails defining the user work condition and the type of work they do. Usually not required. workDefinition: IOnboardingTaskInfo // This task entails uploading images of the previously declared legal ID which will then be verified by our compliance systems. Usually required. identityValidation: IOnboardingTaskInfo // This task entails having the user read and accept the Terms and Conditions. Usually required. tycAcceptance: IOnboardingTaskInfo // This task entails having the user declare their political constraints (things like UIF/PEP/FATCA etc), which will then be verified by our compliance systems. Usually required. politicalConstraintsValidation: IOnboardingTaskInfo // This task entails checking against databases of known terrorists as well as other security databases to ensure this individual is not blacklisted. Usually required. securityValidation: IOnboardingTaskInfo // This task entails uploading images of the face of the user. Usually not required. selfieValidation: IOnboardingTaskInfo // This task can be set to required after the politicalConstraintsValidation task. It entails uploading the corresponding UIF documentation. Usually not required. uifDocumentationValidation: IOnboardingTaskInfo // This task can be set to required after the politicalConstraintsValidation task. It entails uploading the corresponding PEP documentation. Usually not required. pepDocumentationValidation: IOnboardingTaskInfo // This task entails providing and validating a phone number. Usually not required. phoneNumberValidation: IOnboardingTaskInfo } interface IOnboardingTaskInfo { // If true then this user requires this task to be completed in order to continue operating, if false then it is not required for this user. required: boolean // The status of this task. status: ONBOARDING_TASK_STATUS // If task was rejected, here a message will appear explaining the reason for the rejection. rejectionReason?: string } Possible Statuses A user can have multiple statuses, these are: Title Description Status Meaning ONBOARDING Means the user has not completed the minimal onboarding requirements. ACTIVE Means the user has completed enough of the onboarding to be able to perform at least one operation. They might still need to perform other tasks in order to unlock other features. INACTIVE Means the user was deleted or made inactive. Example JSON { "id": "6762a062183af03b822f7a71", "numberId": "10001", "externalId": "example-external-id-1", "sessionId": "example-session-id-1", "email": "example@email.com", "status": "ACTIVE", "type": "INDIVIDUAL", "exchange": "ARGENTINA", "banking": { "accounts": [ { "cbu": "999999999999999", "currency": "ARS", "description": "Supervielle" } ] }, "addresses": { "depositAddresses": { "BINANCE": "0xaA7B65Cc73500b722FACb0722b4D3AEafE60eB68", "ETHEREUM": "0xaA7B65Cc73500b722FACb0722b4D3AEafE60eB68", "ARBITRUM": "0xaA7B65Cc73500b722FACb0722b4D3AEafE60eB68", "TERRA": "terra1jun4lrhyyx0jp3f0z2d34p7vrnh2zvvm09p8xq", "TERRA2": "terra1jun4lrhyyx0jp3f0z2d34p7vrnh2zvvm09p8xq", "POLYGON": "0xaA7B65Cc73500b722FACb0722b4D3AEafE60eB68", "BASE": "0xaA7B65Cc73500b722FACb0722b4D3AEafE60eB68", "ROOTSTOCK": "0xaA7B65Cc73500b722FACb0722b4D3AEafE60eB68", "OPTIMISM": "0xaA7B65Cc73500b722FACb0722b4D3AEafE60eB68", "WORLDCHAIN": "0xaA7B65Cc73500b722FACb0722b4D3AEafE60eB68" }, "knownAddresses": [] }, "feeInfoId": "678c5562b709beffdb4e37ba", "onboarding": { "emailValidation": { "required": false, "status": "NOT_DONE" }, "identityDeclaration": { "required": true, "status": "COMPLETED" }, "basicPersonalDataDefinition": { "required": true, "status": "COMPLETED" }, "workDefinition": { "required": true, "status": "COMPLETED" }, "identityValidation": { "required": true, "status": "COMPLETED" }, "tycAcceptance": { "required": true, "status": "COMPLETED" }, "politicalConstraintsValidation": { "required": true, "status": "COMPLETED" }, "securityValidation": { "required": true, "status": "COMPLETED" }, "selfieValidation": { "required": false, "status": "NOT_DONE" }, "uifDocumentationValidation": { "required": false, "status": "NOT_DONE" }, "pepDocumentationValidation": { "required": false, "status": "NOT_DONE" }, "phoneNumberValidation": { "required": false, "status": "NOT_DONE" } }, "creationTime": "2024-12-13T12:26:03.792-03:00", "updatedAt": "2024-12-13T12:26:34.911-03:00" }
• [User balances](https://docs.manteca.dev/cripto/common-entities/user-balances.md): Each user has an associated balance entity, where we hold its current balance. Unlike other entities it does not have IDs of its own but rather it utilizing the same IDs as the user. User balance can be locked so it cannot be used as well as unlocked, this is done through a pair of endpoints. Read Locking User Balance for more information. Interface TypeScript interface IUserBalance { // The id of the user, a 24 hex string. userId: string // The number id of the user, a positive integer. userNumberId: string // The company defined external id of the user. userExternalId?: string // The balance of the user is a map of asset name to decimal form amount. balance: { // For example "ARS": "1534.32" [asset: string]: string } // Locked balance is balance that cannot be used for any reason, balance can be locked or unlocked as required. lockedBalance: { // For example "ARS": "1534.32" [asset: string]: string } // The time of the creation of the entity as an ISO 8601 Date String. creationTime: string // The time the entity was last updated at as an ISO 8601 Date String. updatedAt: string } Example JSON { "userId": "6762a062183af03b822f7a71", "userNumberId": "10001", "userExternalId": "example-external-id-1", "balance": { "ARS": "10000.00", "USD": "200.00", "USDT": "25.123456789012345678" }, "lockedBalance": { "USD": "15.25" }, "creationTime": "2024-12-13T12:22:54.290-03:00", "updatedAt": "2024-12-13T12:22:54.290-03:00" }
• [Deposits](https://docs.manteca.dev/cripto/common-entities/deposits.md): A deposit entity is created automatically whenever funds arrive to one of our system addresses, through any of our supported networks. Read Networks section for more information. Interface TypeScript interface IDeposit { // The id of the deposit, a 24 hex string. id: string // The number id of the deposit, a positive integer. numberId: string // An optional id defined by your company either through our automatization systems or manually after deposit was created. externalId?: string // Session id associated with the deposit. sessionId?: string // The id of the user the deposit corresponds to, a 24 hex string. userId: string // The number id of the user the deposit corresponds to, a positive integer. userNumberId: string // The external id of the user, as defined by the company. userExternalId?: string // The legalId of the user userLegalId?: string // The asset being depositted. asset: string // The decimal amount being depositted. amount: string // The address from which the funds were sent. source: string // The network through which it is being sent. network: NETWORKS // The id inside the network to identify the transaction. networkId: string // The time the entity was created. creationTime: string // The time the entity was last updated. updatedAt: string } Example JSON { "id": "67613eb255ae7a04e6f9679e", "numberId": "100001", "externalId": "example-external-id-1", "sessionId": "example-session-id-1", "userId": "6762a062183af03b822f7a71", "userNumberId": "10001", "userExternalId": "example-external-id-1", "asset": "USDT", "amount": "15385.3", "source": "0x93e854d2507de1c9d9c278c0d706abe25e86ff2c", "network": "BINANCE", "networkId": "0x57851953a0592dce779d286e7a6053d82a3a8193a6e7b312246eb016b60c59db", "creationTime": "2024-12-13T12:22:54.290-03:00", "updatedAt": "2024-12-13T12:22:54.290-03:00" }
• [Withdraws](https://docs.manteca.dev/cripto/common-entities/withdraws.md): A withdraw consists of taking funds out of our system and sending them to an external address through a certain external network. These networks can be either blockchains or banking systems. Interface TypeScript interface IWithdraw { // The id of the withdraw, a 24 hex string. id: string // The number id of the withdraw, a positive integer. numberId: string // An optional id defined by your company at the time of the creation of the withdraw. externalId?: string // Session id associated with the withdraw. sessionId?: string // The id of the user making the withdraw, a 24 hex string. userId: string // The number id of the user making the withdraw, a positive integer. userNumberId: string // The external id of the user, as defined by the company. userExternalId?: string // The legal id of the user userLegalId?: string // The asset being withdrawn. asset: string // The decimal amount being withdrawn. amount: string // The address where te funds are being sent to. destination: string // The network through which it is being sent. network: NETWORKS // The id inside the network to identify the transaction, undefined at first but added as soon as it is defined by the network. networkId?: string // The status of the transaction. status: WITHDRAW_STATUS // Present if status is CANCELLED, explains the reason for the cancellation statusMessage?: string // The time the entity was created. creationTime: string // The time the entity was last updated. updatedAt: string } Possible Statuses A withdraw can have multiple statuses, these are: Title Description Status Meaning PENDING The user passed all compliance checks and had enough funds to make the withdraw, the withdraw entity was created and a request was made to the corresponding network to send the funds. EXECUTED The withdraw was confirmed succesful by the network and it is safe to assume the destination has received the funds correctly. CANCELLED The withdraw was cancelled and the used funds were refunded, this is a final status and a new withdraw should be attempted after resolving the reason for the cancellation. Example with success JSON { "id": "67613eb255ae7a04e6f9679e", "numberId": "100001", "externalId": "example-external-id-1", "sessionId": "example-session-id-1", "userId": "6762a062183af03b822f7a71", "userNumberId": "10001", "userExternalId": "example-external-id-1", "asset": "USDT", "amount": "15385.3", "destination": "0x93e854d2507de1c9d9c278c0d706abe25e86ff2c", "network": "BINANCE", "networkId": "0x57851953a0592dce779d286e7a6053d82a3a8193a6e7b312246eb016b60c59db", "status": "EXECUTED", "creationTime": "2024-12-13T12:22:54.290-03:00", "updatedAt": "2024-12-13T12:22:54.290-03:00" } Example with error JSON { "id": "67f5dd745666ae4bc50acbc7", "numberId": "100003823", "network": "BANKTRANSFER", "userId": "67efb891d88082731ebccbcf", "userNumberId": "100007516", "userLegalId": "20297585240", "status": "CANCELLED", "statusMessage": "D1: Document number does not match account", "asset": "ARS", "amount": "2.00", "destination": "999999999999995", "creationTime": "2025-04-08T23:37:40.694-03:00", "updatedAt": "2025-04-08T23:37:40.887-03:00" } Possible Errors A withdrawal request may encounter various types of errors. These errors are categorized as follows: Title Description Error code (statusMessage prefix) Error description G Generic errors C Account-related errors (e.g., a blocked or non-existent account) D Identity mismatch errors (e.g., account not owned by the user) U User-related errors B Bank-specific errors The complete list of errors can be found below: G1: Generic error C1: Generic account error C2: Provided bank does not match the account C3: Non-existent account number C4: Inactive or disabled account number C5: Invalid account number C6: Invalid account currency C7: Unsupported bank C8: Invalid account type for the destination bank C9: Invalid account type D1: Document number does not match account number D2: Invalid document number D3: Disabled document number U1: Invalid email U2: User name does not match document B1: Amount does not meet the minimum requirement B2: Invalid bank
• [Orders](https://docs.manteca.dev/cripto/common-entities/orders.md): An order represents an exchange of a certain amount of a given asset for an equivalent amount of a different asset. All possible trades are defined as either a buy operation or a sell operation of one asset against another asset, the second one usually being a fiat or a stable coin. For example, to obtain USDT in exchange for ARS you would perform a buy operation of USDT against ARS, and in turn, to obtain ARS in exchange for USDT you would perform a sell operation of USDT against ARS. The minimum operation amount is 0.1 USD . Interface TypeScript interface IOrder { // The id of the order, a 24 hex string. id: string // The number id of the order, a positive integer. numberId: string // Company defined id for the order. externalId?: string // Session id attached to the order. sessionId?: string // Id of the user performing the operation, a 24 hex string. userId: string // Number id of the user, a positive integer. userNumberId: string // Company defined external id for the user. userExternalId?: string // The exchange the order was performed in. exchange: EXCHANGE // Current status of the order. status: ORDER_STATUS // Present if status is CANCELLED, explains the reason for the cancellation. cancellationReason?: string // Type of order, usually DIRECT. type: ORDER_TYPE // Side of the order, either BUY or SELL. side: ORDER_SIDE // Asset being operated. asset: CRYPTO_ASSETS // Asset against which the operation is being made. against: FIAT_ASSETS | CRYPTO_ASSETS // Amount of the asset to be operated. assetAmount: string // Amount that has been already succesfully operated. filledAmount: string // Price at which the operation is being made. price: string // Effective price of the operation taking fees into consideration. effectivePrice: string // Reference prices to simplify conversion of assetAmount to other prices at the time of the creation of the order. referencePrices: IReferencePrices // Information regarding the fees being applied to this order. feeInfo: IOrderFeeInfo // Detailed itemized summary of the amount claimed from user balance or company debt in order to perform the operation. finalClaimInfo: IOrderFulfillmentInfo // Detailed itemized summary of the amount credited to user balance or as company credit as a result of performing the operation. finalCreditInfo: IOrderFulfillmentInfo // Time at which the order was created as an ISO 8601 Date String. creationTime: string // Time the order was last updated at as an ISO 8601 Date String. updatedAt: string } Reference Prices Interface TypeScript interface IReferencePrices { // Price of the asset in local currency (so ARS for Argentina, CLP for Chile and so on) for the given side. assetLocalCurrencyPrice: string // Price of USDT in local currency (so ARS for Argentina, CLP for Chile and so on) for the given side. usdtLocalCurrencyPrice: string // Price of the asset in ARS for the given side. If exchange is Argentina it should be the same as assetLocalCurrencyPrice. assetArsPrice: string // Price of the asset in USD for the given side. assetUsdPrice: string } Fee info interface TypeScript interface IOrderFeeInfo { // Multiplier for the platform fees, meaning what we charge for the use of our systems. platformFee: string // Multiplier for the company profit, meaning what the company witholds as profit from the operation. companyProfit: string // Addition of all the multipliers totalFee: string } Order Fulfillment info interface TypeScript interface IOrderFulfillmentInfo { // The asset in which the following values are in. asset: string // Total amount after fee addition or subtraction (depending on if it's a claim or a credit). total: string // Base amount without taking fees into consideration. base: string // Total amount to be charged in fees. totalFees: string // Amount to be charged in platform fee. platformFee: string // Amount to be charged in company profit. companyProfit: string } Possible Statuses An order can have multiple statuses, these are: Title Description Status Meaning PENDING The order entity was created, the funds were claimed and all compliance checks were done, but the operation has yet to be done. COMPLETED The operation has been done and the resulting amount has been credited. CANCELLED The order was cancelled and the claimed funds were refunded. This is a final status, a new order must be made. Example JSON { "id": "6762f88e065d780e5d758045", "numberId": "10001", "externalId": "example-external-id-1", "sessionId": "example-session-id-1", "userId": "6762f8c7767750522c90b55f", "userNumberId": "10001", "userExternalId": "example-external-id-1", "exchange": "ARGENTINA", "status": "COMPLETED", "type": "DIRECT", "side": "SELL", "asset": "USDT", "against": "ARS", "assetAmount": "10.00000000", "filledAmount": "10.00000000", "price": "1000.00", "effectivePrice": "998.00", "feeInfo": { "platformFee": "0.001", "companyProfit": "0.001", "totalFee": "0.002" }, "finalClaimInfo": { "asset": "USDT", "total": "10.00000000", "base": "10.00000000", "totalFees": "0.00", "platformFee": "0.00", "companyProfit": "0.00" }, "finalCreditInfo": { "asset": "ARS", "total": "9980.00", "base": "10000.00", "totalFees": "20.00", "platformFee": "10.00", "companyProfit": "10.00" }, "creationTime": "2024-12-13T12:22:54.290-03:00", "updatedAt": "2024-12-13T12:22:54.290-03:00" }
• [Synthetics](https://docs.manteca.dev/cripto/common-entities/synthetics.md): The synthetic entity contains all the relevant information regarding the configuration and current state of an automatic flow, including the status, the stages with their details and what stage is currently being executed or is awaiting execution. Interface TypeScript interface ISynthetic { // The id of the synthetic, a 24 hex string. id: string // The number id of the synthetic, a positive integer. numberId: string // An optional company defined id for the synthetic. externalId?: string // An optional session id attached to the synthetic and all entities created through the use of the synthetic. sessionId?: string // The id of the user performing the operations, a 24 hex string. userId: string // The number id of the user, a positive integer. userNumberId: string // The external id of the user, if defined previously during onboarding. userExternalId?: string // The current status of the synthetic. status: SYNTHETIC_STATUS // If status is CANCELLED then this details the reason for the cancellation cancellationReason?: string // The type of the synthetic, for example RAMP_OPERATION or PARTIAL_RAMP_OPERATION which determines the look of the details and stages fields. type: SYNTHETIC_TYPE // The details regarding the synthetic, the look of the interface is defined by the synthetic type. details: ISyntheticDetails // The stage that is currently in progress or waiting to be executed. If status is COMPLETED it should be one number higher than final stage number. currentStage: number // A map of stage number to stage information, for more information read ISyntheticStage interface. stages: { [stageNumber: number]: ISyntheticStage } // The time the synthetic was created as a ISO 8601 Date String. creationTime: string // The time the synthetic was last updated at as ISO 8601 Date String. updatedAt: string } Types of Synthetic (and their ISyntheticDetails interface) The synthetic type determines the stages, the order of those stages and some internal logic for the synthetic to achieve a certain flow. It also determines the look of the ISyntheticDetails interface. The available synthetic types are: RAMP_OPERATION A ramp operation is defined as a deposit stage, in which we await for funds to be sent to our system, followed by an order stage in which we consume the received funds to perform a certain exchange operation, ending with a withdraw stage in which we send the result of the order to an external address. The deposit stage might not be present if the company configuration allows for debt and debt is not explicitely disallowed during the consturction of the synthetic, in which case the synthetic will start on the order stage directly. TypeScript interface IRampOperationSyntheticDetails { // The address to which the user should send the funds in order for it to be detected and processed accordingly. depositAddress: string // If a bank account address from Argentina then the optional alias is presented here if it has any. depositAlias?: string // The networks through which the user can send the funds. depositAvailableNetworks?: NETWORKS[] // The estimated cost required to withdraw (in the asset currency), which will be deducted from the amount to withdraw. For fiat withdraws this is always 0. withdrawCostInAsset: string // The estimated cost required to withdraw (in the against currency), which will be deducted from the amount to withdraw. For fiat withdraws this is always 0. withdrawCostInAgainst: string // The price without fees at which the operation will be made. price: string // The ISO 8601 Date string of the moment the price will expire at. priceExpireAt: string // Present after the order stage is completed, it contains the amount in asset that was operated. assetAmountOperated?: string // Present after the order stage is completed, it contains the amount in against that was operated. againstAmountOperated?: string } PARTIAL_RAMP_OPERATION A partial ramp operation acts the same way as the ramp operation with the only difference being the absence of a withdraw stage, meaning after the order is completed the synthetic will be completed as well and the resulting amount will remain in the user balance or in the company credit depending the the company accounting configuration (See Accounting for more information). TypeScript interface IRampOperationSyntheticDetails { // The address to which the user should send the funds in order for it to be detected and processed accordingly. depositAddress: string // If a bank account address from Argentina then the optional alias is presented here if it has any. depositAlias?: string // The networks through which the user can send the funds. depositAvailableNetworks?: NETWORKS[] // The price without fees at which the operation will be made. price: string // The ISO 8601 Date string of the moment the price will expire at. priceExpireAt: string // Present after the order stage is completed, it contains the amount in asset that was operated. assetAmountOperated?: string // Present after the order stage is completed, it contains the amount in against that was operated. againstAmountOperated?: string } PIX_PAYMENT This synthetic allows payments through the Pix network in BRL (both QRs and pixKeys). The input currency can be a crypto asset such as USDT, or BRL directly if available in the account balance. TypeScript export interface IQRPaymentSyntheticDetails { // Synthetic configuration depositAddresses?: {[network: string]: string} depositAddress?: string depositAlias?: string sender?: ISender paymentAssetAmount?: string paymentAsset?: FIAT_ASSETS paymentAgainst?: string; paymentPrice?: string paymentAgainstAmount?: string price?: string priceExpireAt?: string qrType?: PAYMENT_TYPE merchant?: IMerchant // Synthetic resulting data assetAmountOperated?: string againstAmountOperated?: string } QR3_PAYMENT This synthetic enables payments through QR 3.0 in Argentina. The input currency can be a crypto asset such as USDT, or ARS directly if available in the account balance. TypeScript export interface IQRPaymentSyntheticDetails { // Synthetic configuration depositAddresses?: {[network: string]: string} depositAddress?: string depositAlias?: string sender?: ISender paymentAssetAmount?: string paymentAsset?: FIAT_ASSETS paymentAgainst?: string; paymentPrice?: string paymentAgainstAmount?: string price?: string priceExpireAt?: string qrType?: PAYMENT_TYPE merchant?: IMerchant // Synthetic resulting data assetAmountOperated?: string againstAmountOperated?: string } PERU_QR_PAYMENT This synthetic is used for payments via Plin/Yape/CCE in Peru (either through QRs or phone numbers). The input currency can be a crypto asset such as USDT, or PEN directly if available in the account balance. TypeScript Plain text export { // Synthetic configuration depositAddresses?: {[network: string]: string} depositAddress?: string depositAlias?: string sender?: ISender paymentAssetAmount?: string paymentAsset?: FIAT_ASSETS paymentAgainst?: string; paymentPrice?: string paymentAgainstAmount?: string price?: string priceExpireAt?: string qrType?: PAYMENT_TYPE merchant?: IMerchant // Synthetic resulting data assetAmountOperated?: string againstAmountOperated?: string } BILL_PAYMENT TypeScript export interface IBillPaymentSyntheticDetails { // Synthetic configuration depositAddresses?: { [network: string]: IWithdrawAddress & { alias?: string } } sender?: ISender } Stages (and their ISyntheticStage interface) Stages represent a given action that the synthetic will take once it is reached, and the details of said action are determined through the synthetic stage info interface, which will depend on the type of stage since each action requires their unique configuration. They all share a common part which is as follows but each stage will extend the interface to add more information. Common Interface TypeScript interface ISyntheticStage { // The type of the synthetic stage. stageType: SYNTHETIC_STAGE_TYPE // Time the stage is supposed to be executed at (if undefined then it means as soon as possible) executionTime?: string // List of error messages related to the stage in order of apperance errors?: string[] } Specific Interfaces DEPOSIT The deposit stage will wait for one more more deposits, and once it detects them it will inform the next sage of the total detected amount. TypeScript interface IDepositSyntheticStage extends ISyntheticStage { // The asset we are waiting for a deposit of. asset: CRYPTO_ASSETS | FIAT_ASSETS // The minimum amount required to continue to the next stage, if undefined then any amount will suffice. thresholdAmount?: string // If true then it will use all of the detected amount even if it goes over the threshold. Otherwise next step will only consume the threshold amount. useOverflow?: boolean // The time after which the deposit detector will expire and the synthetic will also be set to expired. expireAt: string // How much it has detected from the deposits it has considered. Undefined means 0. detectedAmount?: string // Contains the ids of all the deposits considered during this stage. depositIds?: string[] } ORDER The order stage will create an order based on the configuration set inside the stage info, which can be updated by previous stages like a deposit stage. TypeScript interface IOrderSyntheticStage extends ISyntheticStage { // The side of the order determines if it's a BUY or SELL order. side: ORDER_SIDE // The type of the order, in api cripto is mostly always DIRECT. type: ORDER_TYPE // The market asset that is going to be sold or bought. asset: CRYPTO_ASSETS // Against what other asset the order of this stage is being made. against: FIAT_ASSETS | CRYPTO_ASSETS // The amount of the asset that is going to be sold or bought. assetAmount: string // Price code to determine price, obtained through price lock or created at the time of creation of the synthetic. priceCode: string // Decoded price related to price code for ease of parsing. price: string // Optional flag, if true then even if company can use debt the order will fail unless user has enough funds. disallowDebt?: boolean // If stage has been started then this is the orderId of the created order, if stage is still not reached then this is undefined orderId?: string // If synthetic was retried after failure on this stage, this is the list of failed orders, if stage never failed this is undefined failedOrderIds?: string[] } WITHDRAW The withdraw stage will send funds through an external network, according to the configuration set inside the stage info, which can be updated by previous stages like an order stage. TypeScript interface IWithdrawSyntheticStage extends ISyntheticStage { // Either the bank for fiat or the blockchain for crypto. network: NETWORKS // The asset we are going to withdraw. asset: CRYPTO_ASSETS | FIAT_ASSETS // The amount of the asset to withdraw in decimal form. amount: string // The destination address we are sending the funds to. to: string // If stage has been started then this is the withdrawId of the created withdraw, if stage is still not reached then this is undefined withdrawId?: string // If synthetic was retried after failure on this stage, this is the list of failed withdraws, if stage never failed this is undefined failedWithdrawIds?: string[] } ORDER_REVERSAL TypeScript export interface IOrderReversalSyntheticStage extends ICommonSyntheticStage { // Stage configuration orderId: string reversalAssetAmount?: string reversalAgainstAmount?: string } REFUND Plain text export interface IRefundSyntheticStage extends ICommonSyntheticStage { partial: boolean assetToRefund: string // Asset to refund to the user (so if ARS -> USDT -> BRL payment then this would be ARS) amountToRefund: string // Amount to refund to the user asset: string // Asset that was refunded due to the withdraw (so if ARS -> USDT -> BRL payment then this would be USDT) amount: string // Amount that was refunded due to the withdraw (WITHDRAW CLAIMED AMOUNT) internalRefund: boolean // If true then the refund was made by US and not by the network, meaning withdraw was never executed succesfully refundReason: string networkId: string; refundedAt: Date; } BILL_PAYMENT TypeScript export interface IBillPaymentSyntheticStage extends ICommonSyntheticStage { // Stage configuration billId: string // The id of the bill to pay asset: FIAT_ASSETS // The asset of the bill amount: string // The amount to pay // Stage auxiliary data setterRuleId?: string // Execution id of the rule that sets the bill payed trigger ruleId?: string // Execution id of the rule that executes when bill payed trigger is triggered // Stage resulting data billPaymentId?: string // Id of the bill payment associated with this stage } Possible Statuses A synthetic can have multiple statuses, these are: Title Description Status Meaning STARTING The synthetic was just created and is preparing to execute the first stage or wait for the execution time of the first stage. ACTIVE The current stage of the synthetic is actively being processed, what that means depends on the stage itself. WAITING The synthetic is waiting for the conditions required for the execution of the current stage to be met, like for example, reaching the execution time. PAUSED The synthetic was manually paused whilst on the WAITING status and will not execute the next stage until unpaused even if conditions are met. COMPLETED All the stages have been executed, this doesnt mean all processes related to the operation are done, a withdraw for example could still be awaiting confirmations but as far as the synthetic responsibilities goes it has completed its tasks once it confirmed the withdraw request was sent to the network without issues. CANCELLED The synthetic has been cancelled, this is a final status. The reason for the cancellation is present in the cancellationReason field. Example JSON { "id": "675c514e7a7c317162a07187", "numberId": "63", "externalId": "example-external-id-1", "sessionId": "example-session-id-1", "userId": "6723e1e8878dc74ee55d93c2", "userNumberId": "100004338", "userExternalId": "example-external-id-1", "status": "COMPLETED", "type": "RAMP_OPERATION", "details": { "depositAddress": "0x701d632075ffe6D70D06bD390C979Ad7EB16Dc61", "depositAvailableNetworks": [ "ETHEREUM", "BINANCE", "POLYGON", "OPTIMISM", "BASE", "ARBITRUM", "INTERNAL" ], "withdrawCostInAgainst": "0", "withdrawCostInAsset": "0", "price": "950.85", "priceExpireAt": "2024-12-13T17:23:54.281Z", "assetAmountOperated": "14.000000000000000000", "againstAmountOperated": "13311.9" }, "currentStage": 4, "stages": { "1": { "stageType": "DEPOSIT", "asset": "USDC", "thresholdAmount": "10.51690593", "useOverflow": true, "expireAt": "2024-12-13T17:22:54.281Z", "depositIds": [ "675c517c7a7c317162a071f2", "675c520b7a7c317162a0731e" ], "detectedAmount": "14.000000000000000000" }, "2": { "stageType": "ORDER", "side": "SELL", "type": "MARKET", "asset": "USDC", "against": "ARS", "assetAmount": "14.000000000000000000", "price": "950.85", "priceCode": "4f4807e2-700b-44df-8c7a-869ee508a797", "orderId": "675c522c7245ce304324e46d" }, "3": { "stageType": "WITHDRAW", "network": "MANTECA", "asset": "ARS", "amount": "13311.90", "to": "999999999999999", "withdrawId": "67626fb89b8c90270356fff1" } }, "creationTime": "2024-12-13T12:22:54.290-03:00", "updatedAt": "2024-12-13T12:26:38.444-03:00" }
• [Common Entities Queries](https://docs.manteca.dev/cripto/common-entities/query-endpoints-2.md): At continuation we list all the endpoints we provide to query common entities:
  • [Get Users](https://docs.manteca.dev/cripto/common-entities/query-endpoints-2/get-users.md)
  • [Get User](https://docs.manteca.dev/cripto/common-entities/query-endpoints-2/get-user.md)
  • [Get User Balances](https://docs.manteca.dev/cripto/common-entities/query-endpoints-2/get-user-balances.md)
  • [Get User Balance](https://docs.manteca.dev/cripto/common-entities/query-endpoints-2/get-user-balance.md)
  • [Get Deposits](https://docs.manteca.dev/cripto/common-entities/query-endpoints-2/get-deposits.md)
  • [Get Deposit](https://docs.manteca.dev/cripto/common-entities/query-endpoints-2/get-deposit.md)
  • [Get Withdraws](https://docs.manteca.dev/cripto/common-entities/query-endpoints-2/get-withdraws.md)
  • [Get WIthdraw](https://docs.manteca.dev/cripto/common-entities/query-endpoints-2/get-withdraw.md)
  • [Get Orders](https://docs.manteca.dev/cripto/common-entities/query-endpoints-2/get-orders.md)
  • [Get Order](https://docs.manteca.dev/cripto/common-entities/query-endpoints-2/get-order.md)
  • [Get Price Lock](https://docs.manteca.dev/cripto/common-entities/query-endpoints-2/get-price-lock.md)
  • [Get Synthetics](https://docs.manteca.dev/cripto/common-entities/query-endpoints-2/get-accounting-summary.md)
  • [Get Synthetic](https://docs.manteca.dev/cripto/common-entities/query-endpoints-2/get-synthetic.md)
• [Accounting Stats](https://docs.manteca.dev/cripto/stats/accounting-stats.md): At continuation a list of all the available stats endpoints relating to accounting:
  • [Get Accounting Summary](https://docs.manteca.dev/cripto/stats/accounting-stats/get-accounting-summary.md)
• [Onboarding Stats](https://docs.manteca.dev/cripto/stats/stat-endpoints.md): At continuation a list of all the available stats endpoints relating to onboarding:
  • [Get User Missing Personal Data](https://docs.manteca.dev/cripto/stats/stat-endpoints/get-user-missing-personal-data.md): This endpoint allows you to identify which personal data fields are still missing for a specific user in order to complete the Define Personal Data onboarding task. It’s typically used after creating the user, before uploading identity images, to ensure that all required information has been submitted.
• [User Stats](https://docs.manteca.dev/cripto/stats/user-stats.md): At continuation a list of all the available stats endpoints relating to users and their balances:
  • [Get Users Balance Snapshots](https://docs.manteca.dev/cripto/stats/user-stats/get-users-balance-logs-copy.md): For a higher-level summary of account health, the platform generates daily balance snapshots at midnight (GMT-3). These snapshots give you the total available balance of an account at the end of each day. Snapshots are fuzzy by design: If a transaction is being processed at the exact moment the snapshot is generated, it may appear in the next snapshot instead of the current one. For this reason, snapshots should be treated as a convenient daily reference rather than a strict ledger. Snapshots are ideal for: Daily financial reporting Balance trend analysis End-of-day reconciliation
  • [Get Users Balance Logs](https://docs.manteca.dev/cripto/stats/user-stats/get-users-total-balance-copy.md): This endpoint provides a complete list of all balance-impacting entries (slips) for a given user, including both credits and debits. Each slip represents an individual accounting movement recorded in the system. The following movement types are included: PAYMENT_CREATION WITHDRAW_CREATION DEPOSIT_CREATION PAYMENT_CANCELLATION WITHDRAW_CANCELLATION ORDER_CREATION ORDER_REVERSAL These types indicate the origin and nature of each transaction that affects the balance, supporting audit trails, reconciliation, and financial analysis.
  • [Get Users Total Balance](https://docs.manteca.dev/cripto/stats/user-stats/get-users-total-balance.md)
• [QR Payments](https://docs.manteca.dev/cripto/common-flows/qr-payments.md): This flow outlines how to initiate QR payments through our API using a single integration that supports operations in Argentina, Brazil, and Peru. We offer two operational modes: 1) User account onboarding: each user account is onboarded individually through our onboarding process . This is the preferred method if multiple services will be used, as it provides granular control for each user. In cases where the paying user’s nationality is not supported by our onboarding process, a special account with a designated userId will be provided, from which those payments can be processed. 2) Principal Account Mode: in specific scenarios—such as when the client’s legal structure permits—operations can be conducted through a single principal account. This account functions as a centralized or consolidated entity for transaction handling. In both modes, the API behavior remains consistent. The only difference lies in the usage of the userId parameter. While in the user account onboarding model, each API request must include the userId corresponding to the specific onboarded user, in the principal account model, a single userId representing the principal account is used across all requests. QR payments follow a two–step process: payment preview and payment confirmation. Payment preview To initiate a payment, the client must scan the QR code using a device and send the encoded string to the payment lock endpoint . Our platform will automatically detect whether the QR belongs to Argentina’s QR 3.0 network, Brazil’s PIX system, or Peru’s Yape/Plin network and will return the relevant payment information along with a unique lock code. Alternatively, you can initiate a payment by sending a PIX key (such as a CPF, email, phone number, or random key) instead of a QR code. In this case, you can still use the paymentDestination field. The against field specifies the currency that will be debited from the account balance to complete the payment settlement. It does not refer to the destination currency, but rather the source of funds from the user's balance. For example, when making a payment in Brazil, if the user wants to pay using Argentine pesos, the against field must be set to ARS. If the user holds Brazilian reais and wishes to settle directly in the local currency, then BRL should be used instead. Similarly, if the payer holds a stablecoin, such as USDT, this can be specified in the against field. In such cases, a real-time conversion will be triggered from USDT to the merchant’s local settlement currency (ARS, BRL, or PEN), and the payment will be executed immediately. When operating under the principal account model, the sender information must be provided as part of the payment lock, since the actual payer is not directly onboarded as a user. This ensures that all compliance requirements—such as AML/KYC validation—are still met. Here is an example of how the sender field should be populated for a payment originating in Brazil: JSON "sender": { "exchange": "BRAZIL", "legalId": "08439431902", "name": "ROBERTO", "surname": "CARLOS" } Payment confirmation Once the client has obtained the lock code, the payment can be confirmed using the QR Payment synthetic. This operation will debit the funds from the specified balance and complete the settlement to the designated recipient. To track the status of the payment, you may do so either by performing a query using the Synthetic status endpoint , or by subscribing to the SYNTHETIC_STATUS_UPDATE webhook , which will automatically notify you of the final status once it becomes available. Reconciliation & Reporting To retrieve a list of past payments, you can use the get synthetics endpoint , which supports filtering by status , date range , and other relevant parameters. Additionally, real-time balance information for any user—whether a principal account or an individually onboarded user—can be obtained via the get user balances endpoint . Refunds For now, any synthetic with a CANCELLED status represents a transaction for which funds must be returned to the user, as we have already re-credited their account for the original debit. These cases can arise either from failures or payment refunds. If it is a failure, the refund stage will contain internalRefund = true. If it is a refund, the refund stage will contain internalRefund = false. This allows you to differentiate between the two cases. You must also take into account the value in the amountToRefund field of the refund stage, since a payment may be cancelled but the refund executed only partially. To retrieve all payments that were refunded due to a reimbursement (i.e., cases where internalRefund = false ), you can use the GET /synthetics?isRefunded=true . Payment Status Lifecycle The lifecycle of a payment is as follows: All payments start in the ACTIVE state, at which point the funds are debited from the user’s account. From there, they can transition to: COMPLETED , when the payment is successfully processed. CANCELLED , in the event of a network or processing error. In this case, the debited funds are automatically re-credited to the originating account. Additionally, there is the case where a payment that was already in the COMPLETED state later transitions to CANCELLED, which corresponds to refunds. In the sandbox environment, specific keywords in the payment destination string trigger test behaviors: If the destination includes “failure”, the payment will fail. If the destination includes “refund”, the payment will be refunded automatically after 30 seconds. In all other cases, payments will complete successfully. This behavior is only available in the sandbox environment and does not apply to production. You can find more examples in the Test Resources section.
• [Ramp-on/Ramp-off](https://docs.manteca.dev/cripto/common-flows/ramp-on-ramp-off.md): Pending documentation.
• [Exchange As a Service](https://docs.manteca.dev/cripto/common-flows/exchange-as-a-service.md): Pending documentation.
• [Supported resources](https://docs.manteca.dev/cripto/info/supported-assets-1.md): This section provides endpoints to retrieve information about the resources supported for deposits and withdrawals, including assets, networks, and their corresponding availability.
  • [Supported assets](https://docs.manteca.dev/cripto/info/supported-assets-1/supported-assets.md)
• [Price Quoting](https://docs.manteca.dev/cripto/annex/getting-prices.md): All exchange rates provided by the API are real-time and reflect the current market conditions. You can fetch the latest prices at any moment using the corresponding endpoint. Before executing a transaction, you must lock the price to guarantee the rate. Prices may fluctuate rapidly due to market volatility, so operations must be based on a previously locked price to ensure consistency and avoid mismatches.
  • [Quoting a Coin Pair Price](https://docs.manteca.dev/cripto/annex/getting-prices/get-coin-pair-price.md): You can request a real-time quote for any supported coin pair. This quote represents the current exchange rate and is based on live market data.
• [Previewing QR Payments](https://docs.manteca.dev/cripto/annex/locking-pix-payments.md): QR payments start by scanning a QR code. You should then utilize our endpoints to decode the information contained in that QR code and lock in a temporary exchange rate for the operation. After that, you must create a synthetic payment based on that locked-in quote.
  • [Lock QR Payment](https://docs.manteca.dev/cripto/annex/locking-pix-payments/lock-pix.md): To initiate a payment, the client must scan the QR code using a device and send the encoded string to this endpoint. Our platform will automatically detect whether the QR belongs to Argentina’s QR 3.0 network or Brazil’s PIX system, and will return the relevant payment information along with a unique lock code. Alternatively, you can initiate a payment by sending a PIX key (such as a CPF, email, phone number, or random key) instead of a QR code. In this case, you can still use the paymentDestination field. (Important: When using a PIX key, you must also include the amount field, since PIX key payments do not embed an amount in the reference itself.). The against field should indicate the currency to be debited from the user's account to complete the settlement. The purpose of this endpoint is not only to return that data, but also to generate and return a code that will later be used to execute the final payment. Among the returned information, you'll also find the exchange rate used for the transaction, along with other relevant data. If a preview is requested for a QR code that has already been paid, the response will return a PIX_STATUS error. If the QR code is invalid, it will return an INVALID_PIX_CODE error. QR codes can be either static or dynamic. For static QR codes, the returned payment amount will be 0 , as they do not carry a predefined value. Dynamic QR codes, on the other hand, include a preset amount greater than 0 . If the QR is static, a payment code will not be generated. In that case, you’ll need to perform the preview request again, this time including a fixed amount that represents the value the user wants to pay. To facilitate testing, we provide a few sample QR codes . Common Errors CONFLICT.QR_PAYMENT: QR-PAYMENT generic error CONFLICT.QR_STATUS: Given QR payment is already paid or expired CONFLICT.USER_NOT_VALIDATED: User is not ACTIVE BAD_REQUEST.PAYMENT_DESTINATION: Payment destination seems to be invalid BAD_REQUEST.PAYMENT_AMOUNT: Amount is required for pixKey BAD_REQUEST.PAYMENT_DESTINATION_MISSING_AMOUNT: The pseudo-static QR is not loaded yet. FORBIDDEN.PERMISSIONS: Account has no permissions to use this endpoint
  • [Get QR Payment Lock](https://docs.manteca.dev/cripto/annex/locking-pix-payments/get-pix-lock.md)
• [Locking withdraw cost](https://docs.manteca.dev/cripto/annex/locking-withdraw-cost.md): This endpoint allows you to pre-lock the withdrawal cost for one or more blockchain networks before executing the actual transfer. It returns a unique withdrawLockCode for each network, along with the estimated fee and expiration time. To proceed with the withdrawal using the locked fee, you must include the withdrawLockCode field in your request to the withdraw endpoint.
  • [Locking crypto withdraw cost](https://docs.manteca.dev/cripto/annex/locking-withdraw-cost/locking-withdraw-cost.md)
• [Locking User Balance](https://docs.manteca.dev/cripto/annex/locking-user-balance.md): Locking the balance of an user is a special action that ensures the balance will not be used for any reason until manually unlocked.
  • [Lock User Balance](https://docs.manteca.dev/cripto/annex/locking-user-balance/lock-user-balance.md)
  • [Unlock User Balance](https://docs.manteca.dev/cripto/annex/locking-user-balance/unlock-user-balance.md)
• [Get available companies](https://docs.manteca.dev/cripto/annex/preparing-for-a-bill-payment/get-available-companies.md): To initiate a Bill Payment, the client must first identify which bill the user wants to pay and fetch the outstanding bills associated with a reference (e.g., account number, DNI, contract number).
• [Get outstanding bills](https://docs.manteca.dev/cripto/annex/preparing-for-a-bill-payment/get-outstanding-bills.md): You need to prompt your user to input the corresponding referenceId to identify the bill according the the selected method, so for example if method is barcode number referenceId would be the number of the barcode, and if method is CUIT/CUIL then referenceId would be the customer CUIT/CUIL and so on.
• [Lock bill payment](https://docs.manteca.dev/cripto/annex/preparing-for-a-bill-payment/lock-bill-payment.md): A lock reserves the FX route and validates the bill information.
• [Accounting Endpoints](https://docs.manteca.dev/cripto/annex/accounting-endpoints.md): At continuation we will details the endpoints relating to your company accounting, for more information read the Accounting section.
  • [Get Accounting Settlements](https://docs.manteca.dev/cripto/annex/accounting-endpoints/get-accounting-settlements.md)
  • [Get Accounting Settlement](https://docs.manteca.dev/cripto/annex/accounting-endpoints/get-accounting-settlement.md)
  • [Get Accounting Withdraws](https://docs.manteca.dev/cripto/annex/accounting-endpoints/get-accounting-withdraws.md)
  • [Get Accounting WIthdraw](https://docs.manteca.dev/cripto/annex/accounting-endpoints/get-accounting-withdraw.md)
  • [Request Accounting Withdraw](https://docs.manteca.dev/cripto/annex/accounting-endpoints/request-accounting-withdraw.md)
• [Enum Definitions](https://docs.manteca.dev/cripto/annex/enums.md): This section lists all possible enum values used across our API endpoints. It serves as a central reference to improve visibility and ensure consistent integration.
  • [Withdraw Constants Reference](https://docs.manteca.dev/cripto/annex/enums/withdraw-constants-reference.md): Bank account types (accountType) Plain text SAVINGS – Standard savings account. CHECKING – Standard checking account. DEBIT – Debit card-based account (used in countries like Mexico). PHONE – Mobile phone-based accounts (used in networks like Transfiya or similar). VISTA – Special type of account used in Chile. RUT – Chilean RUT accounts, used exclusively with Banco Estado (bank code 317). Argentina – Supported Bank Codes (bankCode) Plain text 007 – Banco de Galicia y Buenos Aires S.A.U. 011 – Banco de la Nación Argentina 014 – Banco de la Provincia de Buenos Aires 015 – Industrial and Commercial Bank of China 016 – Citibank N.A. 017 – Banco BBVA Argentina S.A. 020 – Banco de la Provincia de Córdoba S.A. 027 – Banco Supervielle S.A. 029 – Banco de la Ciudad de Buenos Aires 034 – Banco Patagonia S.A. 044 – Banco Hipotecario S.A. 045 – Banco de San Juan S.A. 065 – Banco Municipal de Rosario 072 – Banco Santander Argentina S.A. 083 – Banco del Chubut S.A. 086 – Banco de Santa Cruz S.A. 093 – Banco de La Pampa S.E.M. 094 – Banco de Corrientes S.A. 097 – Banco Provincia del Neuquén S.A. 131 – Bank of China Limited 143 – Brubank S.A.U. 147 – BiBank S.A. 150 – Banco GGAL S.A. 165 – JPMorgan Chase Bank, N.A. 191 – Banco Credicoop Cooperativo Limitado 198 – Banco de Valores S.A. 247 – Banco Roela S.A. 254 – Banco Mariva S.A. 266 – BNP Paribas 268 – Banco Provincia de Tierra del Fuego 269 – Banco de la República Oriental del Uruguay 277 – Banco Sáenz S.A. 281 – Banco Meridian S.A. 285 – Banco Macro S.A. 299 – Banco Comafi S.A. 300 – Banco de Inversión y Comercio Exterior S.A. 301 – Banco Piano S.A. 305 – Banco Julio S.A. 309 – Banco Rioja S.A.U. 310 – Banco del Sol S.A. 311 – Nuevo Banco del Chaco S.A. 312 – Banco VOII S.A. 315 – Banco de Formosa S.A. 319 – Banco CMF S.A. 321 – Banco de Santiago del Estero S.A. 322 – Banco Industrial S.A. 330 – Nuevo Banco de Santa Fe S.A. 331 – Banco Cetelem Argentina S.A. 332 – Banco de Servicios Financieros S.A. 338 – Banco de Servicios y Transacciones S.A. 339 – RCI Banque S.A. 340 – BACS Banco de Crédito y Securitización S.A. 341 – Banco Masventas S.A. 384 – Wilobank S.A.U. 386 – Nuevo Banco de Entre Ríos S.A. 389 – Banco Columbia S.A. 426 – Banco BICA S.A. 431 – Banco Coinag S.A. 432 – Banco de Comercio S.A. 435 – Banco Sucredito Regional S.A.U. 448 – Banco Dino S.A. 44077 – Compañía Financiera Argentina S.A. 44088 – Volkswagen Financial Services Compañía Financiera S.A. 44092 – FCA Compañía Financiera S.A. 44093 – GPAT Compañía Financiera S.A.U. 44094 – Mercedes-Benz Compañía Financiera Argentina S.A. 44095 – Rombo Compañía Financiera S.A. 44096 – John Deere Credit Compañía Financiera S.A. 44098 – PSA Finance Argentina Compañía Financiera S.A. 44099 – Toyota Compañía Financiera de Argentina S.A. 45030 – Naranja Digital Compañía Financiera S.A. 45056 – Montemar Compañía Financiera S.A. 45072 – Reba Compañía Financiera S.A. 65203 – Crédito Regional Compañía Financiera S.A. Chile – Supported Bank Codes (bankCode) Plain text 317 – Banco Estado 323 – Banco Falabella 318 – Banco de Chile 314 – Banco Santander 962 – Mercado Pago 310 – BCI 976 – MACH 325 – Tenpo Prepago 309 – Scotiabank Chile 322 – Banco Ripley 959 – Tapp Caja Los Andes 319 – Coopeuch 315 – Banco Itaú 312 – BICE 321 – Banco Consorcio 960 – Copec Pay 324 – Banco Security 961 – Prepago Los Héroes 980 – Los Andes Tarjetas de Prepago 308 – Banco Internacional 311 – Corpbanca Mexico – Supported Bank Codes (bankCode) Plain text 002 – Banco Nacional de México 006 – Banco Nacional de Comercio Exterior 009 – Banco Nacional de Obras y Servicios Públicos 012 – BBVA Bancomer 014 – Banco Santander (México) 019 – Banco Nacional del Ejército 021 – HSBC México 030 – Banco del Bajío 032 – IXE Banco 036 – Banco Inbursa 037 – Banco Interacciones 042 – Banca Mifel 044 – Scotiabank Inverlat 058 – Banco Regional de Monterrey 059 – Banco Invex 060 – Bansi 062 – Banca Afirme 072 – Banco Mercantil del Norte 102 – The Royal Bank of Scotland México 103 – American Express Bank (México) 106 – Bank of America México 108 – Bank of Tokyo-Mitsubishi UFJ (México) 110 – Banco J.P. Morgan 112 – Banco Monex 113 – Banco Ve por Más 124 – Deutsche Bank México 126 – Banco Credit Suisse (México) 127 – Banco Azteca 128 – Banco Autofin México 129 – Barclays Bank México 130 – Banco Compartamos 131 – Banco Ahorro Famsa 132 – Banco Multiva 133 – Banco Actinver 134 – Banco Wal-Mart de México Adelante 135 – Nacional Financiera 136 – Inter Banco 137 – Bancoppel 138 – ABC Capital 139 – UBS Bank México 140 – Consubanco 141 – Volkswagen Bank 143 – CIBanco 145 – Banco Base 147 – Bankaool 148 – Pagatodo 149 – Forjadores 150 – Inmobiliario 151 – Donde 152 – Bancrea 154 – Banco Covalto 155 – ICBC 156 – Banco de Sabadell 157 – Shinhan 158 – Mizuho Bank 159 – Bank of China 160 – Bank S3 166 – Banco del Ahorro Nacional y Servicios Financieros 168 – Sociedad Hipotecaria Federal 600 – Monex Casa de Bolsa 601 – GBM Grupo Bursátil Mexicano 602 – Masari Casa de Bolsa 605 – Value 606 – Estructuradores del Mercado de Valores Casa de Bolsa 607 – Casa de Cambio Tiber 608 – Vector Casa de Bolsa 610 – B y B 614 – Acciones y Valores Banamex 615 – Merrill Lynch México 616 – Casa de Bolsa Finamex 617 – Valores Mexicanos Casa de Bolsa 618 – Única Casa de Cambio 619 – Mapfre Tepeyac 620 – Profuturo G.N.P. 621 – Actinver Casa de Bolsa 622 – Operadora Actinver 623 – Skandia Vida 626 – Deutsche Securities 627 – Zurich Compañía de Seguros 628 – Zurich Vida 630 – Intercam Casa de Bolsa 631 – CI Casa de Bolsa 632 – Bulltick Casa de Bolsa 633 – Sterling Casa de Cambio 634 – Fincomún 636 – HDI Seguros 637 – Order Express Casa de Cambio 638 – NU 640 – J.P. Morgan Casa de Bolsa 642 – Operadora de Recursos Reforma 646 – Mercado Pago 647 – Telecomunicaciones de México 648 – Evercore Casa de Bolsa 649 – Skandia Operadora de Fondos 651 – Seguros Monterrey New York Life 652 – Solución ASEA 661 – Klar 671 – Caja Huastecas 677 – Caja Popular Mexicana 680 – Caja Popular Cristóbal Colón 683 – Caja de Ahorro de los Telefonistas 684 – Transfer 685 – Fondo (FIRA) 686 – Invercap 699 – Fondeadora 706 – Arcus 710 – Nvio 722 – Mercado Pago W 723 – Cuenca 728 – Spin by Oxxo Panama – Supported Bank Codes (bankCode) Plain text 0013 – Banco Nacional de Panamá 0026 – Banistmo S.A. 0039 – Citibank 0071 – Banco General 0181 – Banco Davivienda 0372 – Multibank 0408 – Banco Towerbank 0424 – Banco Scotiabank 0518 – Banco BICSA 0712 – Cooperativa de Profesionales 0767 – Banco Banvivienda 0770 – Banco Caja de Ahorros 0916 – Banco del Pacífico (Panamá) S.A. 1067 – Metrobank S.A. 1083 – Banco Aliado 1106 – Credicorp Bank 1151 – Global Bank 1164 – Bank of China 1258 – Canal Bank 1384 – BAC International Bank 1397 – BCT Bank 1478 – MMG Bank 1494 – Banco St. George 1504 – Banco Azteca 1517 – Banco Pichincha Panamá 1533 – Produbank 1562 – Banco Delta 1575 – Banco Lafise Panamá S.A. 1588 – Banco Banesco 1591 – Capital Bank 1614 – Banco Banisi S.A. 1627 – Banco G&T Continental 1630 – Banco Mercantil Bank 1656 – BBP Bank S.A. 1672 – Prival Bank 1685 – Balboa Bank & Trust 1708 – Uni Bank & Trust Inc 1724 – Banco Ficohsa Panamá 1737 – FPB Bank 1753 – Bancolombia 1782 – Bi-Bank S.A. 1805 – B2 Atlas Bank 2503 – Banco CoopEDUC 2516 – Banco Cooesan 2529 – Banco CACECHI 2532 – Banco Coeduco 2545 – Coopeve 5005 – Cooperativa Cristóbal 5018 – Banco Edioacc R.L 5021 – Banco Ecaseso 5034 – Banco Cooprac R.L. 9900 – Banco Itaú Panamá S.A. Costa Rica – Supported Bank Codes (bankCode) Plain text 0102 – Banco BAC San José 0104 – Banco Davivienda Costa Rica S.A. 0107 – Banco BCT 0114 – Banco Lafise 0116 – Banco Promérica 0120 – Banco Improsa 0123 – Banco Scotiabank 0125 – Banco Cathay 0126 – Banco General de Costa Rica S.A. 0127 – Banco CMB (Costa Rica) S.A. 0151 – Banco Nacional de Costa Rica 0152 – Banco de Costa Rica 0161 – Banco Popular de Desarrollo Comunal 0162 – Banco Hipotecario de la Vivienda 0231 – Banco Hipotecario de la Vivienda 0312 – Prival Bank (Costa Rica) S.A. Guatemala – Supported Bank Codes (bankCode) Plain text 001 – Banco de Guatemala 004 – El Crédito Hipotecario Nacional de Guatemala 012 – Banco de los Trabajadores 013 – Banco Inmobiliario S.A. 015 – Banco Industrial S.A. 016 – Banco de Desarrollo Rural S.A. 019 – Banco Internacional S.A. 030 – Citibank, N.A. Sucursal Guatemala 036 – Vivibanco S.A. 039 – Banco Ficohsa Guatemala S.A. 040 – Banco ProAmerica S.A. 041 – Banco de Antigua S.A. 042 – Banco de América Central S.A. 044 – Banco Agromercantil de Guatemala S.A. 045 – Banco G&T Continental S.A. 047 – Banco Azteca de Guatemala S.A. 048 – Banco INV S.A. 049 – Banco Credicorp S.A. Colombia – Supported Bank Codes (bankCode) Plain text 1507 – Banca Digital Nequi 1007 – Bancolombia 1809 – Nu 1551 – Daviplata 1051 – Banco Davivienda S.A. 1001 – Banco de Bogotá 1032 – Banco Caja Social BCSC S.A. 1013 – BBVA Colombia 1052 – Banco AV Villas 1801 – Movii 1804 – Ualá 1019 – Banco Colpatria (Scotiabank Colpatria) 1062 – Banco Falabella S.A. 1070 – Lulo Bank S.A. 1002 – Banco Popular 1292 – Confiar Cooperativa Financiera Philippines – Supported Bank Codes (bankCode) Plain text shopeepay – ShopeePay eastwest – EastWest Bank rcbc – RCBC / Diskartech security – Security Bank robinsons – Robinsons Bank metrobank – Metrobank pdax – PDAX veterans – Philippine Veterans Bank cardbank – Card Bank cimb – CIMB Bank Philippines maybank – Maybank pnb – PNBMPHMMTOD seabank – SeaBank landbank – Landbank / OFBank chinabank – China Bank grabpay – GrabPay cebuanal – Cebuana Lhuillier Bank / Cebuana Xpress paymaya – PayMaya / Maya Wallet mayabank – Maya Bank gcash – GCash allbank – AllBank (A Thrift Bank), Inc. unionbank – Union Bank of the Philippines guinobatan – Asenso / Rural Bank of Guinobatan bdouni – BDO Bank aub – Asia United Bank bpi – BPI gotyme – GoTyme Bank ecash – eCash Bolivia – Supported Bank Codes (bankCode) Plain text 001 - BANCO MERCANTIL 002 - BANCO NACIONAL DE BOLIVIA 003 - BANCO DE CRÉDITO DE BOLIVIA 005 - BANCO BISA 006 - BANCO UNIÓN 007 - BANCO ECONÓMICO 008 - BANCO SOLIDARIO 009 - BANCO GANADERO 011 - LA PRIMERA ENTIDAD FINANCIERA DE VIVIENDA (EX MUTUAL LA PRIMERA) 013 - MUTUAL LA PROMOTORA 014 - EL PROGRESO ENTIDAD FINANCIERA DE VIVIENDA (EX MUTUAL EL PROGRESO) 022 - COOPERATIVA JESÚS NAZARENO 023 - COOPERATIVA SAN MARTIN 024 - COOPERATIVA FÁTIMA 029 - COOPERATIVA PIO X 031 - COOPERATIVA QUILLACOLLO 033 - COOPERATIVA TRINIDAD 034 - COOPERATIVA COMARAPA 035 - COOPERATIVA SAN MATEO 036 - COOPERATIVA EL CHOROLQUE 038 - COOPERATIVA CATEDRAL 039 - MAGISTERIO RURAL 044 - BANCO PYME DE LA COMUNIDAD (BANCOMUNIDAD) 045 - BANCO FIE 047 - BANCO ECOFUTURO 049 - BANCO FORTALEZA 052 - BANCO DE LA NACION ARGENTINA 053 - TIGO MONEY (BILLETERA MOVIL) 054 - BILLETERA MÓVIL DE ENTEL BILLETERA MÓVIL DE ENTEL Peru – Supported Bank Codes (bankCode) Plain text 002 - Banco de Crédito del Perú (BCP) 003 - Interbank 007 - Citibank del Perú 009 - Scotiabank Perú 011 - BBVA Continental 018 - Banco de la Nación 023 - Banco de Comercio 035 - Banco Pichincha 038 - BanBif 043 - CrediScotia 049 - Mibanco 053 - Banco GNB Perú 054 - Banco Falabella 055 - Banco Ripley 056 - Banco Santander Perú 058 - Alfin Banco (ex Banco Azteca) 060 - ICBC Perú Bank 091 - Compartamos Financiera 094 - Tarjeta Oh 096 - Financiera Efectiva 099 - Financiera Confianza 776 - Prex Perú 800 - Caja Metropolitana de Lima 801 - Caja Piura 802 - Caja Trujillo 803 - Caja Arequipa 805 - Caja Sullana 806 - Caja Cusco 808 - Caja Huancayo 809 - Caja Ica 811 - Caja Maynas 813 - Caja Tacna 849 - Caja Los Andes 901 - Yape 902 - Plin 904 - BIM 910 - Cooperativa Abaco 921 - Ligo 922 - Dale
  • [Payouts Account Validations](https://docs.manteca.dev/cripto/annex/enums/payouts-account-validations.md): Title Description Title Description Title Description Title Country Type Supported account Argentina BANK_TRANSFER CBU e.g: 2850590940090418135201 Regex: ^\d{22}$ Alias e.g: mi.alias.banco1 Regex: ^[A-Za-z0-9.]{6,20}$ Brazil PIX CPF e.g: 12345678909 Regex: ^\d{11}$ Emai e.g: usuario@email.com Regex: ^[^\s@]+@[^\s@]+\.[^\s@]{2,}$ Phone number e.g: 11987654321 Regex: /^(1[1-9]|[2-9]\d)9\d{8}$/ Random Key (UUID) e.g. 123e4567-e89b-12d3-a456-426614174000 Regex:/^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$/ Colombia BANK_TRANSFER / NEQUI Checking/Savings e.g: 1234567890 Regex: ^\d{6,12}$ Nequi e.g: 03123456789 Regex: ^03\d{9}$ Colombia TRANSFIYA Phone number (mobile number linked to Transfiya) e.g: 3001234567 Regex: ^3\d{9}$ Chile BANK_TRANSFER For Banco Estado, the RUT must be entered without the verification digit (last digit) and without the hyphen (-). e.g: 123456789 Regex:^\d{6,12}$ Guatemala BANK_TRANSFER Checking e.g: 1234567890 Regex: ^\d{10}$ Savings e.g: 1234567 Regex: ^\d{7}$ Panama BANK_TRANSFER Checking e.g: 12345678 Regex: ^\d{6,12}$ Savings with leading zeros e.g: 000123456789 Regex: ^\d{6,12}$ Costa Rica BANK_TRANSFER IBAN Accounts: total length must be between 20 and 22 digits, including the CR prefix + number (18–20 digits). Checking e.g: 123456789012345678 Regex: ^\d{18,20}$ Savings e.g: 123456789012345678 Regex: ^\d{18,20}$ Mexico SPEI CLABE (Interbank account – Savings) e.g: 012345678901234567 (18 digit) Regex: ^\d{18}$ Debit card e.g: 1234567812345678 (16 digit) Regex: ^\d{16}$ Phone-based (CoDi) e.g: 5512345678 (10 digit) Regex: ^\d{10}$ Philippines INSTACASH E‑wallet (phone) e.g: 09975186291 Regex: ^09\d{9}$ Bank account Regex: ^\d{10,16}$ Bolivia BANK_TRANSFER Bank account e.g: 1234567 Regex: /^\d{7,14}$/ Peru BANK_TRANSFER Bank account e.g: 00212345678901234567 Regex: /^\d{20}$/ (The first three digits must correspond to a valid bankCode)
  • [Supported Documents](https://docs.manteca.dev/cripto/annex/enums/accepted-documents-by-country.md): Title Description Country Accepted Document Recommendations to Avoid Rejection Argentina National Identity Document (DNI) • Upload clear photos of both sides of the DNI. • Avoid glare, cuts, or blurry areas. • Information must match the user profile (name, ID number). • Photocopies or edited images are not accepted. • Ensure the document is valid and not expired. Brazil CPF / RG / CNH • Document must be clear and complete. • Photo and signature must be visible. • Verify CPF format is valid. • Do not upload copies, cropped photos, or damaged IDs. Chile National ID Card (RUN / RUT) • User must be at least 18 years old. • Document must be valid and unaltered. • Ensure name and date of birth match the registration data. • Edited or reflective photos are not accepted. Colombia Citizenship ID / PPT / Foreign ID • Document must be readable and valid. • PPT must show a green check mark of authenticity. • For foreign IDs, confirm date format (YYYY-MM-DD). • Cropped or copied photos are not accepted. Guatemala Personal Identification Document (DPI) • DPI must be clear and complete. • Show full name, ID number, and photo. • Avoid glare, shadows, or partial images. • Damaged or black-and-white copies are not accepted. Costa Rica National ID / DIMEX • DIMEX must include visible QR code (12 digits). • Digital PDF versions are accepted if readable. • Photos must be clear and free of glare or cuts. Mexico INE / CURP / RFC • INE must be clear and current. • CURP and RFC must follow the correct format. • Avoid glare, dark photos, or reflections. • Edited or incomplete images are not accepted. Panama National ID / Resident ID • ID must be complete with visible photo and signature. • Information must match the user profile. • Expired or screenshot copies are not accepted. Bolivia Bolivian National ID (issued by SEGIP) / Foreign Resident ID • Official ID issued by SEGIP. • Only IDs for users 18 years or older are accepted. • Check that the ID is in good condition and valid. • For foreign users, upload a Foreign Identity Card issued by SEGIP. Peru Blue National ID (DNI) / Electronic National ID (DNIe) / Foreigner ID Card • Both Blue DNI and DNIe are valid until expiration. • The Blue DNI is no longer issued since 2025, but remains valid until its expiry date. • DNIe must show chip and readable data. • For foreign residents, a valid Foreigner ID Card is accepted. • Ensure all photos are clear and free of glare.
  • [Supported Legal IDs](https://docs.manteca.dev/cripto/annex/enums/supported-legal-id.md): Title Country Supported Legal ID Example Regex Argentina DNI / CUIT DNI: 12345678 CUIT: 20123456781 DNI: ^\d{7,8}$ CUIT: ^(?:20|23|24|25|26|27|30|33|34)-?\d{8}-?\d$ Brazil CPF 12345678909 ^\d{11}$ Chile RUT / RUN 12345678-9 ^\d{7,8}-[\dkK]$ Colombia National ID / Foreign ID / PPT National ID / Foreign ID / PPT: 1234567890 National ID / Foreign ID / PPT: ^\d{6,10}$ Guatemala CUI 1234567890101 ^\d{13}$ Costa Rica ID / DIMEX ID: 112345678 DIMEX: 900123456 ID: ^\d{9}$ DIMEX: ^\d{9,12}$ Mexico CURP / RFC CURP: GODE561231HDFRRN09 RFC: GODE561231GR8 CURP: ^[A-Z]{4}\d{6}[HM][A-Z]{2}[BCDFGHJKLMNPQRSTVWXYZ]{3}[A-Z0-9]\d$ RFC: ^[A-ZÑ&]{3,4}\d{6}[A-Z0-9]{3}$ Panama CIP / RUC CIP: 899871234 RUC: E-8-13667 CIP: ^(?:\d{7,12}|\d-\d{3,4}-\d{3,6}|\d{1,2}-NT-\d{1,4}-\d{1,6}|(?:PE|N|E)-\d{1,4}-\d{4,6})$ RUC: /^(?:[1-9]|[EN])-?\d{1,4}-?\d{1,5}$/i Bolivia CI 7794986 BE7663435 7663435BE ^(?:\d{7,10}|(?:BE|CB|CH|LP|OR|PD|PT|SC|TJ)\d{7,10}|\d{7,10}(?:BE|CB|CH|LP|OR|PD|PT|SC|TJ))$ Peru DNI DNI: 12487201 /^\d{8}(\d|-\d)?$/
• [Test Resources](https://docs.manteca.dev/cripto/annex/test-assets.md): In our sandbox environment, you can test all the flows end-to-end. If there’s any type of test you’d like to conduct that isn’t currently supported by the resources we provide, feel free to reach out — we’re happy to help and can enable any additional flows you need. Crypto withdrawals We provide a faucet where you can obtain test cryptocurrencies. Below is a table with all the supported token contracts. Chain Ass Contract addre BNB Testnet USDT 0x3eC7DA586A34589157e0B3AFA5F9eFADa51f36ec Polygon Amoy USDT 0x8431eBc62F7B08af1bBf80eE7c85364ffc24ae24 ETH Sepolia USDT 0x33623435D98fD040DBd382B2076C638C45BfEa6b Optimism Sepolia USDC 0x177AAE8822048B9dD840C9816CD0e9654924c261 Worldchain Sepolia USDC 0x7b66f92D421C8c9Ea12F328d6335e08590AaF4D4 Arbitrum Sepolia USDC 0x8431ebc62f7b08af1bbf80ee7c85364ffc24ae24 Base Sepolia USDC 0x8431eBc62F7B08af1bBf80eE7c85364ffc24ae2 Fiat withdrawals Any fiat withdrawal may either succeed or fail randomly, simulating real-world scenarios. QR payments You can use the following sample QR codes to test different QR payment scenarios. Keep in mind the following rules: If the QR code contains the word qr3, it will be considered a valid QR for Argentina. If it contains pix, it will be considered a valid QR for Brazil. If it also contains manualamount, the amount sent in the amount field will be used — meaning it will behave as a static QR. If not, it will be treated as a dynamic QR. If destination includes “failure” word, the payment will fail. If destination includes “refund” word, the payment will be refunded after 30s. You can use the following sample QR codes to test different QR payment scenarios: Country Type String Image Brazil Static pixmanualamount Brazil Dynamic pix Argentina Dynamic qr3 Peru Dynamic 00020101021226370002800103903022025072409211954330527520448295303604540415005802PE5917CESAR TACURI INGA6004Lima80550003ID10144suGASdIEsZFzlFh4eZ/UMQRNdpSojGNBwPiV0Punz2o=90490005GLOSA0136Happy Path Generación de QR Dinamico91230007FECVCTO01082025123192210005QUOTA01089999999963041AAA User onboardings If the user's name contains the word "fail" (case-insensitive), the onboarding request will be rejected. This behavior is intended for testing purposes and allows you to simulate failed user onboarding scenarios.