API Policy

How Gurdx versions its API, announces changes and retires old behaviour, so you can plan upgrades.

Stability promise#

Gurdx keeps a stable contract: paths, parameters, the {data, status, executionTime} success envelope and error codes 101 to 127 delivered over HTTP 200. We treat that contract as stable and will not change it silently. Anything we add on top is additive: new fields, new endpoints and new error codes (128 and above).

Write your client so that it ignores fields it does not know. Do not assume the list of fields in a response is closed.

Versioning#

Releases use MAJOR.MINOR.PATCH numbers, listed on the Changelog.

Deprecation#

When a feature, field or version is going to be removed:

1. We announce it in the documentation, by email to account owners and in the dashboard.
2. We give at least two months of notice for removals that can affect a working integration.
3. After the notice period the old behaviour may stop working. Security fixes are the exception and can be applied immediately.

Rate and fair use#

Use the API for your own application. Do not resell raw access, probe the service for weaknesses, or attempt to bypass quota, flood limits or authorized-host rules. Accounts that abuse the service can be suspended (error 102). Limits are described on Usage limits.

Data handling#

• Raw request logs are kept for a limited retention window; usage counters are kept longer.
• Card numbers are never stored.
• You can request deletion of end-user data through User Data Deletion.

Support and notices#

Important notices are sent to the email of the account owner, so keep it up to date in the dashboard (https://gurdx.cretip.com/app). If something behaves differently from this documentation, report it to support and include the request URL (without your key) and the response body.