The eBRC API, Explained: Certificates Over REST for Platforms and Enterprises
For one certificate, a portal is fine. For a thousand customers who each need certificates, only an API makes sense. Here is what an eBRC API actually promises, and how to judge one.
The real contract
Strip the marketing from any filing API and the honest shape is this: submit once, get a request ID, poll for status. The eBRC version runs over REST with JSON, authenticated with an API key header. You push a filing, a single mapping or an array, hold the request ID, and poll until the certificate exists. The PDF is then a download away. Excel works as an input alongside JSON, because export desks live in spreadsheets and pretending otherwise helps nobody.
What to demand from the integration
- A real sandbox, first. Build against an environment where nothing is legally binding, with the same validations as production. Every certificate should record which environment produced it, so test artefacts can never masquerade as real ones.
- Row-level errors. When a bulk submission fails, the answer must name the row and the field. Anything vaguer turns integration into archaeology.
- Idempotent resubmission. Fixing and resubmitting must never create a duplicate filing. This single property is what makes retry logic safe to write.
- Published rate limits and a request ID on every call. Dependable integrations are built on documented limits, not discovered ones.
- OpenAPI and cURL for every endpoint. If the reference cannot be pasted into a terminal, the reference is not finished.
Multi-entity: the part platforms actually need
A marketplace, a CHA, or a cross-border payments company does not export anything itself. Its customers do. The structure that respects that reality holds many exporter entities under one account, each with its own DGFT connection, each filing as itself. Your customers get their certificates under your product experience; the filings remain legally theirs. The platform never touches a portal, and neither do its customers.
Production access in this world is rightly contract-gated: a signed NDA and production agreement before live filings, because these are legally binding government submissions. Rigour there is a feature, not friction.
Who integrates this, and why
- Payment platforms and cross-border finance companies. Their exporter customers already receive foreign payments through them; certificates are the missing last mile of the compliance story. The distinction between payment advices and realisation certificates is exactly the one in FIRA, FIRC, e-FIRC, eBRC.
- Marketplaces and export enablers. Sellers who export need certificates for RoDTEP and drawback; a platform that closes that loop keeps its sellers.
- High-volume exporters. Enterprises with subsidiaries file at scale from their own systems, each entity under one roof. The same contract, pointed inward.
Judging readiness in one afternoon
Read the lifecycle endpoints, run the cURL examples against the sandbox, submit a deliberately broken bulk file, and watch how the errors come back. Those four moves reveal more than any sales deck. The API documentation is public for exactly that reason, the platform structure is described on the platforms page, and for volume pricing and production agreements, talk to a human with your requirement and get a quote.
Frequently asked questions
What is the eBRC API?
A REST interface for generating electronic Bank Realisation Certificates from your own systems: submit filings as JSON or Excel, receive a request ID, poll for status, and download certificate PDFs. One account can hold many exporter entities, each with its own DGFT connection.
Can a platform generate certificates for its customers?
Yes, and correctly so: each customer connects their own DGFT account and files as themselves under the platform's account. The certificates are legally the exporter's; the experience is the platform's.
Is there a sandbox?
Yes, and it is the default. Nothing is legally binding until an explicit switch to production, which is contract-gated behind a signed NDA and production agreement.
What formats does submission accept?
JSON for system-to-system integration and Excel for desks that live in spreadsheets. Both are validated row by row, and resubmission never creates a duplicate filing.
