Your customers get their certificates. You never touch the portal.
Certificates as a feature of your product. One account holds many exporter entities, each with its own DGFT connection, so every customer files as themselves while your product does the work.
A feature your customers are already asking for.
Marketplaces, payment platforms, CHAs, and fintechs serve exporters every day. Every one of those exporters needs eBRCs. This is how they get them inside your product.
Your customers get their Electronic Bank Realisation Certificates inside your product, under your brand. You never touch the DGFT portal.
Every exporter on your platform lives as an entity under your account, each with its own DGFT connection. Every filing belongs to the exporter who made it.
Onboard, connect, pull remittances, generate, poll, download. JSON in, a request ID back, the PDF out, usually in about two hours.
Onboard, connect, pull, generate, poll, download.
The whole certificate lifecycle over REST. Your brand in front. Their certificates on time.
Each exporter is an entity under your account with its own DGFT connection. Their filings are theirs; the product experience is yours.
Start free and build: 250 production certificates a month and 10 exporter entities are included, with sandbox use not metered. When your volume outgrows that, a quote is one contact-form message away.
Prove the whole flow against a real sandbox before anything is legally binding, and every certificate records which environment produced it.
Per-endpoint rate limits are published in the docs, every call returns a request ID, and every endpoint ships with cURL you can paste.
The same filings move through a pre-filled Excel template, .xlsx or .xls up to 5 MB, with per-row validation, and bulk data exports back out as xlsx or CSV.
Sandbox to live,
in four steps.
Prove the flow before anything is real. Go live on your signature, not a leap of faith.
Prove it in the sandbox
Onboard a test entity, pull remittances, generate, poll, download. The sandbox is the default, and nothing in it is legally binding.
sandbox by defaultOnboard your exporters
Create each customer as an exporter entity over the API. Each one connects its own DGFT account and files as itself, inside your product.
POST /v1/platform-customersGenerate and present
Submit mappings, poll by request ID, and pull the PDF into your product when it is ready, usually in about two hours.
~2 hrs, typicallyGo live on your signature
The NDA and production agreement are e-signed in the console. Every certificate records which environment produced it, so a rehearsal can never be mistaken for a legal filing.
e-signed in the consoleAn integration your team ships once and forgets.
The parts your engineers will actually ask about, stated plainly.
One header over HTTPS: x-api-key. Keys are issued per environment and shown once at issue. Keep yours safe; it can't be recovered later, only reissued.
Published per endpoint in the docs. The tightest sit on the endpoints that reach DGFT, so the service stays dependable for every partner.
List endpoints take page and limit, with limit capped at 100. Useful the day a customer has years of remittances.
Consistent JSON envelopes with stable, machine-readable error codes, and a request ID echoed on every error. Surface them in your product as they are, or translate them; either way they never change shape.
An OpenAPI spec, plus copy-paste cURL for every endpoint.
Purpose codes, currency codes, port codes, and field-by-field specs, kept in the docs, so your product can validate before it submits.
Free for general use: 250 production certificates a month and up to 10 exporter entities, with sandbox use not metered. The full definition lives on the pricing page. For committed volume across your customer base or customisation, send your requirement through the contact form and we will come back with a quote.
You always know where your volume stands.
The console is your home as a partner: your volume, your allowance, and every client you generate for.
The volume dashboard: see the ceiling before you hit it
How this cycle is going, in numbers that answer the questions you would actually ask.
- Certificates generated, split into succeeded and still processing.
- The weekly trend, your peak day, and the daily average.
- Allowance, in the open. How much of the monthly allowance remains and how many days are left in the cycle.
The client portfolio: who actually uses it
Every exporter you generate for, ranked by volume and success rate. Product analytics you do not have to build.
- Ranked by volume and success rate, so you can see which customers lean on the feature.
- Exportable to CSV whenever your own reporting wants the numbers.
- Keys at hand. View each key's environment, status, and creation date, and copy the one you need.
One account. Every exporter on your platform.
Enterprises use the API for their own entities. Platforms use it for their customers, so every exporter on your platform files as themselves while your product does the work.
What your customers are trusting you with.
Every filing belongs to the entity that made it. Your customers' records stay separate, entity by entity, certificate by certificate.
The sandbox is the default, live filing is behind an explicit switch, and every certificate records which environment produced it.
Keys are issued per environment and shown once at issue. They can only be reissued, never recovered.
Per-endpoint rate limits live in the docs, and every call returns a request ID, so support conversations start with facts.
PDF downloads, copyable eBRC numbers, and full exports are always available. Their certificates are theirs, wherever your product goes next.
Write to us with a request ID and a real person replies, usually within a day.
Asked, answered.
One account holds many exporter entities, each with its own DGFT connection. Every customer files as themselves while your product does the work.
Yes. Each exporter entity connects its own DGFT account, so every certificate is filed by the exporter it belongs to. Their filings are theirs; the product experience is yours.
Every submission returns a request ID, and you poll a status endpoint until the certificate is ready. It is a simple, dependable contract.
Fetch status by request ID, pull certificate details and the PDF over the API, and present them wherever they belong in your product. Volume and per-client numbers live in the partner console.
It is free for general use: up to 250 production certificates a month and up to 10 exporter entities, with sandbox use not metered. For committed volume across your customer base or customisation, send your requirement through the contact form and we will come back with a quote.
With them. Certificates download as PDFs, eBRC numbers are copyable, and ledgers export in full, at any time.
Your customer's part takes minutes. We usually have the certificate back in about two hours, and status is a poll away the whole time.
Not quite your shape?
Filing for your own entities instead?
The same API serves high-volume export desks: subsidiaries and divisions as separate entities under one account, JSON or Excel in, certificates out.
See how it fits →The app · For ExportersFile your own, in minutes of your time
Remittances arrive on their own and every certificate is a short submission away, with a Test mode so nothing is legally binding until you say so.
Get started →Guides · ResourcesThe eBRC, explained in plain English
Playbooks and guides on eBRCs, inward remittances, DGFT compliance, and the incentives that depend on realisation.
Read the guides →Talk to a human.
A question about certificates, the API, or a filing that will not behave: write to us and a real person replies, usually within a day.
- Exporters: stuck filings, missing IRMs, bulk uploads.
- Platforms and enterprises: API access, sandbox keys, and volume or customisation quotes.
- Anything else: we read everything that arrives.
Prefer email? amin@eximfiles.io
Prove it in the sandbox first.
Generate for every exporter you serve, over one API.