Manteca

Manteca Docs

Introducción

Autenticación

Errores

Paginación

Recursos principales

Compañía

Usuarios

Documentación

Órdenes

Movimientos fiat

Transacciones cripto

Precios

Flujos de API

Alta de usuario

On-ramp

Off-ramp

Reglas de pago

Pay-in

Pay-out

Widget

Casos de uso

Webhooks

Crear webhook

Obtener webhook

Información general

Depósitos y retiros de activos FIAT

Países soportados

Argentina

Chile

Health

Theneo Demo TechCrunch

API Cripto

Documentación - API Cripto

Producción

Sandbox

<p class="slate-p " ></p><p class="slate-p " >Manteca está organizada alrededor de la interfaz <a href="https://en.wikipedia.org/wiki/REST" target="_blank">REST</a>. Tiene URLs predecibles orientadas a recursos y usa códigos de respuesta HTTP estándar. Todos los valores de retorno son en formato JSON. </p><p class="slate-p " >Contamos con un sandbox para que puedas probar el API sin alterar los flujos productivos. Para acceder al mismo, tendrás que usar la URL correspondiente (junto con sus API keys).</p><p class="slate-p " >Por otro lado, para todo lo que es notificaciones hacia el lado del cliente, utilizamos webhooks. También contamos con un servicio de websockets para escuchar algunos eventos como los precios.</p><p class="slate-p " >El API utiliza el protocolo <a href="https://en.wikipedia.org/wiki/HTTPS" target="_blank">HTTPS</a> para exponer los endpoints. No soporta HTTP.</p><p class="slate-p " ></p><p class="slate-p " ></p>

Manteca está organizada alrededor de la interfaz 

. Tiene URLs predecibles orientadas a recursos y usa códigos de respuesta HTTP estándar. Todos los valores de retorno son en formato JSON. 

Contamos con un sandbox para que puedas probar el API sin alterar los flujos productivos. Para acceder al mismo, tendrás que usar la URL correspondiente (junto con sus API keys).

Por otro lado, para todo lo que es notificaciones hacia el lado del cliente, utilizamos webhooks. También contamos con un servicio de websockets para escuchar algunos eventos como los precios.

 para exponer los endpoints. No soporta HTTP.

<p class="slate-p " ></p><p class="slate-p " >Manteca utiliza API keys para autenticar los requests. Las mismas son enviadas a través del header <code class="slate-code">md-api-key</code></p><p class="slate-p " >Las credenciales poseen privilegios completos por lo que es imprescindible que sean guardadas de manera segura. La interacción con Manteca debe ser siempre del lado del servidor, especialmente para los llamados autenticados.</p><p class="slate-p " >En algunos casos, también proveemos la posibilidad de realizar IP whitelisting o acceder vía una VPN exclusiva para aumentar la seguridad. </p>

Manteca utiliza API keys para autenticar los requests. Las mismas son enviadas a través del header 

Las credenciales poseen privilegios completos por lo que es imprescindible que sean guardadas de manera segura. La interacción con Manteca debe ser siempre del lado del servidor, especialmente para los llamados autenticados.

En algunos casos, también proveemos la posibilidad de realizar IP whitelisting o acceder vía una VPN exclusiva para aumentar la seguridad. 

md-api-key

internalStatus

message

Ejemplo de respuesta de error

<p class="slate-p " >API Broker usa <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Status" target="_blank">respuestas HTTP</a> estándar para indicar resultados exitosos o fallidos. </p><p class="slate-p " >En general: </p><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative">Códigos en el rango de <code class="slate-code">2xx</code> indican éxito.</div></li><li class="slate-li " ><div style="position:relative">Códigos en el rango de <code class="slate-code">4xx</code> indican un error relacionado a la información provista (como parámetros omitidos o con un tipo inválido).</div></li><li class="slate-li " ><div style="position:relative">Códigos en el rango de <code class="slate-code">5xx</code> indican un error inesperado en Manteca.</div></li></ul><p class="slate-p " >Más allá de los códigos, en caso de error, se podrá acceder a más detalle a partir de visualizar el body de la respuesta. Siempre se maneja un mismo formato que contiene por un lado un internalStatus que hace referencia a un código verbal de error y por otro, un message que es básicamente una descripción algo más detallada del error.</p><div class="slate-div"></div><p class="slate-p " ></p><p class="slate-p " > </p><p class="slate-p " >
</p><p class="slate-p " ></p><p class="slate-p " ><div class="slate-div"></div></p><p class="slate-p " ></p><p class="slate-p " ></p>

 estándar para indicar resultados exitosos o fallidos. 

Más allá de los códigos, en caso de error, se podrá acceder a más detalle a partir de visualizar el body de la respuesta. Siempre se maneja un mismo formato que contiene por un lado un internalStatus que hace referencia a un código verbal de error y por otro, un message que es básicamente una descripción algo más detallada del error.

200 - OK

La creación de un recurso funcionó correctamente.

201 - Created

Todo funcionó correctamente y no hay response.

204 - No Content

El request tiene algún error. Por lo general, son conflictos con los parámetros enviados.

400 - Bad request

401 - Unauthorized

El API key no tiene suficientes permisos para realizar tal acción.

403 - Forbidden

404 - Not Found

La request genera un conflicto. Por ejemplo, por temas de duplicación de request.

409 - Conflict

La cantidad de requests enviados supera el límite impuesto.

429 - Too Many Requests

