EazLink guide
How does BIR EIS system-to-system API integration work?
The practical data flow from an ERP, POS or CAS through validation, transmission, response handling and reconciliation.
Updated 2026-09-06 by the EazLink team. Editorial review: EazLink Editorial Team.
Direct answer
In a system-to-system design, the invoice-producing system sends structured data to an integration layer, which applies the current BIR mapping and submits through the approved interface. The integration stores the response and returns a status to the source system. Registration, certification, credentials and production permission sit around that technical flow.
What to remember
- The API call is one step in a larger controlled workflow.
- Authentication, mapping, errors and audit logs need named owners.
- The source transaction must have a stable idempotency reference.
- Use the technical documents supplied for the approved BIR environment.
A typical system-to-system flow
Each layer should have one clear responsibility.
| Layer | Responsibility | Failure to plan for |
|---|---|---|
| ERP, POS or CAS | Create and own the transaction | Missing or unstable source fields |
| Integration layer | Map, validate, submit and track | Duplicates and hidden retries |
| BIR interface | Receive and return the official result | Timeouts and service advisories |
| Operations | Reconcile and resolve exceptions | Orphaned transactions |
Design the request before writing code
Start with representative invoices, credit events, cancellations and branch cases. Map every source field to its business meaning before mapping it to a technical payload.
Keep transformation rules versioned. A field should not change meaning because two developers interpreted the same label differently.
Treat the response as business data
Store HTTP results, business response codes, timestamps and the final accepted or rejected state. Return a smaller normalized status to the source system.
A timeout is unknown, not failed. The retry process should first determine whether the earlier request reached the service.
Use a controlled integration boundary
EazLink gives source systems one interface while the configured BIR EIS connector handles the external contract. This reduces changes in each ERP or POS.
Access to BIR test and production interfaces depends on the official onboarding and permission process.
API design review
- Select representative source transactions.
- Define the payload contract and validation rules.
- Design authentication and secret handling.
- Define idempotency, timeout and retry rules.
- Make reconciliation visible to operations.
Quick questions
Is BIR EIS just one API call?
No. A working project also needs onboarding, data mapping, authentication, response handling, exception work and reconciliation.
Should the ERP call the BIR interface directly?
It can, but direct coupling puts BIR-specific changes and credentials inside the ERP. Middleware often creates a cleaner boundary.
What should happen after a timeout?
Treat the state as unknown until the integration checks the available status or applies the approved recovery procedure.
Continue the preparation
Sources and verification
Check the current BIR rules and portal notices before making a compliance decision.