Overview
Your customers accept Allaria's terms on a landing page that Allaria hosts. You ask for a single-use link server-to-server, redirect the customer to it, and their acceptance on that page becomes the record Allaria keeps of the signature.
This section documents an integration specific to Banco del Sol and requires the BANCO_DEL_SOL_VIEWER role. Do not share links to these pages outside the integration.
Integrate against development: the flow runs end to end there today.
- Production is still being provisioned — the credentials for this endpoint do not exist yet. A production call will not succeed until Allaria tells you it is ready.
- Ask integraciones@allaria.com.ar before scheduling a go-live.
Who this section is for
This is the consent step of the account flow: it produces the record that the customer accepted a document, and nothing else. Opening the account itself, and everything that follows it, lives in Account Opening.
You build two calls: the one that asks for a link, and — when you need it — the one that asks whether somebody already signed. The page the customer reads, the acceptance, and the record are Allaria's side.
Prerequisites
The link is issued through the b2b gateway, so the call is authenticated like any other: your egress IPs whitelisted and an access token from your client_id / client_secret. See Get started.
Your credentials also have to be authorized for this endpoint specifically. A token that works elsewhere but answers 403 here means that authorization is missing — ask integraciones@allaria.com.ar.
The two kinds of link
A link leads to one of two screens, and they are mutually exclusive. You choose which when you ask for the link, because only you know whether the person already has an account with Allaria.
kind | Who it is for | What the person accepts | What happens afterwards |
|---|---|---|---|
TYC | Somebody opening an account | The terms and conditions, which already contain the BYMA linkage inside the text | The account opening continues as normal |
VINCULATION | Somebody who already has an account | The BYMA linkage of one of their accounts, which they pick on the screen, and nothing else | Allaria links that account in BYMA afterwards, not at the moment of accepting, and the flow ends there |
A VINCULATION link also needs the person's CUIT: that screen lists the accounts (comitentes) they already hold, Allaria looks those up by CUIT, and the person picks one of them to link.
There is no third case and no checkbox. On a TYC link the linkage is part of the text being signed; on a VINCULATION link there are no terms, and accepting that screen is the linkage consent.
The flow
Call Issue link with the person's DNI, first and last name, and the kind. You get back a URL and the number of seconds it stays valid.
Do this right away. The expiry window starts when the link is issued, not when the customer opens it. A link issued in advance and sent by email is likely to be dead on arrival.
On Allaria's landing page. Nothing for you to build. Accepting consumes the link.
The record holds which document was accepted, when, and from which IP. It is the evidence of the signature.
TYC: account opening is being wired to read it. Until that is finished, the record is kept but does not yet advance the account on its own.VINCULATION: accepting also queues the linkage of the account the person picked. Allaria completes it in BYMA asynchronously, retrying if BYMA does not answer, so the account is not linked yet at the moment the person accepts.
You can read that record back at any time with Check signature, by document, so deciding whether to send somebody through this flow does not depend on you having kept anything from step 1.
The link
https://apertura-cuenta.allaria.com.ar/banco-del-sol/kJ3nQ7pXr2vB8sLmT4wYd6ZaE1cH0gNfUiOjRkPq5tM
Use the url exactly as returned — do not rebuild it from the token or assume the path stays the same.
- Single use. Once accepted, the link is spent. Reopening it shows the customer that they already accepted, which is the correct screen, not an error.
- Expires.
expires_in_secondscarries the window; it is 30 minutes in production and longer in development. Read it from the response instead of hardcoding it — if it ever changes, your integration follows. - One live link per person. Asking for a new link retires any unused link that person still has. The old one then tells them it was replaced.
Anybody holding that URL can accept the terms in that person's name until it is spent.
- Send it over the channel you already use to authenticate the customer.
- Do not log it, and do not put it anywhere it can be read by somebody else.
After the customer accepts, you hear from the landing — not from here
Two things reach you once the person has signed, and both come from the landing page: the notification that they accepted, and where the customer is sent next.
Neither travels through this API. The call you make ends when you receive the link:
- no callback from this endpoint;
- no status for you to poll;
- no
return_urlin the request.
There is also nothing to configure per customer — both are agreed once with the landing team, not sent on every call.
Common failure modes
| Symptom | Cause |
|---|---|
401 invalid token | Expired or malformed access token. Get a new one — see Authentication. |
403 client not allowed to issue links | The token is valid but your client_id is not authorized for this endpoint. |
422 invalid_payload | A field in payload did not validate. The problems array names every field that failed, not just the first. |
| The customer sees "the link expired" | Too long between issuing the link and the customer opening it. Issue it at the moment you redirect. |
| The customer sees "the link was replaced" | A newer link was issued for the same DNI. Ask for one link at a time, not a batch ahead of time. |
| The customer sees "you already accepted" | The link was already used — typically the customer refreshed the page after signing. This is success, not a failure. |