500 - Internal Server Error

<p class="slate-p " >Hay endpoints que devuelven arrays como response al pedido. En los casos en los que los datos pueden crecer dinámicamente, se devolverá la información de la paginación en el pedido y se aceptarán los siguientes parámetros para pedir los datos paginados.</p><h3 class="slate-h3 " >Parámetros</h3><ul class="slate-ul " ><li class="slate-li " ><div style="position:relative"><code class="slate-code">page</code>: Página actual, el default es 1.</div></li><li class="slate-li " ><div style="position:relative"><code class="slate-code">limit</code>: La cantidad de elementos por página, el default es 10.</div></li></ul><div class="slate-div"></div><p class="slate-p " ></p><p class="slate-p " ></p><p class="slate-p " ></p>

Hay endpoints que devuelven arrays como response al pedido. En los casos en los que los datos pueden crecer dinámicamente, se devolverá la información de la paginación en el pedido y se aceptarán los siguientes parámetros para pedir los datos paginados.

page

limit

<p>Descubrí algunas de las distintas soluciones que se pueden implementar a través del API Cripto. Acá vas a poder encontrar flujos y casos prácticos de uso de la plataforma.</p><p></p><p></p>

Descubrí algunas de las distintas soluciones que se pueden implementar a través del API Cripto. Acá vas a poder encontrar flujos y casos prácticos de uso de la plataforma.

<p></p><p>Las reglas de pago funcionan como una capa de abstracción sobre los diversos servicios involucrados en las operaciones de compra/venta y retiro de activos. Simplifican el proceso de <strong>ramp-on</strong> y <strong>ramp-off</strong> al unificar la lógica necesaria para manejar tanto criptomonedas como fiat de manera automática.</p><p>
El endpoint </p>

Las reglas de pago funcionan como una capa de abstracción sobre los diversos servicios involucrados en las operaciones de compra/venta y retiro de activos. Simplifican el proceso de 

 al unificar la lógica necesaria para manejar tanto criptomonedas como fiat de manera automática.

 se utiliza para realizar la compra automática de criptomonedas y el retiro de los fondos resultantes. Cuando se reciben los fondos (por ejemplo, en pesos argentinos), se genera automáticamente una orden de compra de la criptomoneda solicitada. Una vez completada la compra, los activos se retiran y transfieren a la dirección de criptomonedas especificada, a través de la red solicitada. 

 gestiona la venta de criptomonedas y el retiro de los fondos resultantes. Cuando se reciben los fondos (por ejemplo, USDC vía Ethereum), se genera automáticamente una orden de venta contra la moneda solicitada. Una vez completada la venta, los activos se retiran y transfieren a la cuenta bancaria solicitada.

<p>La integración vía widget permite realizar el <strong>onboarding </strong>de usuarios e integrarse al proceso de <strong>onramp </strong>y de <strong>offramp </strong>directamente sin necesidad de desarrollo de front-end.</p><p></p><h3><strong>Funcionamiento</strong></h3>

La integración vía widget permite realizar el 

directamente sin necesidad de desarrollo de front-end.

El funcionamiento general es igual para todos los casos de uso. En esencia, lo que hay que hacer es generar una widget-URL a través de un POST a nuestras APIs con ciertas configuraciones (entre otras cosas, se elige qué flujo queremos realizar entre onboarding, ramp-on y ramp-off). Cada cliente es identificado a través del 

, lo que permite generar múltiples URLs para un mismo usuario en cualquier momento. Una vez obtenemos tal URL, bastaría con redirigir al usuario a la misma para iniciar el proceso.

Al acceder a la primera pantalla y completar los datos iniciales, la cuenta del usuario será creada. Luego, el usuario debe completar la información necesaria para verificar sus datos e identidad. Estos son todos los pasos que deberá seguir durante el proceso de creación de su cuenta, hasta que quede validado para operar.


Vía chat, los usuarios recibirán atención personalizada para poder llevar a cabo el registro, si es que en algún momento tienen alguna duda, que no les permite finalizar el proceso. 

Luego de subir el documento, se realiza una lectura automática del DNI. En caso de que la imagen sea procesada correctamente, ya queda validada la cuenta. Caso contrario, se procede a una validación manual, para verificar que los datos son visibles y nítidos.

Parámetros que se devuelven en el returnUrl y failureUrl

<p>Podes configurar los webhook endpoints a través del API para ser notificado por cada uno de los eventos que ocurran y te sean de interés.
</p><h3>¿Cómo funciona?</h3><p>A través del atributo secret, que se creó con el método POST, creamos un HMAC por medio del body y enviamos el webhook con toda la información. De esta manera, recibirás en el header el HMAC que creamos y la información en el body. Harás el mismo proceso, para verificar la</p>

Podes configurar los webhook endpoints a través del API para ser notificado por cada uno de los eventos que ocurran y te sean de interés.


A través del atributo secret, que se creó con el método POST, creamos un HMAC por medio del body y enviamos el webhook con toda la información. De esta manera, recibirás en el header el HMAC que creamos y la información en el body. Harás el mismo proceso, para verificar la información.Cuando recibís el webhook, tomas la firma, el body y el secret que tenes almacenado. Luego, creas un HMAC y comparas con el que recibiste en el header, teniendo que obtener el mismo resultado. De esta manera, confirmamos que la información no ha sido adulterada. Para esto, se debe hacer un stringify que sortee el JSON alfabeticamente. Recomendamos la libreria 