turkish-apis: a directory of APIs built in Turkey

What the repository actually is: two tables and an examples directory

turkish-apis is a repository to store Turkish and Turkey based APIs, and it says so in both of its languages. The English README opens with that description and the Turkish README repeats it as a repository listing APIs of Turkish or Turkish origin, inviting contributions to it.

The structure is small. The top level entries are `CONTRIBUTING.md`, `LICENSE`, `README.md` and an `examples/` directory, and the repository has no releases and no package of any kind. That is the whole shape: a document, a licence, a contribution guide, and some example code.

The document itself is two tables. The English table is titled English and the Turkish one Türkçe, and each has the same four columns: the API with a link, a description, the auth method, and whether HTTPS is supported. The two tables do not hold the same set of entries, which is worth noticing. The English table leads with the Akbank API Portal and includes Garanti BBVA, İş Bankası, Vakıfbank, QNB Finansbank, ininal, Ziraat Katılım, Kuveyt Türk and Denizbank among the banks, and covers BtcTurk and Paribu in crypto, Trendyol, n11 and Yemeksepeti in commerce, bip in messaging, DergiPark and TUIK in public data, plus intertech, iyzico, Countly and Dahi.ai. The Turkish table includes entries the English one does not, such as the Atlas API from the General Directorate of Mapping, the Presidency's Digital Transformation Office electronic correspondence APIs, the e-Nabız personal health records service, EPİAŞ for energy market data, FedEx shipping, and the İTÜ ECC academic group API, alongside banking and commerce entries that overlap.

So the list is genuinely a directory of Turkish-origin services rather than a curated shortlist of the biggest ones, and a developer in the UK looking for a Turkish tax authority endpoint would find it here and not in the English table at all.

The auth and HTTPS columns are the reason the list is worth keeping

Two of the four columns are what turn a link dump into something you can act on, and they are the columns to read first.

The auth column records the authentication scheme each API uses, and the values are close to a controlled vocabulary: OAuth dominates the bank and platform entries, apiKey appears on the developer portal style services and the public data endpoints, None appears for exactly one entry, and one entry is recorded as Unknown. EPİAŞ, the energy market operator, is the Unknown one, which is a useful signal in itself, since it means the author could not determine the scheme from the public documentation.

The HTTPS column is more consequential than it looks, and it is not uniformly positive. Dahi.ai, the bot building service, is marked as not supporting HTTPS, and Yemeksepeti, the food ordering API, is also marked as not supporting HTTPS. The Turkish table records the same two exceptions in Turkish as Var, meaning present, against the entries marked Hayır for absent. The Garanti BBVA row in the Turkish table even carries the English word Yes in the HTTPS column, a small copy and paste artefact that shows the table is maintained by hand.

For a developer, those two columns are the ones that decide whether an API is a candidate. An apiKey scheme with HTTPS support is a request with a header. OAuth means you need a token lifecycle, a refresh flow and an account, which for a bank portal usually means a business agreement before you get a credential at all. And a no-HTTPS entry is a genuine disqualifier for anything touching production traffic, because the credentials travel in the clear.

The descriptions also carry real information rather than repeating the name. Countly is described as a product analytics platform, and the entry says the service provides customizability and privacy-first approaches to product development. iyzico is a company offering virtual POS services in Turkey. Kuveyt Türk's entry says it is the API for an API banking system. Those phrases are short, but they tell you the shape of the business relationship you are about to enter.

What the examples directory actually shows you

The `examples/` directory is the part that turns a list into a resource, and it is worth understanding before you point a client at any of these APIs.

The directory holds one subdirectory per worked example, and the names visible in the tree are BarkodOku, BtcTurk, GenelPara, NVI_KPS, SPK, Tuzla_Belediyesi and a shared `EXAMPLES.md` index.

The spread is instructive. GenelPara is a financial market data service, so its example presumably shows a market data request with a key. BtcTurk is the crypto exchange, so its example shows an authenticated market or account endpoint. NVI_KPS points at the Turkish national identification number registry, and SPK at the Capital Markets Board, and both of those are public authority APIs with a different shape again, where the interesting question is whether a key is issued to an individual or only to an institution. BarkodOku is the barcode lookup service, a simple GET with a key. Tuzla_Belediyesi is a municipal API, which suggests a third pattern again: a local government service with its own registration process.

