Skip to content

Terms of Use ​

Last updated: June 13, 2026

These terms describe acceptable use of the public TurkiyeAPI service. They are intended to set clear expectations for a free public API.

Independent Project ​

TurkiyeAPI is an independent open/public API project. It is not affiliated with, endorsed by, or operated by any official government institution.

Free Public Access ​

TurkiyeAPI is provided free of charge and does not require authentication for normal public access.

Access may be limited, changed, or blocked when needed to protect the service, prevent abuse, or keep the API available for other users.

Acceptable Use ​

You may use TurkiyeAPI for lawful applications such as address forms, location selectors, reporting tools, public data exploration, and internal data workflows.

You must not use the API to:

  • Perform illegal activity.
  • Build or support fraud, deception, phishing, spam, or misleading services.
  • Attack, overload, disrupt, scrape abusively, or reverse engineer the service in a harmful way.
  • Bypass rate limits or other protective controls.
  • Send secrets, credentials, personal data, or confidential data in query parameters or request payloads.
  • Misrepresent TurkiyeAPI as an official government service.

Rate Limits and Blocking ​

The API may apply rate limits. Excessive, automated, harmful, or abnormal traffic may be throttled or blocked.

If you need higher-volume usage, prefer dataset downloads when available or contact the maintainer to discuss the use case.

No Warranty or SLA ​

TurkiyeAPI is provided "as is" without a service-level agreement, uptime guarantee, or warranty of accuracy, completeness, fitness for a particular purpose, or uninterrupted availability.

The data is useful for many workflows, but you should verify it independently before using it in critical, legal, financial, emergency, or safety-sensitive systems.

Changes ​

Endpoints, response fields, datasets, rate limits, and infrastructure may change over time.

The project aims to document breaking changes and migration paths when practical, especially for stable API versions.

v1 and v2 ​

v1 is the legacy API. v2 is the current API surface documented in this guide.

New integrations should use v2 unless they specifically depend on v1 behavior.

Contact ​

For questions, report an issue or start a discussion in the GitHub repository.