EIS Bridge™ — trademark application pending · IPOPHL Class 42 · Ref EFPH202600003850268
← Marketing site

Support

Get help with integration, API keys, and production certification.

Get API Key

Vendor API keys are issued to registered POS/ERP vendors during onboarding. Your vendor administrator can generate and rotate keys in the EIS Bridge Console.

  1. Complete vendor registration with EIS Bridge.
  2. Receive sandbox credentials: API key, test merchant_code, branch_code, and pos_device_id.
  3. Integrate and pass the QA certification suite.
  4. Request production API key after certification sign-off.

Not yet registered? Contact support@eisbridge.com to begin vendor onboarding.

Contact

Changelog

v1.0 — Initial release (2026)

First public Vendor API release.

  • POST /transactions — single transaction submit
  • POST /transactions/batch — batch submit
  • GET /transactions/{bridge_transaction_id} — status retrieval
  • GET /transactions — list with filters
  • POST /vendors/webhook — webhook configuration
  • Standard Sale Object JSON schema v1.0
  • Postman Collection v1.0
  • QA Integration Test Suite v1.0

FAQ

Does EIS Bridge replace merchant EIS CERT and PTT?

No. BIR certifies taxpayer systems, not software providers. Each merchant must complete EIS registration, EIS CERT, and Permit to Transmit (PTT) on eis-cert.bir.gov.ph. EIS Bridge handles technical mapping, signing, and transmission once the merchant is onboarded. See the Certification Playbook.

Is EIS Bridge accredited by the BIR?

No. EIS Bridge is independent software and is not affiliated with, endorsed by, or accredited by the BIR. EIS Bridge assists with technical transmission workflows only and does not provide tax, legal, or accounting advice.

Why am I getting validation_error?

A validation_error (HTTP 400) means one or more fields failed schema validation. Check the fields array in the response for the specific paths — common causes include missing totals.net, invalid ISO 8601 datetime, negative qty, or unknown properties. Validate your payload against the Standard Sale Object and JSON schema.

How do I handle duplicates?

Use a stable transaction_id from your POS receipt number, scoped per merchant + branch + device. If you resubmit identical data, EIS Bridge returns status: duplicate with the original bridge_transaction_id — treat this as success. If the same ID is sent with different data, you receive HTTP 409 (transaction_conflict). See Idempotency rules.

How do I test T+3 scenarios?

Run test case TC-72 (Offline POS — Delayed Transmission): create a sale with transaction_datetime set 24–48 hours in the past, then submit. The transaction should still be accepted within the T+3 compliance window. Full steps are in the QA test suite.