So the examples are not a tutorial with a single narrative. They are a set of per-service demonstrations, each showing the request shape for one kind of provider, and the collection covers the range from a plain key in a query parameter to an OAuth flow against a financial institution.

The `EXAMPLES.md` file is the index into them, and the README links to the examples directory from both language sections with the labels Check Examples and Örneklere Göz At. The repository's topics back this up: `examples-python` is one of the listed topics, which tells you the example code is written in Python, and topics like `collection`, `list` and `public` describe the repository rather than any of the APIs in it.

Contributing, and the two language lists as a maintenance problem

The repository invites contributions from both the English and Turkish side, and the contribution guide is linked from both descriptions.

What that means in practice is the interesting part, and it is a maintenance characteristic rather than a feature. The list exists twice, in two tables, with different entries. A new API added to the Turkish table has to be added to the English table as well if it is to be visible to English readers, and the same entry has to be written in two languages, each with its own auth and HTTPS values. A field corrected in one table can easily be left stale in the other, and the Garanti BBVA row with an English Yes in the Turkish table is exactly the kind of artefact that duplication produces.

The topic list also carries an `english` topic alongside `turkish` and `turkiye`, and `trendyol`, `isbank` and `btcturk` are topics too, which is a hint that the repository has been used as a reference source for those services specifically.

The commit record gives the maintenance picture. The repository is not archived and the last push was on 2026-06-01, with no GitHub releases at all. That date is more than four months before the point at which this is being written, and a directory of third-party endpoints is a different kind of project from a library: the list can go stale without anything in the repository changing, because the services it points at change on their own schedules. A bank can retire an API version, an exchange can change its base URL, a municipal portal can disappear.

The licence is MIT, so the list itself is permissively licensed and copying entries into your own notes or an internal wiki is straightforward. What the licence does not do is make the listed APIs yours to use, since each of those has its own terms and, in the case of the financial and health entries, its own regulatory and registration requirements.

Where this list stops and what to use instead

Three limitations follow from the format itself, and they are worth naming before you spend a day working through twenty developer portals.

The first is that the list is not verified in any ongoing way. There is no service status, no last-checked column, and no automation described that probes the endpoints. The auth and HTTPS values were correct at the moment somebody wrote them, and for a fast moving platform like a crypto exchange that can be months stale. The Unknown value on the EPİAŞ row is the honest case, and there is no way to tell from the table which other rows are in that condition.

The second is that the list contains no worked production advice for the hard services. For an apiKey service the request is obvious. For a bank API under OAuth there are business prerequisites, application forms, environment separation and a certification process, and none of that is in this repository. The list gets you to the right portal; it does not get you a credential.

The third is that it is a static document with no package, no client library and no versioning. There is nothing to depend on and nothing to upgrade.

The alternative approach is a directory you trust for currency rather than a list you trust for coverage. A provider's own developer portal is authoritative on its own auth scheme and its own HTTPS support, and most portals in this list are the only place that information is correct. So the sensible use of turkish-apis is as a map, and the sensible use of a portal is as the source of truth, and the difference in approach is the difference between a list and a contract.

The other alternative is a general API aggregator or a Turkish developer community directory, which tend to track a larger number of smaller and more local services than a single curated repository can, at the cost of the same verification problem plus advertising. For a specific integration, an aggregator's listing of the same bank is no more current than this list's, but it is often easier to search.

Editorial conclusion

Use turkish-apis as a starting point when you need a Turkish provider and do not know which ones exist, because the English and Turkish tables make the coverage of banks, e-commerce, crypto, messaging and public data visible at a glance and the auth column saves a round of documentation reading. Do not treat it as a dependency or a service contract, because it is a list of links with no package, no versioning and no uptime promise. Before you build on any entry, open its developer portal and confirm that the authentication method and HTTPS support listed in the table still match the current documentation, and check the `examples/` directory to see whether someone has already worked out the request shape for that particular API.

Frequently asked questions

Official sources

1. 3rt4nm4n/turkish-apis on GitHub
2. Issues
3. License: MIT
4. README