Backwards compatibility

This page is deliberately narrow. A compatibility policy is a public promise, and a promise the platform does not keep costs an integrator more than no promise at all. What follows is what the API actually supports today.

What is stable

operationId is a public contract. Every operation carries a stable operationId (createWallet, listWithdrawals, rotateWebhookSecret), and those become the method names in the generated SDKs. Renaming one is a major SDK version, not a routine change.

The /v2 prefix is the version. A change that cannot be made additively belongs behind a new prefix, not inside this one.

The signing recipe is stable. It changed once, before the API had any consumers; it is not something that moves now.

What may change without notice, and how to survive it

Changes are made additively: new fields on a response, new values in an enum, new endpoints, new webhook event types.

So your client must ignore fields it does not recognise, and must not crash on an enum value it has never seen. This is the one thing the platform asks of you, and it is what makes additive evolution possible. If your JSON parser is strict by default, loosen it for CowriePay responses. If you switch on an enum, have a default branch.

Note what that sentence is and is not: it is guidance to clients, not a guarantee that no field will ever be withdrawn. It is stated as advice on purpose.

What is NOT promised yet

Being explicit about the gaps is the point of the page:

• There is no formal deprecation window. There is no published notice period, no Sunset header, and no dated API version you can pin to.
• There is no guarantee that a field is never removed. The published surface has narrowed before: scope values and webhook event types have been withdrawn from the published spec when the feature behind them was not available. A client that had hard-coded them would have had to change.
• Enum values are not closed sets. Treat every enum as open.

If you need a stronger commitment than this for a procurement or a contract, ask: it is a commercial conversation, not a technical one, and it is better had explicitly than inferred from a documentation page.