ARCA Conecta
ARCA Conecta asks the customer for the login they use on ARCA, Argentina's tax authority: their CUIT and their Clave Fiscal. The customer fills a secure form inside the conversation, and the node stores those values as the customer's own credential for the AltData sources you choose. From then on, any data request to those sources reads ARCA with the customer's credential, with no further setup in the flow.
The default source is ARG-PRI-0002 (ARCA Mis Comprobantes). The node then checks the credential against ARCA once and follows Success or Error.
It works like SAT/SRI Password: a form created from the node for each connector, the same two outputs and a variable with the outcome. The difference is where the credential goes. SAT and SRI hand it to their own integration; ARCA Conecta stores it with the customer's data source credentials.
Before You Use It
The conversation must have an identified customer. The credential belongs to a customer, so a Login, Read Borrower or Create Borrower node has to run first. Publishing warns you when no earlier node in the flow identifies the customer. The warning does not block publishing, because another flow may identify the customer before it jumps to this one. If the conversation reaches the node with no customer, the node does not send the form: it leaves a warning notice asking for a login step before it and follows Error.
The tenant must publish the arca-password form on each connector. Open the node, choose a connector and click Create Form. On a web connector the form is saved for the web channel; on WhatsApp it is published as a WhatsApp Flow, which needs the wp_private_key secret on the connector. Repeat for every connector the flow runs on. A connector without the form cannot show it: the node leaves a warning notice and follows Error.
The source must take customer-owned credentials. Only AltData sources whose credentials belong to each customer, not to the tenant, appear in the selector, and the source has to be enabled in your environment.
The Form
The form is built from the fields the first selected source asks for. For ARCA that means the CUIT and the Clave Fiscal. Fields the source marks as secret, such as the Clave Fiscal, are shown as password fields. On the web the customer sees the form in a panel and a loading message, Validando credenciales..., while the node works; on WhatsApp it opens as a native form.
If you change the sources after creating the form, the editor tells you when a source asks for different fields than the first one, since one form cannot serve both. A source that does not take customer credentials is flagged as well.
Configuration
| Option | Description |
|---|---|
| Data sources | The AltData sources with customer-owned credentials that receive the same CUIT and Clave Fiscal. Several can be selected. Only the first one is checked. Default: ARG-PRI-0002 (ARCA Mis Comprobantes) |
| Connectors with configured form | The connectors that already have the form. Use Create Form for the ones that do not |
| Verification result variable | Where the outcome is stored, to evaluate later with a Conditional. It never holds the Clave Fiscal. Empty means arca_verification |
| Enable Test Mode | Stores and checks nothing and always follows Success. Does not need an identified customer |
What Happens After the Customer Submits
- The credential is stored for every selected source. The CUIT and Clave Fiscal are saved encrypted, once per source. A stored credential cannot be read back: not by the flow, not by an operator, not through the API. You can only replace it.
- It is checked against the first source only. Every check logs into ARCA with the customer's Clave Fiscal, and ARCA can lock the account after repeated attempts with a wrong key. Checking each source would add attempts and tell you nothing new about the credential. If another source needs a different ARCA service, that permission is not checked in the flow.
- The form answer is masked. The node clears the submitted values from the stored form response. They never reach a variable, a notice or a message.
The node follows Success only when every source stored the credential and the check passed. If any step fails, it follows Error.
The Result Variable
The variable holds an object with the same fields that SAT and SRI write: status, verified, code, reason, testMode and completedAt. status has three values a condition can branch on:
status | Meaning |
|---|---|
verified | Stored for every source and the check passed |
rejected | ARCA answered about the credential: it was refused, or the customer has something to do on ARCA's side |
failed | The check could not run: no customer, no form or no answer, missing fields, a source that cannot take the credential, or AltData unavailable |
The code narrows it down:
code | What to do |
|---|---|
CREDENTIAL_REJECTED | ARCA refused the CUIT or the Clave Fiscal. Ask the customer to check them and submit again |
MANUAL_ACTION_REQUIRED | The credential works, but the customer has to do something on ARCA first, typically enable the Mis Comprobantes service for their Clave Fiscal. The reason carries the instruction the source gives. Once the customer does it, they can submit the form again |
CHECK_NOT_SUPPORTED | The credential was stored, but the source cannot check credentials, so the node follows Error |
MISSING_CREDENTIALS | The answer was missing a field the source requires. Check that the form was created from the same source |
NO_BORROWER | The conversation had no identified customer |
FORM_NOT_FOUND / FORM_RESPONSE_NOT_FOUND | The connector has no published form, or no answer was stored for this customer |
SYSTEM_ERROR | AltData or the service failed. This one is also an error-level notice on the conversation |
The same reason appears in the conversation's notices, so an operator can read it in Chat without opening the variable.
Output Handles
| Handle | When |
|---|---|
| Success | The credential was stored for every source and the check against the first one passed. In test mode, always |
| Error | No identified customer, no published form, the credential was refused, the customer has to act on ARCA, or the store or the check failed |
Things to Know
A refused credential stays stored. The credential is saved before it is checked, so a refused CUIT or Clave Fiscal remains on the customer until a new answer replaces it. A later submission overwrites it.
Do not loop the customer on Error. With a wrong Clave Fiscal, sending the form again and again adds login attempts on ARCA, which is what locks the account. Read the code first: MANUAL_ACTION_REQUIRED needs the customer to act on ARCA, not to type the key again.
Not available on email. The editor does not offer the node in email flows.
Test mode skips everything. Nothing is stored or checked, and no customer is needed. Use it to try the flow, not to collect real credentials.