Changelog
Every change to the contract, newest first. It is one entry long, which is the honest state of a v1 published today — and a changelog started at the first release is one that stays complete.
What is safe to depend on
Knowing which half of a response is a promise is worth more than the changelog itself, because it decides what your code is allowed to branch on.
| Part of the contract | Promise |
|---|---|
error.code | Stable forever. |
| Adding an error code, a field or an endpoint | A compatible change. Your client must tolerate fields it does not recognise, and an unknown order status must be treated as terminal — which it is, if you follow poll_after_ms. |
| Changing or removing a code, a field or an endpoint | Not compatible. It appears here, with notice. |
error.message | Prose. May change without notice — never parse or match on it. |
| Enum values | New values may be added. Handle an unknown value by falling through rather than by throwing. |
| Prices | Move with the catalogue and with your tier. An accepted order is snapshotted and never re-priced. |
| Cursors | Opaque. Pass back next_cursor verbatim; never construct or parse one. |
Entries
2026-08-19The partner cabinet
- noteNOTHING ABOUT THE /partner/v1 CONTRACT CHANGED. No route was added, removed, renamed or re-shaped, no field moved, and no rate class was re-priced. An integration written against v1 needs no change, and this entry exists because the previous one told you there was no self-serve key management — which is no longer true, and a changelog that quietly leaves a superseded claim standing is worse than one with no entry at all.
- addedA cabinet for humans, at /partners/app. Members of a partner account sign in with an ordinary SimWay login — email, Google or Telegram — and can read the float, the statement with its running balance, the effective rate and the tier ladder, every order and every eSIM profile; mint, label, list and revoke their own API keys with an IP allowlist; open a deposit; refill the sandbox float; and correct their company details. It is a browser client on the consumer /api/v1 prefix behind a JWT, not a second way to authenticate against /partner/v1.
- addedTwo membership roles, fixed by the schema. An owner mints and revokes LIVE keys, opens deposits and edits the company record. A developer mints and revokes SANDBOX keys and reads the money, the orders and the profiles. Two things are owner-only: the live key list, which carries each credential’s label, last four characters and the address it was last used from, and the activation payload on a LIVE profile, because an activation code installs a profile once and is the article being sold. The sandbox returns a full payload to either role, so a developer can build the whole delivery path without it. Being added to an account is still done by a human at SimWay.
- noteThe cabinet CANNOT PLACE AN ORDER, deliberately and permanently. Ordering is what an API key is for: a key is chosen, scoped to one mode, pinnable to a CIDR range, revocable in one request and rate-limited on its own bucket, and a browser session is none of those things — so a cabinet that could buy would make a stolen tab a spending instrument. POST /partner/v1/orders also requires an Idempotency-Key because a retried purchase is a double charge, and a browser form has no client that knows to send one.
- noteKey issuance and revocation remain absent from the machine surface and will stay absent. A credential that could mint its own successor would survive its own revocation, which is the whole reason the primitives live behind a signed-in human instead.
2026-08-18v1 published
- addedThe sixteen endpoints of the v1 surface, at https://api.simway.pro/partner/v1 — account, deposits, catalogue, orders and eSIM profiles.
- addedSelf-serve deposits: POST /deposits mints a cryptocurrency invoice for a whole number of dollars from $100 to $10,000, GET /deposits is the funding history and GET /deposits/{id} resolves one. It answers 201 rather than the order endpoint’s 202 — an invoice is not a credit — and it deliberately takes no Idempotency-Key, because a repeated POST mints a second invoice and an unpaid invoice is not a charge. Bank transfer remains the rail for anything larger. Cards are absent by decision.
- noteThree deposit behaviours are counter-intuitive and are documented rather than left to be discovered: an overpayment is credited in full rather than capped at the invoice, an underpayment is credited at what actually arrived, and a refund issued after a deposit was credited does NOT take the float back automatically — it is reconciled by a person, and the float may already be spent.
- addedThis reference, generated from a typed description of the contract, together with /partners/llms.txt, /partners/llms-full.txt and /partners/openapi.json — all four from the same source.
- noteNo webhooks, no order cancellation, no card deposits, no live usage read and no self-serve key management. Each of those is absent rather than pending, and none should be planned around.