FIN-TECHAI API documentation

One REST API, one key, four modules. This page covers the concepts that recur across all of them — coverage, as-of block, reason codes, versioning — so the reference pages do not have to repeat them.

The shape of the API

Everything is HTTPS and JSON. One base URL, one bearer token, one rate limiter shared across modules. There are no long-lived connections to maintain and no message broker to run: you call an endpoint, and where an answer takes longer than a request should, you get a webhook.

Base URL   https://api.fin-techai.com/v1
Sandbox    https://sandbox.fin-techai.com/v1
Auth       Authorization: Bearer ftai_live_…
Encoding   application/json; charset=utf-8

Monetary and quantity values are decimal strings, never JSON numbers — "250000.00", not 250000.00. Floats lose precision on large token amounts, and a rounding error in a payout is not a rounding error to the recipient.

The four modules

Modules are licensed independently and share nothing except authentication and rate limiting. A key scoped to Sentinel calling /credit/profile gets a 403, not an empty result.

Concepts you will meet everywhere

Coverage

Every response carries a coverage object naming the chains consulted and flagging any that were stale. This is the most important field in the payload and the one most integrations ignore. An address funded through a chain we do not index looks newer and cleaner than it is — coverage is how you know.

"coverage": {
  "chains": ["ethereum", "solana", "tron"],
  "stale": [],                // chains lagging head materially
  "excluded": ["bitcoin"]     // not ingested at all
}

As-of block

Scores and profiles are stamped with as_of_block, the height they were computed at. Compare it to your own view of head to distinguish a stale answer from a wrong one. During an ingest incident this is the field that tells you what is happening; the status page is the slower signal.

Reason codes

No score is returned without the weighted signals that produced it. Reason codes are stable, documented strings — match on the code, never on the human-readable message, which may be reworded at any time.

"reasons": [
  { "code": "MIXER_PROXIMITY", "weight": 34, "hops": 2 },
  { "code": "HIGH_VELOCITY_FUNNEL", "weight": 22 }
]

New codes are added over time and are additive: an unknown code should be logged and ignored by your integration, never treated as an error. Weights sum to the score.

Idempotency

Any state-changing call accepts an Idempotency-Key header. Retrying with the same key returns the original result rather than repeating the action — which for a payout is the difference between a retry and a double-send. Keys are retained 24 hours.

Versioning

The URL carries the major version. Additive changes — new endpoints, fields, reason codes — ship without a version bump, so your integration must tolerate unknown fields.

Every release is on the changelog with a breaking-capable flag.

Where to go next