API Overview
This section is written for administrators and integration developers — the one corner of this knowledge base where Apex class names belong.
REDA Financials is Salesforce-native to the bone: every document is a custom object, every posting is a trigger-driven state change, and every standard Salesforce API therefore works on your accounting data out of the box. On top of that platform surface, the package exposes a small, deliberate set of stable contracts. This overview maps the whole integration landscape.
The four integration layers
| Layer | What it is | Article |
|---|---|---|
| Standard Salesforce APIs | REST, Bulk and (org-enabled) streaming against the refin__ objects — CRUD, query, mass load. The workhorse layer. | REST · Bulk · Streaming |
| The global Apex API | Five stable global classes (below) for tax calculation, PDF generation, email intake, and provider extension contracts. | Apex Development |
| Declarative hooks | One packaged Flow action ("Generate PDF Document") plus the pattern that posting = a status-field update any Flow can perform. | Flows Integration |
| No-code extensibility | Field sets that extend forms, ledger dimensions and PDFs without touching code. | FieldSet Extensibility |
Everything that ships — and everything that deliberately doesn't
Integration planning starts with an honest inventory. Here is the complete packaged surface — and, just as usefully, the things you might go looking for that are not there, because the standard platform already provides them:
| Surface | What ships | Where it's covered |
|---|---|---|
| Global Apex classes | Five: refin.GlobalTaxService, refin.PDFGeneratorAPI, refin.BankFeedProvider, refin.EInvoiceProvider, refin.OCREmailHandler | Apex Development · Extension Packages |
| Flow invocable actions | Exactly one: Generate PDF Document (category "REDA Financials") | Flows Integration |
| Custom objects and fields | Every document, line and ledger row is an ordinary refin__ custom object — full CRUD and query through the standard APIs | REST · Bulk |
| Field sets | 43 packaged field sets across the transactional objects, in three families (Interface, Posting_Mapping, PDF_Template) — admin-editable, no code | FieldSet Extensibility |
| Custom REST endpoints | None — zero @RestResource classes ship; the standard sObject, query and composite endpoints are the REST surface | REST API |
| Platform events / CDC | None packaged; Change Data Capture on refin__ objects is a standard org capability your admin can enable | Streaming |
| Named credentials / connected apps | None ship — integrations authenticate through your org's own connected app and OAuth flow, governed by your policies | — |
| Outbound callouts | Exactly two: REDA's AI service for the AI features (included with the REDA Financials AI licence) and Open Exchange Rates for the daily FX rate sync | AI features · FX sync |
The global Apex surface — the complete list
Thirteen global types constitute the package's stable Apex contract. Five are the day-to-day entry points:
refin.GlobalTaxService— calculate indirect tax and withholding tax programmatically, no DML, fully GL-resolved results.refin.PDFGeneratorAPI— generate a document PDF from Apex or Flow.refin.BankFeedProvider— the abstract contract bank-feed extension packages implement.refin.EInvoiceProvider— the abstract contract e-invoicing providers implement.refin.OCREmailHandler— the inbound-email handler behind email-to-invoice; point an Email Service at it.
The remaining eight exist for extension packages — the e-invoicing contracts and the types they exchange, plus two entry points you call directly:
refin.EInvoiceQueueProvider,refin.EInvoiceDocumentProvider,refin.EInvoiceProvisioner— global interfaces added alongsideEInvoiceProvider, because a released global abstract class can't gain methods without breaking the packages that already extend it.refin.EInvoiceDocument,refin.EInvoiceEvent,refin.EInvoiceProvisionResult— the data-transfer types those contracts pass and return.refin.EInvoiceStatusPollSchedulable— schedule the e-invoice status poll on your own cron instead of the Admin Console card.refin.EInvoiceTrailCreator— create an E-Invoice Trail for posted sales invoices; also exposed as a Flow action.
Everything else in the package is public — internal, invisible across namespaces, and subject to change. If a class isn't on this list, don't build against it.
Internal services are not API — even when you can see them
Reading debug logs and permission sets, you'll encounter internal service classes behind everyday actions — posting, PDF rendering, bank-statement import, AI and FX callouts, tax-content seeding. They are public, not global — subscriber and extension Apex cannot call them across the namespace boundary, and their internal shape can change in any release, so nothing you build should reference them by name:
| What happens internally | The supported route instead |
|---|---|
| The posting engine behind every Draft → Posted transition | Update refin__Status__c to 'Posted' — the trigger runs the engine for you |
| The engine behind the list-view Bulk Status Update action, which never bypasses standard posting guards | The list-view action, or your own bulk status updates via the APIs |
| PDF rendering internals | refin.PDFGeneratorAPI.generateOne or the Flow action |
| Bank statement import internals | The BankFeedProvider contract and standard-API writes |
| The two outbound-callout paths (AI, FX rates) | Operate them from the Admin Console; they are not callable surfaces |
| Country tax-content seeding behind the Tax Setup Wizard | Run the wizard in the UI |
refin.PDFGeneratorAPI and refin.EInvoiceTrailCreator — the two that back packaged Flow actions. refin.GlobalTaxService, refin.BankFeedProvider, refin.OCREmailHandler and the e-invoicing contract types are not granted by any packaged permission set; grant those yourself where your Flow or Apex context requires them.
Versioning and upgrade safety
The package's API classes are built at Salesforce API version 65.0 — refin.GlobalTaxService declares itself "@since API v65.0". The managed-package rule is your planning backbone:
- Global is forever: once released, global classes, methods and member variables cannot be removed or have their signatures changed by the publisher. The thirteen types above, the Flow actions they expose, and every released
refin__object and field are your stable surface. - Public is private, practically: internal classes can be renamed, reshaped or deleted in any release — and since they're invisible cross-namespace, nothing you ship can break by depending on them, because nothing you ship can depend on them.
- Behavior travels through triggers: all 52 packaged triggers run on API DML identically across upgrades — there is no bypass flag to lose, no special mode to re-test.
A typical integration, sketched
Meridian Properties Group's property-management system bills tenants; REDA keeps the books. The nightly integration authenticates through Meridian's own connected app as an integration user holding Accounts Receivable, inserts each invoice as a draft refin__Sales_Invoice__c with its lines, then updates each to Posted in a second call. Document numbers assign from the entity's sequences on insert, entity defaults fill, and posting runs the full engine — tax, exchange rates, period guards. When a record fails (a closed period, say), the error message the API returns is the same sentence a user would read on screen, which makes support conversations short. Total custom code in REDA: none.
The one principle that makes integration easy
The API and the UI are the same machine. Insert a draft invoice via REST and it gets its document number, entity defaults and validations exactly as if typed. Update its status to Posted and the full posting engine runs — tax, withholding, exchange rates, every guard. There is no integration back door, which means there is nothing special to learn: what a user can do, an API user can do, under the same rules and the same permission sets.
Where to go next
- REST API for Accounting Data — the day-one integration.
- Apex Development on REDA — the global classes in detail.
- Extension Packages — the provider contracts.
Frequently asked questions
Yes — that's what global means in a managed package: released global signatures can't be removed or changed. That guarantee is exactly why the surface is kept small.
The same packaged permission set a human doing that work would hold (an AP integration posts bills → Accounts Payable). Triggers enforce identical rules for API and UI writes; there's no separate integration profile to invent.
Setup → Object Manager — every REDA object is there under the refin__ prefix (e.g., refin__Sales_Invoice__c, refin__Status__c). Standard describe calls work too, of course.
No — it's public, so the platform itself makes it invisible to your namespace. The supported (and equally bulk-safe) route is the status-field update: the trigger invokes the engine with full guard coverage.
Exactly two callout destinations ship: REDA's AI service (the AI features, included with the REDA Financials AI licence) and Open Exchange Rates (daily FX sync, multi-currency orgs). No webhooks, no other endpoints — anything else you see in a security review isn't REDA.
Was this article helpful?