Decentralised News · Agentic Finance · Decision research
By Heath Muchena · Source review 2026-11-14 · Instrument version 1.0.0
What Matters
An API can keep returning valid responses while the meaning of a field, cancellation or account scope changes. Review the workflow assumption affected by each change, then bind the relevant regression evidence to the actual client build. A completed change record supports human review; it is not a deployment approval.
The trading service is online. Its requests return JSON. Its old smoke test still passes. None of those observations proves that the service interprets the exchange correctly after an API change.
The useful unit of review is a chain: dated provider change, affected operation, client assumption, regression fixture, tested build and responsible reviewer. This article uses current Kraken documentation as concrete examples of eight kinds of change. It is an integration method, not an exchange ranking or a claim that DN has observed these changes causing customer losses.
The examples and local worksheet are synthetic. No exchange account was connected, no order was submitted and no venue compatibility test was executed for this article.
DN Evidence Block
Sources reviewed: 2026-11-14 · Evidence type: Current primary API documentation and an original DN change-to-assumption review method. Sources checked on 13 November 2026 UTC.
Scope: Documented Kraken API examples; the record can organize changes for another provider only after its own specification is reviewed.
- Current documentation contains dated retirements and changes to authentication, fee data, pagination and cancellation behavior.
- Endpoint behavior and client test expectations are kept separate: provider documentation supports the example; DN proposes the regression question.
- The local instrument checks entered evidence and build binding. Its own synthetic checks do not establish exchange compatibility.
Not established by this work: No exchange API, account, order, transfer or trading strategy was tested. No outage, customer loss, profitability, benchmark ranking or successful migration is claimed.
Original DN instrument · version 1.0.0
DN API Change Impact Register
Record one API change and its workflow assumption. Check missing evidence, reported test/build mismatches and the entered calendar date. Download a local JSON record for human review; no exchange connection or deployment verdict is produced.
Enter your assumptions or load a labelled example. Required blank numbers stay missing; unknown evidence remains unknown. Use nonpersonal labels only. This instrument makes no network requests and uses no persistent browser storage.
Use your own inputs
No current result. Complete inputs or load an illustrative example.
Entered source and fixture references are not fetched or independently verified. A pass is a user-reported result, not a test performed by this tool. One change per record; shared dependencies and full migration coverage require separate review. Calendar days do not represent exact cutoff times. No credentials, account identifiers, personal names, API requests or persistent storage are needed.
1. Endpoint retirement changes the workflow, not just the URL
Record the API family, operation and affected account before scheduling a migration. A similar path on another API is not necessarily the same service. An endpoint retirement can change where a financial action is recorded, whether a response represents completion, and what the client should do after a timeout.
Kraken’s 12 November 2026 release notes schedule the legacy Derivatives POST /withdrawal and GET /transfers routes for removal on 30 November 2026. The documented replacement is POST /transfer, including transfers to or from Spot. The new transfer completes before its response is sent.
The assumption to review: “A successful response only creates a pending transfer that my worker must poll.” Preserve the old assumption even when it is now wrong; otherwise the reason for changing the code disappears.
The fixture to design: a completed transfer response, a timeout with an unresolved outcome, and a subsequent authoritative account record. Check that the client does not manufacture a second transfer simply because the old polling identifier is missing. This is a proposed regression scenario, not a report of an observed Kraken failure.
2. Authentication and message formats can move together
A streaming migration may require a new credential flow and a different parser. Updating the connection address while leaving the subscription envelope unchanged is an incomplete migration. Separate the public market-data path from private account streams and order entry, because they may have different authorization requirements.
The current Derivatives WebSocket guide announces a 1 March 2027 end date for the legacy stream. Its Unified WebSocket replacement uses a different message structure and a token obtained with a Kraken API key, rather than the legacy Derivatives-key challenge flow. The guide also requires explicit selection of the Derivatives asset class.
The assumption to review: “My existing authenticated subscription and parser remain valid on the new connection.” A connection that opens successfully is only evidence of transport availability.
The fixture to design: public subscription, rejected private subscription, authorized private subscription, reconnect and unexpected asset-class response. Confirm that an error cannot be parsed as a quiet market or an empty account. Keep credentials out of the review record; store a nonsecret configuration reference and the permissions required for that workflow.
3. A field can remain valid JSON after it stops carrying useful data
Type checks are useful but insufficient. A response may still contain the expected key and array type while the data source behind that field has changed. If the application treats an empty collection as an economic zero, the failure can travel into quoting, position sizing or profit attribution without producing a parser exception.
The current AssetPairs reference shows empty fees and fees_maker arrays. Kraken’s dated release notes explain that those fields were retained for compatibility after their fee data was removed. The TradeVolume reference is the documented fee-query source and distinguishes pair-specific fee responses from a request that supplies no pair.
The assumption to review: “The fee field exists, so I have a usable fee schedule.” The replacement assumption should identify the product, pair, fee side and source that the workflow actually needs.
The fixture to design: an empty legacy array, a missing pair, a valid zero fee and an unavailable fee query. These cases must remain distinguishable. A genuine zero may be used as zero; missing information should leave the estimate unresolved or trigger the explicitly approved fallback. Do not silently convert uncertainty into a more attractive trading estimate.
4. Pagination can change the meaning of a complete history
An exporter can produce a well-formed file that omits part of the account history. The dangerous assumption is often a stopping rule: a total count, a fixed page size, or an offset that the new endpoint no longer supports in the same mode.
Kraken’s Ledgers documentation supports cursor pagination. In that mode the response count is null, the next-page token determines whether more results exist, and a nonzero offset cannot be combined with cursor mode.
The assumption to review: “A missing count means there are no more records.” State completeness as an observable requirement: every page in the requested range was followed, duplicate identifiers were handled consistently, and the terminal condition was recorded.
The fixture to design: at least two pages with a null count, a nonempty continuation token and a final page without one. Add a repeated page and an interrupted export. A resilient client should not equate a successful first page with a complete ledger. The result reference should identify the build and fixture data used; a screenshot of an empty error log does not establish completeness.
5. A new error code may require a different recovery decision
Error handling is part of the financial workflow. Repeating every rejected request can amplify an authentication problem, while treating every limit response as permanent can strand work that should have been queued. Record the recovery decision associated with each class of failure, not just the text displayed to the operator.
The current Maker Protection guide distinguishes the concurrent hold cap from the open-order limit and documents a separate error for the former. Separately, Kraken’s Spot error guide warns that repeatedly sending a deleted or invalid key can trigger an IP-wide temporary lockout.
The assumption to review: “All order-limit errors share the same remedy,” or “Every authentication error deserves another immediate attempt.” Those assumptions need separate evidence because one concerns in-flight capacity and the other concerns credential validity.
The fixture to design: a known retryable refusal, an invalid credential, a new unknown error value and an ambiguous response after submission. The unknown case should reach an explicit unresolved state with sufficient context for review. It must not be treated as successful merely because an error string was absent from an old allowlist.
6. Cancellation can stop remaining exposure without undoing committed execution
A cancellation request, its acknowledgment and the remaining financial exposure are three different observations. An agent that treats them as one event can release budget too early or report a position as absent while a fill is still possible.
For the selected Derivatives markets described in the current Maker Protection guide, a cancel that reaches a held order is answered at release. The order still reaches matching; cancellation applies to what would otherwise remain. The guide explicitly includes the user’s cancel-all and dead-man’s-switch paths in this behavior.
The assumption to review: “Sending the stop command guarantees no subsequent fill.” Document the relevant market, order state and effective version rather than applying one venue rule to every product.
The fixture to design: a held order, a cancel request, a partial fill and the canceled remainder. The expected result must reconcile executed quantity and residual quantity. Include a fully filled order whose cancellation returns not-found. This fixture does not require placing a live order; a documented or synthetic message sequence can expose a faulty client assumption before a separately authorized venue test.
7. An omitted account selector can change which balance you believe you inspected
Adding multi-account support creates a scope question even if the original endpoint remains available. A default account may be valid for an interactive user and wrong for a service that is meant to reconcile one strategy wallet. A successful balance or ledger query does not prove it covered the intended account.
The current Ledgers reference states that omitting account_id selects the authenticated user’s default wallet. It also separates ordinary asset filtering from explicit asset-and-class filtering.
The assumption to review: “My authenticated query covers the wallet and asset class that this workflow manages.” Make that scope part of the test expectation. Use a nonpersonal account alias in the export; retain any sensitive account mapping in the operator’s own controlled records.
The fixture to design: two wallet aliases with distinct ledger identifiers, one explicit selection and one default selection. Check that the reconciliation cannot label the default response as the requested wallet without a binding. The same principle applies to base versus displayed quantities: a value must retain its unit and representation, not just its numeric magnitude.
8. Additive status fields can improve observation without becoming an execution command
Not every API change is a breaking change. Some changes add useful context while preserving existing behavior. The review should record whether the application deliberately adopts that context, safely ignores it, or incorrectly gives it authority it does not have.
Kraken’s SystemStatus reference distinguishes the trading-engine status from scheduled-maintenance and emergency advisory arrays. The advisory fields are additive; they do not determine the top-level engine status.
The assumption to review: “No advisory means the system is safe for my next action,” or “An upcoming advisory means trading has already stopped.” Neither follows from the documented distinction.
The fixture to design: online status with a future advisory, restricted status without an advisory, and an empty advisory list. The client should apply its documented operating policy to the actual fields. Record the reviewer, the client build and the fixture result before changing that policy. DN’s instrument below checks whether those records are present and internally consistent; it does not connect to the exchange or approve deployment.
Methodology, limitations and corrections
DN selected documented examples that change an integration assumption, then separated the provider claim from a proposed client fixture. The method is deliberately different from comparing exchange fees or rate limits: it asks whether a particular deployed workflow still interprets a particular operation correctly.
| Link in the record | Evidence to retain | Question it resolves |
|---|---|---|
| Change to scope | Dated source and exact API family/operation | Does the announcement concern this workflow? |
| Scope to assumption | Written old expectation and dependency reason | What behavior could be wrong even with a valid response? |
| Assumption to fixture | Inputs, expected state and retained result | Was the relevant boundary actually checked? |
| Fixture to build | Exact tested and proposed build identifiers | Does the result apply to the code under review? |
| Record to decision | Responsible role and unresolved issues | Who must accept the remaining uncertainty? |
The instrument counts missing record items and contradictions; these are not a risk or compliance score. A reported pass with a different build remains unresolved. A claimed no-impact classification requires a reason. A reported failure remains open even if all references are filled in. Dates are compared as UTC calendar dates; an absent effective date stays null. The synthetic example uses 6 October to 14 November 2026, a difference of 39 calendar days, solely to demonstrate the date field.
References should point to the exact version or an operator-retained snapshot where permitted. A new changelog entry, client build or scope decision can invalidate an earlier record. Preserve the earlier record as history and create a new review; do not overwrite a past failure with an undated pass. The JSON export contains the entered assumptions, result and creation timestamp and is generated locally. It does not certify that the cited document or result exists.
Version 1.0.0, 14 November 2026: original change-impact instrument and synthetic validation fixtures. Source observations are dated 13 November 2026 UTC. No live migration or financial outcome has been measured.
For corrections, identify the claim, source and date when contacting Decentralised News. A new record-creation timestamp does not refresh its underlying evidence.
Change log: version 1.0.0, 2026-11-14. Initial documentation review, original instrument and labelled examples.
Frequently asked questions
Does HTTP success mean my integration is compatible?
No. It can establish that a request was accepted at the transport layer while fields, scope or state transitions are interpreted incorrectly by the client. Compatibility needs workflow-specific evidence.
Does this worksheet run regression tests?
No. It records a result supplied by the user and checks whether its reference and tested build are present. The synthetic examples demonstrate the worksheet logic, not exchange behavior.
Can a passed fixture be reused for a later build?
The record keeps a different build unresolved. A reviewer may establish an appropriate reuse policy with dependency evidence, but this tool does not infer equivalence between builds.
Why record a change that does not affect my workflow?
A scoped non-applicability reason prevents repeated investigation and makes the boundary reviewable. A bare no flag provides little evidence and can conceal a mistaken dependency assumption.
Is a cancellation acknowledgment proof that no trade occurred?
That depends on the specific product and order state. Reconcile executed and remaining quantities using the applicable current rules; a stop request does not automatically reverse already-committed execution.
Should I enter API keys or account numbers?
No. Use nonsecret build, fixture and workflow references. The instrument runs locally and needs no exchange credentials, private account data or personal names.
Primary sources
- Kraken Developers: release notes. Dated endpoint retirement and semantic-change examples; not evidence of a customer outage or loss. Reviewed 2026-11-13.
- Kraken Developers: Derivatives WebSocket. Legacy retirement date, Unified WebSocket message and authentication differences. Reviewed 2026-11-13.
- Kraken Developers: Get Tradable Asset Pairs. Current AssetPairs response representation, including empty fee arrays. Reviewed 2026-11-13.
- Kraken Developers: Get Trade Volume. Pair-specific fee queries and fee_schedule parameter. Reviewed 2026-11-13.
- Kraken Developers: Get Ledgers Info. Cursor pagination, null count, account selection and asset filtering. Reviewed 2026-11-13.
- Kraken Developers: Maker Protection. Current selected-market hold-cap errors and cancellation/committed-execution semantics. Reviewed 2026-11-13.
- Kraken Developers: error messages. Invalid-key retries and temporary lockout scope. Reviewed 2026-11-13.
- Kraken Developers: Get System Status. Advisory arrays are additive and distinct from trading-engine status. Reviewed 2026-11-13.
Turn the finding into a decision
If your integration team needs a scoped review, the DN Research Desk can discuss a change-impact brief based on public specifications and redacted workflow assumptions. Define the endpoints, evidence access and deliverable before commissioning work. This is a possible research engagement, not a promised certification, profitable strategy or completed service. No exchange affiliate link is needed to use this record.
Related DN research
Disclosure: Analysis and instrument results are editorial. Where labelled affiliate links appear, DN may receive compensation when you sign up or buy through them. Commercial relationships do not determine findings. No tested integration or guaranteed outcome is implied.
