Extension Packages

Some integrations are products in their own right — bank feeds with provider credentials, e-invoicing against government APIs. REDA Financials structures these as extension packages: the core defines a global abstract contract, the extension implements it, and a setup record wires the two together. Two base contracts ship today, plus three optional capability interfaces a provider implements only if it needs them.

How the pattern works

Both contracts follow the same architecture, and both class headers describe it in the same words: "The core package resolves the provider at runtime via: Type.forName(setup.Provider_Class__c).newInstance()". Neither contract hard-codes a vendor. There are four moving parts, each with a clear owner:

refin.BankFeedProvider — automated bank statements

• The contract: three methods an implementation provides — connect (the provider's linking flow), sync (fetch transactions since the cursor and deliver statement lines), disconnect (revoke access). Results return in a standard shape (success, transactions imported, updated cursor, balance, error).
• The wiring: a Bank Feed Setup record per connected account — provider name, environment (Sandbox/Production), the implementing class name, sync cursor and status (Active / Paused / Error / Disconnected), last sync. The setups live on the bank account's record page.
• Credentials stay with the extension — the core never sees provider tokens; the extension owns its authentication end-to-end.
• The payoff: statements arrive as ordinary bank statements (import source marked accordingly) and flow into the same matching and reconciliation as a CSV would — automation upstream, familiar workflow downstream.

The bank feed contract, method by method

Every method receives the setup record as its context. The class doc spells out the model: "Each method receives the Bank_Feed_Setup__c record as the primary context — the provider reads the linked bank account and its own credentials to execute sync logic."

global abstract BankFeedResult sync(refin__Bank_Feed_Setup__c setup);

global abstract BankFeedResult connect(
    refin__Bank_Feed_Setup__c setup,
    Map<String, String> params
);

global abstract void disconnect(refin__Bank_Feed_Setup__c setup);

BankFeedResult is a global inner class — every member is @AuraEnabled global, and the constructor defaults success to false and transactionsImported to 0, so an implementation must earn a success:

refin__Bank_Feed_Setup__c — field reference

A skeleton implementation

Here is the shape of a provider — Meridian's team sketching one against their US bank's direct API. Only the contract pieces are real; the comments mark where your provider logic goes:

global class MeridianBankFeedProvider extends refin.BankFeedProvider {

    global override refin.BankFeedProvider.BankFeedResult connect(
            refin__Bank_Feed_Setup__c setup, Map<String, String> params) {
        refin.BankFeedProvider.BankFeedResult result =
            new refin.BankFeedProvider.BankFeedResult();
        // Exchange the connection parameters (e.g. public_token) with the
        // provider. Store credentials in YOUR package — never in core objects.
        result.success = true;
        return result;
    }

    global override refin.BankFeedProvider.BankFeedResult sync(
            refin__Bank_Feed_Setup__c setup) {
        refin.BankFeedProvider.BankFeedResult result =
            new refin.BankFeedProvider.BankFeedResult();
        // 1. Fetch transactions since setup.refin__Sync_Cursor__c
        // 2. Deliver them as bank statement lines
        // 3. Return the new cursor so it can be persisted
        result.transactionsImported = 42;
        result.updatedCursor = 'cursor-after-this-batch';
        result.success = true;
        return result;
    }

    global override void disconnect(refin__Bank_Feed_Setup__c setup) {
        // Revoke tokens and webhooks on the provider side; the core
        // sets Sync_Status to Disconnected after this completes.
    }
}

refin.EInvoiceProvider — statutory e-invoicing

• The contract: submit (build the jurisdiction's payload from the document and call the authority), checkStatus (poll asynchronous authorities), cancel (jurisdiction-specific rules apply — the contract note itself cites Brazil's 24-hour window and Mexico's receiver acceptance).
• The wiring: an E-Invoice Setup per entity/country — provider, environment, implementing class, which document types participate, and an Auto Submit On Post option; every submission attempt is recorded as an E-Invoice Trail on the document (status, fiscal UUID and number, payloads, response, retry count) — the compliance audit trail regulators expect.
• Availability note: the trails and related lists are visible throughout the app (you've seen E-Invoice Trails on invoice pages); live submission requires the provider extension for your jurisdiction — confirm what's available for your country with REDA.

The e-invoice contract, method by method

All three return an EInvoiceResult — members: success, status, fiscalUUID, fiscalNumber, responseCode, responseMessage, xmlPayload, responsePayload, errorMessage.

The e-invoice objects — field reference

The refin__E_Invoice_Trail__c record is the per-submission audit row: lookups to the setup and the source invoice, Document_Type__c, Status__c, Fiscal_UUID__c, Fiscal_Number__c, XML_Payload__c, the response fields (Response_Code__c/Message__c/Payload__c/Date__c), Submitted_Date__c, Retry_Count__c and Provider_Document_Id__c — the evidence chain regulators expect, one row per attempt. Status__c carries eight values: Draft, Ready to Send, Queued, Submitted, Accepted, Rejected, Cancelled, Error.

Optional capability interfaces — how a frozen contract still grows

refin.EInvoiceProvider shipped as a global abstract class in a Managed-Released version, which means no method can ever be added to it. Rather than freeze the framework with it, REDA adds new behaviour as separate global interfaces, which Salesforce does permit. A provider extends EInvoiceProvider and implements whichever capability interfaces it supports; the core detects support with instanceof and simply skips the capability for providers that don't implement it.

The three data types they exchange

• refin.EInvoiceEvent — one milestone in a document's life at the authority. The core correlates it back to a Trail by erpDocumentId, a value your provider stamps into the outbound envelope and the authority echoes back. status is normalised to Accepted, Rejected, Cancelled or InProgress — the core keys retry and terminal-state logic off that, never off the raw responseCode. It also carries notificationId, processType (Outbound / Inbound), responseMessage, fiscalUUID, fiscalNumber, an optional documents list, payload and eventDate.
• refin.EInvoiceDocument — one artefact: title, fileExtension ('xml' or 'pdf'), base64Body, and documentKind ('Legal', 'LegalResponse' or 'Representation'). The core decodes it and attaches it to the Trail and the source invoice as Salesforce Files, so users see the compliant artefacts on the record they already work with.
• refin.EInvoiceProvisionResult — success (defaulting to false), externalId (the provider-side handle) and message.

documentKind, processType and status are all String rather than enums — deliberately, so the permitted set can grow without breaking a frozen global signature. Don't switch exhaustively on them; handle the values you know and pass the rest through.

Common mistakes to avoid

For teams building an extension

• Implement the abstract class in your package's namespace; register the fully-qualified class name in the setup record.
• Own your credentials (named credentials in your package), your API mapping, your error semantics — return honest results; the core surfaces them in Sync Status and trails.
• Build against the contract only — the documented global surface is the stable one (the rules).

Where to go next

1. Importing Bank Statements — the flow feeds land in.
2. AppExchange Integrations — the broader ecosystem picture.
3. Apex Development on REDA — the global-surface rules.

Frequently asked questions