Data products

The three licensable surfaces — historical exports, the premium realtime feed, and versioned bulk datasets — and the entitlements that unlock them.

Drazill sells three data surfaces. All three sit on the same API key you already have; what separates a licensed key from an unlicensed one is an entitlement — a commercial grant an administrator adds to a key against a signed agreement.

Entitlements are orthogonal to the two permission axes you already know. A key can be perfectly scoped, well inside its rate limit, and still be refused, because the three are ANDed and none implies another:

AxisQuestion it answersWho sets it
Scope (scopes)May this key call this endpoint?You, when you mint the key
Tier (rate_limit_tier)How much throughput?Support / your plan
Entitlement (entitlements)Did its owner license this product?An administrator, against a signed agreement

A refusal on the third axis returns API_KEY_MISSING_ENTITLEMENT (403) — deliberately a different code from API_KEY_SCOPE_REQUIRED, because minting a broader key will never fix it.

1. Historical exports — data:history

REST, JSON or streaming CSV, cursor-paginated, PII-free by construction (no counterparty, order, wallet or user field is ever selected).

  • GET /api/v1/data-exports/markets/{market_id}/price-series
  • GET /api/v1/data-exports/markets/{market_id}/trade-tape

Windows up to the published maximum are open to any authenticated caller — the entitlement does not gate today’s free reads, it extends them. A key holding data:history may request deeper windows; without it, a request past the public maximum returns EXPORT_WINDOW_INVALID (422) naming the grant that would widen it.

Coverage is allow-listed per data source and defaults conservative: first-party markets are exportable, and a provider-attributed market only once that provider’s redistribution terms are cleared. See Compliance & regions.

2. Premium realtime feed — data:live

The institutional WebSocket channels: full order-book depth (orderbook:), the raw trade tape (trades:), and order-level market-by-order (mbo:). See Market by order and Connect & authenticate.

The gate is tier OR entitlement. An API key reaches these channels either by being on the premium feed tier or by holding data:live — a licence should not also require a throughput change. Browser sessions and anonymous connections are unaffected, and the lighter channels (prices:, market:, category:) stay open as they always were.

3. Bulk research datasets — data:bulk

Three curated bundles built on a schedule and delivered as time-limited signed URLs:

DatasetOne row isContents
ticksone executed tradethe anonymized time-and-sales tape
resolved_panelone resolved marketmetadata, price-path summary stats, the outcome label
book_statsone (market, outcome, day)daily spread / slippage aggregates

Each bundle ships as twin objects from the same rows — data.parquet and data.csv — alongside a data dictionary, a README and a manifest.json carrying the row count, a schema hash and the build timestamp.

  • GET /api/v1/data-exports/datasets — the catalog. Public: it also tells you whether you are entitled, and reports the latest built version. If a bundle has never been materialized in an environment, those fields are null rather than a version with nothing behind it.
  • POST /api/v1/data-exports/datasets/{name}/download — a signed URL. ?format=csv selects the CSV twin; ?version= pins a specific build so a citation stays reproducible.

This endpoint requires both data:bulk on the key and an active data licence on your organization. Neither alone is sufficient — the key grant is the technical half, the licence is the paper.

Privacy is structural, not a policy. No research dataset contains a user, counterparty, order or wallet identifier, and none groups by user, so there is no re-identification surface to manage. Bundles built outside production are stamped SIMULATED in the manifest and the README — the mechanism is real, the numbers are a demo.

Pricing

Contact us. Pricing for data licences and paid tiers is set per agreement and we do not publish a rate card, so you will not find invented numbers here. Tell us the volume you expect and which of the three surfaces you need. The per-tier request limits, which are published, are on Rate limits & quotas.

How a licence becomes a working key

Two records have to agree, and a person makes them agree — nothing is automated from a signature:

  1. A data licence is executed for your organization.
  2. An administrator grants the matching entitlements on the specific key(s) you name, as a full replacement set. The write is session-authenticated and audited; a leaked API key can never grant itself a product.
  3. You verify from your side: one call per licensed product.

So a key you mint yourself carries no entitlements, and minting another one will not add any. If a call fails with API_KEY_MISSING_ENTITLEMENT after a licence is in place, the grant has not been applied to that key yet — send us the key prefix rather than creating a new one.

Revoking works the same way in reverse and takes effect immediately: the licence term and status are checked on every request, not at a billing boundary.

Try it first

You do not need a licence to evaluate any of this. A sandbox (drzl_test_) key reads the same public market data, the same catalog, and the same within-window historical exports — see Sandbox and Get an API key. What a test key cannot do is hold a grant it was never given: entitlements are enforced on sandbox and live keys alike, so a sandbox integration exercises the real refusal path rather than a permissive stub.