Kibot API Client (.NET)
Kibot API Client is an open-source .NET application that demonstrates the full communication between a client and the Kibot Historical Data API. It ships as both source and binary, covers authentication, gzip decompression, and per-symbol historical-data download, and is intended as a starting point for anyone building a Windows-hosted downloader or extending Kibot data access into an existing .NET application.
What it is
Kibot describes the project as "an open-source application written in .NET that demonstrates the communication between the client application and our servers. The application contains all the source code required for authentication and download of historical data from our servers" (per the Kibot API Client page). In practice it is a small Windows Forms application with one main form, a few helper methods, and zero third-party dependencies beyond what ships with the .NET base class libraries. Anything Kibot's Kibot Agent desktop tool does over the API is reproducible from this codebase; Agent is functionally a more elaborate UI layered on the same call patterns.
What is in the download
The download page exposes three artefacts, each useful for a different audience:
| Artefact | Audience | Contents |
|---|---|---|
| Source, VB.NET 2010 | Visual Studio 2010+ users | Full VS solution: forms, code-behind, project file |
| Source, C# 2010 | VS 2010+ users on the C# side | Same solution structure, C# language surface |
| Source, VB.NET 2008 | Legacy .NET 2.0/3.5 toolchains | Same code, older project format |
| Source, C# 2008 | Legacy C# users | Same code, older project format |
| Compiled binary | Anyone with .NET Framework 2.0+ installed | Drop-in .exe plus required DLLs |
| Portable version | Users without admin rights | Single standalone .exe, no runtimes or installation required |
| .NET Framework 2.0 runtimes | Bare Windows installs | Microsoft runtime installer, only needed if the host has nothing newer |
The portable variant is the fastest way to confirm a Kibot account works end-to-end without installing anything, copy the .exe to a folder, double-click, log in, request data.
Runtime compatibility
Kibot API Client is built against .NET Framework 2.0 and is forward-compatible with every later Framework runtime (3.0, 3.5, 4.0, 4.5, 4.6, 4.7, 4.8). That choice keeps the binary universally runnable on modern Windows, the inbox .NET Framework 4.8 on Windows 10 and 11 has the 2.0 compatibility shim and runs the executable without extra installs. If a target machine has only a clean Windows install with no Framework, the bundled .NET Framework 2.0 Runtimes installer covers it.
For new .NET Core / .NET 5+ codebases, the sample is still useful as reference but should not be linked against directly. Port the call sequence to HttpClient with HttpClientHandler { AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate, UseCookies = true }, the line-by-line equivalents are documented in the .NET section of API client examples.
Building the source
To open and modify the project, install Microsoft Visual Studio (any edition from 2008 forward). The free Visual Studio Community works for non-commercial use; the older Visual Studio 2010 Express, originally recommended on Kibot's download page, still opens the 2010 solution files cleanly. Pick the language and toolchain that matches the codebase you will integrate the result into; the VB.NET and C# versions are line-for-line equivalent.
The build steps are conventional:
- Download and extract the source zip for your chosen language and Visual Studio version.
- Open the
.slnfile in Visual Studio. - Restore any NuGet packages (the default project does not reference any; this step is for forks that add HTTP libraries or logging).
- Build the solution. The output is a single Windows Forms executable.
- Run the binary, enter your Kibot credentials, and confirm a sample download succeeds.
How it maps to the API
The sample exercises the exact endpoint surface documented in API overview. Concretely:
- Login. Calls
http://api.kibot.com/?action=login&user=<email>&password=<pwd>and validates that the response body starts with200. The session cookie returned is captured by the underlyingHttpWebRequestmachinery and reused on subsequent requests. See API authentication. - History fetch. Calls
http://api.kibot.com/?action=history&symbol=<sym>&interval=<interval>&period=<n>withAutomaticDecompressionenabled so the gzip response stream is decompressed transparently before it reaches user code. See History request. - Status / logout. Optional, included to demonstrate the session housekeeping endpoints documented in API authentication.
- Adjustments and snapshot. Not exercised by the bundled UI but trivial to add, they are the same URL shape with
action=adjustmentsoraction=snapshot. See Adjustments request and Snapshot request.
Extending the client
The bundled UI is intentionally minimal: one symbol, one interval, one fetch button. Production downloaders forked from it typically add the same four extensions, in the same order:
Batch symbol loops. Replace the single-symbol form field with a loaded symbol list and iterate. The Kibot session stays valid for 20 minutes of inactivity, so a tight loop reuses one login across the full batch. Re-login only when the server returns 401 Not Logged In; that pattern is what Kibot Agent uses internally and is the canonical way to keep wall-clock time low for batches of hundreds of symbols. Support has confirmed in writing: "Once you login, the server waits for 20 minutes of inactivity before it logs you out. In practice, you only need to login once before you start downloading data and as long as you do not pause or stop the download process you will be able to access API without any problems."
Retry-on-error logic. The api.kibot.com address routes to a pool of physical servers; a transient failure on one back-end can return a sporadic error even when the next request succeeds. Watch for non-200 responses, sleep ~10 seconds, retry. Support's own guidance: "instruct your code to watch for errors and repeat the request if you detect one. This will make your download process more robust. We are using the same logic in our Kibot Agent software."
Bounded parallelism. The server pool tolerates more than one connection per account, but only up to a point. Recommended ceiling is 5 concurrent connections per subscription, past that, downloads slow down rather than speed up because the bottleneck shifts to local disk and the per-server rate-limit guards. The hard limits are higher (historically 20 new connections per second, 40 concurrent), but 5 is the sweet spot in support's experience and matches Kibot Agent's defaults.
Logging and resumability. Persist a per-symbol success/failure log so a long batch can be resumed without re-downloading completed files. Forks running on cloud Windows VMs commonly add a SQLite or simple CSV ledger here. Watch for the gzip-stripping interaction with antivirus and corporate proxies, if a previously-working integration starts returning uncompressed data, the most common cause is that "the antivirus protection or a proxy server on your side may be causing this. Gzipping is probably applied by the web server but antivirus trying to protect http connections unzips server response, checks it and after that rewrites response headers on the fly" (support, 2018).
When to use this vs. rolling your own
Reach for Kibot API Client when:
- You need a Windows GUI downloader and want a working scaffold to extend.
- Your shop is already on .NET Framework and you want a sample that drops cleanly into an existing Visual Studio solution.
- You need to confirm an account works end-to-end against the API before writing any code at all (run the portable
.exe, log in, download).
Roll your own when:
- Your target is Linux or macOS, see the curl, Python, Go, Rust, or TypeScript snippets in API client examples.
- You are on .NET Core / .NET 5+ and want
HttpClient-native code. The line-by-line port is in the .NET section of API client examples. - You need adjustments, snapshot, or tick endpoints that the bundled UI does not expose. The sample is a fine scaffold but you will be adding most of the surface yourself.
Key Takeaways
- Kibot API Client is the canonical open-source .NET reference for the Historical Data API, available as VB.NET and C# source (2008 and 2010 project formats) plus compiled and portable binaries.
- Built on .NET Framework 2.0; runs unchanged on every later Framework runtime including the 4.8 inbox on Windows 10 and 11.
- The sample exercises
loginandhistoryend-to-end withAutomaticDecompressionfor gzip, the right call pattern for batch downloaders. - Common forks add four things in order: batch symbol loops, retry-on-non-200, bounded parallelism (5 connections recommended), and a resumability ledger.
- On modern .NET Core / .NET 5+, port the call shape to
HttpClient+HttpClientHandler { AutomaticDecompression = ... }rather than linking the legacyHttpWebRequestcode directly.
Related
- API client examples, Reference implementations in nine languages, including the modern
HttpClientport of the .NET sample. - API overview, Endpoint inventory, subscription tiers, and the v2 feature set the .NET sample can drive.
- API authentication, Login flow, 20-minute idle timeout, and the skip-login pattern.
- History request, The
?action=historyparameters the sample's data fetch uses. - Server responses, HTTP status codes the sample (and any fork) should branch on.
- Kibot Agent, The full GUI built on the same endpoints; useful to compare extension ideas against.