BLOG
GİB e-Beyan REST API vs. BDP
GİB’s e-Beyan platform allows system-to-system integration through REST APIs, while the Declaration Preparation Program (BDP) remains one of the channels used to prepare and package Turkish tax declarations. Treating them simply as “new versus old” misses the operational decision. The correct channel depends on the declaration type, tax period, province or tax-office rollout date, taxpayer authorization, and the scope GİB has enabled in the relevant environment.
What does BDP do?
BDP is GİB’s desktop declaration preparation application. A user prepares the declaration, runs its controls, and submits the resulting package through the electronic declaration channel. In an SAP landscape this can create a sequence of extracting data from SAP, checking it in a spreadsheet or another intermediate format, and transferring it into BDP.
A BDP-based workflow is not automatically invalid or obsolete. It can remain the applicable channel for particular declarations and periods. Some period checks documented in GİB’s APIs can also return messages instructing the user to file an earlier period through BDP.
What changes with the e-Beyan REST API?
For declarations that GİB has enabled, the e-Beyan APIs allow an authorized system to manage preparation, data transfer, validation, approval, status queries, and document retrieval. GİB’s integration guide requires organizations to:
- Apply for e-Beyan integration through the Digital Tax Office.
- Register and obtain approval for fixed IP addresses used by test and production environments.
- Create a separate API key for each environment.
- Send requests from an approved IP using Bearer authentication.
- Keep API keys out of public platforms and store them securely.
In an SAP integration, this model can preserve the relationship between a source record, declaration line, and GİB response. The presence of an API does not mean that every declaration and period is automatically supported.
BDP and REST API compared
| Topic | BDP-oriented flow | e-Beyan REST API flow |
|---|---|---|
| Interaction | Desktop application and package transfer | Web service between authorized systems |
| Scope | Forms and versions published for BDP | Declarations enabled for the relevant GİB environment, period, and province or taxpayer |
| Data source | File or user input | Auditable transfer from a source system such as SAP |
| Status tracking | Across application and portal steps | API responses linked to the source transaction |
| Authentication | GİB user and submission mechanism | Approved IP and environment-specific API key |
How should the filing channel be selected?
Instead of promising a universal “BDP-free” process, prepare a decision record for each scenario:
- What are the declaration type and tax code?
- Which tax period is being filed?
- Is the taxpayer’s province or tax office within the phased rollout for the target period?
- Has GİB enabled the declaration in test, pilot, or production?
- Does the taxpayer have filing and integration authorization?
- Is this an original, corrective, voluntary-disclosure, or late filing?
- How will returned statuses and documents be archived in SAP?
This turns a marketing statement into an implementable technical scope. Continue with the declaration, period, and filing-channel scope guide and the SAP E-Beyanname integration architecture.
Fenikstech only treats submission as available where GİB has enabled the applicable declaration, period, province or taxpayer, and environment. Explore the interactive simulation of the SAP E-Beyanname solution.
Official sources
- GİB e-Beyan Integration Guide
- GİB announcement of 20 July 2026 on the phased KDV e-Beyan rollout
- GİB e-Beyan REST API developer documentation
- GİB e-Beyan user documentation
This article was reviewed against the official sources on 23 July 2026. Check GİB’s latest announcements before implementation because enabled scope can change.