Richtlinien
Wie die Data API versioniert wird, wie Abkündigungen angekündigt werden und wie lange sie laufen, und wie du ein Sicherheitsproblem meldest.
Die API wird über den Pfad versioniert: Jeder Endpunkt liegt unter /api/v1. Die info.version des Vertrags (aktuell 1.1.0) folgt dem Changelog: Die Minor-Nummer steigt, wenn etwas hinzukommt, die Patch-Nummer, wenn etwas behoben wird, und eine neue Pfadversion (/api/v2) ist der einzige Weg, auf dem ein Breaking Change ausgeliefert wird.
Die acht offiziellen SDKs folgen der API: Ein neuer Endpunkt ist ein Minor-Release des SDK, ein entfernter oder umbenannter ein Major-Release.
Das passiert innerhalb einer Pfadversion nie:
{ data, meta }-Envelope, den Fehler-Envelope oder die Bedeutung eines bestehenden Fehlercodes ändern.Das kann jederzeit passieren und wird im Changelog angekündigt:
error.code, nie auf die Nachricht.Wenn ein Endpunkt, Parameter oder Feld zur Entfernung vorgesehen ist, wird das im Changelog und per E-Mail an jeden Key-Inhaber angekündigt, und ab diesem Tag antwortet der Endpunkt mit den Headern Deprecation und Sunset (RFC 9745, RFC 8594), die das Entfernungsdatum nennen. Der OpenAPI-Vertrag markiert es mit deprecated: true.
Die Entfernung erfolgt frühestens sechs Monate nach der Ankündigung. Eine neue Pfadversion läuft mindestens sechs Monate parallel zur vorherigen, bevor die alte auf dieselbe Weise abgeschaltet wird.
Burst-Limits pro Minute und Monatskontingente sind Teil deines Plans, werden auf jeder Antwort in den Headern X-RateLimit-* und X-Quota-* gemeldet und sind in der Referenz dokumentiert. Ein Limit anzuheben ist nie breaking; eines innerhalb eines Plans zu senken schon - und folgt dem Abkündigungszeitplan.
Wenn du glaubst, eine Sicherheitslücke in bitculator.com, der Data API, dem MCP-Server oder den SDKs gefunden zu haben, schreib an contact@bitculator.com - mit der betroffenen URL oder dem betroffenen Endpunkt, Schritten zur Reproduktion und der Auswirkung, die du siehst. Du bekommst innerhalb von drei Werktagen eine Antwort.
Bitte halte die Meldung vertraulich, bis das Problem behoben ist, greife nicht auf fremde Daten zu und verändere sie nicht, und führe keine Denial-of-Service-Angriffe oder automatisierten Scans gegen die Produktion aus. Meldungen, die in gutem Glauben unter diesen Bedingungen erfolgen, werden nicht mit rechtlichen Schritten beantwortet. Es gibt kein bezahltes Bug-Bounty-Programm; auf Wunsch wird namentlich gedankt.
Derselbe Kontakt ist maschinenlesbar unter /.well-known/security.txt (RFC 9116) veröffentlicht.
Der Live-Status der Komponenten, offene Vorfälle und die Ausfälle der letzten 30 Tage stehen auf der Statusseite und unter /status.json.