Direct programmatic access to the trade graph for in-house data teams. Four endpoints, stable contract, predictable schema evolution, OAuth 2.0 with hardware tokens for any write path. The graph at the speed of your own data layer.
The CrestAPI surface is deliberately small. Four endpoints — /entity, /lane, /counterparty, /audit — cover the verbs an in-house data team needs against the graph: resolve, score, traverse, verify. We do not add endpoints to support new pricing tiers. We add endpoints when the methodology adds a primitive, and when we do, we publish the addition four release cycles in advance.
The contract is OpenAPI 3.1, versioned in lock-step with the graph and signed against the release tag. Minor schema changes are additive only; major changes carry a twelve-month deprecation window with parallel availability. A customer integrating against v3 on the day this page was filed can plan against v3 through April MMXXVII.
| Endpoint | Verb | Returns | Auth |
|---|---|---|---|
/entity | Resolve · screen | Canonical entity · evidence · scores | Read · OAuth 2.0 |
/lane | Score · forecast | Signal Routes score · contributors | Read · OAuth 2.0 |
/counterparty | Traverse · expose | Bank chain · hops · weights | Read · OAuth 2.0 |
/audit | Verify · receipt | Per-query receipt · version stamp | Read · OAuth 2.0 |
The phrase "stable contract" is used loosely in this industry, so we will be precise. The CrestAPI contract is signed against the release tag of the underlying graph; the signature is verifiable against the public key published in the Library and rotated on a documented schedule. The schema is published in OpenAPI 3.1, with versioned changelogs and a structured "what would break" section for every release.
The deprecation policy is twelve months, parallel availability. If we deprecate a field, the field continues to be returned alongside its replacement for twelve months from the date of the deprecation notice. If we deprecate an endpoint, the endpoint continues to be available — at unchanged rate limits — for twelve months. We have never made an unannounced breaking change. The Library carries the full release history.
The team that owns the data lake, the entity model and the downstream consumers. CrestAPI joins into the existing graph at the entity layer; the join key is published, the deprecation window is twelve months, the receipt is per-query.
The team that ships the customer-facing application — a trade-finance origination platform, a freight-forwarder portal, an SBLC manager. CrestAPI sits behind the application's own auth, with per-tenant audit hooks and per-endpoint quotas.
The consultancy or systems integrator wiring the graph into a customer's existing compliance and trade-finance stack. The reference integrations are in the Library; the support model is direct to the engineering desk for the duration of the engagement.
API keys are issued after the first briefing. The reason is not gatekeeping; it is that we have never seen a useful CrestAPI integration that did not begin with a 45-minute working session against a real portfolio. The briefing surfaces the schema questions, the entity-resolution edge cases and the audit requirements that the integration will run into; getting them onto the page before any code is written has paid back, in every engagement so far, the first day the integration goes live.