Changelog

​

2026-11-04 — Equipment tab: one Connection & device section

• The provider dashboard’s customer Equipment tab and an anonymous line’s page now show one Connection & device section: line state, router state, unit, building, speed, device, the customer’s own Wi-Fi network, and an Open device button. On the customer tab a Connection path button opens the path page; on an anonymous line’s page the path is its own card below. Check live status, Run service check and the Reboot button on the tab are gone; Reboot is on the device page.
• The Health badge reads Building outage, Line down or Device offline where they apply, and clears by itself once the line is back. The red outage banner appears only for a building-wide outage.
• The connection path shows Unit ONT, Building switch and Kurnl network without device names, ports or ids.
• Updated: Installs & equipment, Add a customer & subscription.
• No change to the partner API.

​

2026-11-03 — A changed billing e-mail notifies only the old address

• When the billing contact’s e-mail address changes — through PATCH /partner/subscriber/me/invoice-contact, POST …/invoice-contact/use-holder or the agent’s contact update with invoice — kurnl mails the address that stops receiving the invoices. The new address gets no mail.
• Corrected: Agent overview, Agent reference and Subscribers said both addresses were told.

​

2026-11-02 — Operator discount codes on your own checkout

• The session carries operator_offers: every kurnl operator discount the shopper may use on the session’s building, with the code, headline, duration and the monthly price it gives on the plan.
• discount_code on the session form of /external-checkout/complete and /external-checkout/anonymous-complete is now honoured, checked as of the hand-over day: a kurnl operator code from the session’s operator_offers or one of your own discount codes. Anything else answers 400 Invalid or expired discount code and creates nothing; on a bulk plan a code answers 422 bulk_discount. The session’s own code sent back counts as no code.
• kurnl’s own marketplace no longer takes a code for a checkout you host.

​

2026-11-02 — install.booked can say booked_by: "provider"

• A provider’s staff can now book, move or cancel a third-line technician visit for their customer in the dashboard. A booking or a move made there fires install.booked with booked_by: "provider"; the customer’s own booking keeps customer, kurnl staff keep staff.
• install_path provider_visit on the session status is described as “a visit kurnl schedules” (it always was kurnl’s); the value itself is unchanged.

​

2026-10-29 — Communication preferences: one channel per topic

• GET and PATCH /partner/subscriber/me/preferences carry five channel keys — billing_channel, security_channel, outages_channel, support_channel, marketing_channel — with the values email, sms, both or off as each topic allows, plus updated_at, sms_available and has_phone. The booleans marketing_email, outage_notifications and sms_transactional are now derived from the channels; a PATCH still accepts them.
• A PATCH that adds texts — sms or both on a topic that had none, or the legacy sms_transactional: true — answers 409 no_phone when the person has no phone number on file, next to the existing 409 sms_not_available. A channel word a topic does not offer (for example marketing_channel: "sms") answers 422.
• Texts: the billing, outage and ticket events with an active SMS template now text customers who chose sms or both; a customer who chose sms for billing, outages or support is no longer e-mailed for that topic.

​

2026-10-28 — A refused password answers 400

• When the sign-in service refuses the subscriber.password of a new account, POST /partner/provisioning/provider-initiated and POST /partner/external-checkout/complete answer 400 with its reason as detail, for example "Password should be at least 6 characters.". Nothing was created; a session can be completed again with another password. Before, they answered 500 "Provisioning failed". A password under 8 characters is still refused with 422 by the request model first.
• POST /partner/provisioning/bulk reports the same reason as the failed item’s error, where it said Provisioning failed before.
• External checkout complete now shows the 8-character minimum of subscriber.password, which the request model always had.

​

2026-10-27 — An erased customer is not found

• A customer whose personal data the provider erased on their PIPEDA deletion request is no longer found by the agent API: GET /partner/agent/customers/search leaves them out, and every /partner/agent/customers/{id} route answers 404 not_found, as for a customer that is not the provider’s. Before, an erased customer was still found, with its contact fields empty.

​

2026-10-27 — One change to a line at a time: 409 action_in_progress

• A change to a subscription now runs for one request at a time per line. A second request for the same line while the first is still running answers 409 {"detail": {"code": "action_in_progress", "message": "…"}} and changes nothing. Before, two concurrent requests could both run, and a double cancel could issue a second final invoice and credit note. Affected: POST /partner/subscriber/me/subscriptions/{id}/cancel, POST /partner/subscriptions/{id}/change-plan, the suspend, restore and cancel actions of POST /partner/external-checkout/subscription-status, POST /partner/agent/customers/{id}/plan-change, and the internal /api/v1/subscription/{id}/cancel.
• A cancel that arrives after another one finished answers 409 already_cancelled.
• POST /partner/agent/customers/{id}/plan-change refuses a second change the same day with detail as an object, {"code": "change_limit_reached", "message": "…"}; before, detail was the sentence alone. POST /partner/subscriptions/{id}/change-plan keeps its sentence.
• The read-then-act race the plan-change page described is closed.

​

2026-10-27 — Operator discounts: discount_code on partner creates, wholesale discount rows

• Kurnl can now run its own operator discounts on chosen buildings, with a code, a start and an end date per building. Kurnl pays: the customer’s price and the wholesale price drop by the same amount for the promo months, so the provider’s margin is unchanged. A provider can opt out of them in the dashboard (Billing → Discounts → Operator discounts). If the plan’s own campaign is cheaper, the campaign stays (compared on the monthly promo price only; a tie keeps the campaign).
• POST /checkout/validate-discount-code takes optional building_id / location_identifier and answers source (provider | operator), label, promo_price_monthly, list_price_monthly, duration_months, setup_fee, applied and reason (campaign_better, or unavailable when the check could not run, a temporary read failure). A bulk plan answers valid: false. An operator code can now be “expired”.
• POST /partner/external-checkout/sessions takes discount_code (400 Invalid or expired discount code on a miss, before the session exists); the hosted URL gains &discount_code=. GET /partner/external-checkout/sessions/{id} returns discount_code and operator_discount (code, name, discount_type, discount_value, duration_months, list_price_monthly, promo_price_monthly; 503 if it cannot be read). The public session status returns discount_code and operator_discount_name. At completion kurnl applies its side (the wholesale reduction); the partner passes the discount on to the customer. A code that was valid at the hand-over is honoured at completion; an archived code lapses and the order goes through at campaign or list terms.
• complete and anonymous-complete take discount_code only in their explicit-fields (sessionless) form; with a session_id the session’s stored code is used and the body’s is ignored. POST /provisioning/provider-initiated and POST /provisioning/bulk accept discount_code. A miss is a 400 (per item in a bulk batch).
• The billing CSVs (GET /partner/reports/billing, the dashboard’s Wholesale Billing CSV) carry an extra row per subscription and month with Fee Type = Operator discount, the label in Wholesale Product Name, and negative Total Cost and Wholesale price monthly. Fee Type is no longer always Monthly.
• A plan change carries an operator discount over to the new plan; a provider’s campaign still ends.

​

2026-10-26 — Anonymous lines: what is live in production

• Webhooks: subscription.activated fires on every activation path, install.booked tells you about booked or moved visits, and every event carries external_subscription_id and is_anonymous. An optional Backup notification e-mail (dashboard, Checkout page) gets each event by mail as well.
• Cancel: POST /partner/external-checkout/subscription-status with action: "cancel" and an optional end_date.
• Mails to your customers: kurnl sends service mails (outage, restored, router shipped, ticket received, visit booking) to the contact_email you send; lifecycle mails only where the provider switched them on; never billing or account mails.
• Plan change to another provider’s plan: refused with 403 and a message that says to cancel the line and order a new one.
• Wi-Fi set-up link: live in production since 2026-10-27; see Wi-Fi set-up for anonymous lines below.

​

2026-10-26 — Plan change to another provider on an anonymous line

• A plan change that targets another provider’s plan on an anonymous line (no customer record) is refused with 403 and the message This line has no customer record and cannot switch provider. Cancel it; the new provider orders a new line. Before, the message was the general one about change-provider.
• Providers get a full page for anonymous lines in the dashboard: health, equipment, connection path, visits and tickets. No API change.

​

2026-10-26 — first_charge is the invoice’s gross, tax included, before credits

• The reactivation preview (GET /partner/subscriber/me/subscriptions/{id}/reactivation) quoted billing.first_charge net of tax, and on the activate path as the setup fee plus a whole month, while the action bills the setup fee plus the partial month from today, with tax. first_charge is now the gross of the invoice the action creates today — the same lines, tax and discount, before any credit on the account — and null when it cannot be computed right now.
• The reactivation answer’s first_charge (path: "remote") is the true-up invoice’s gross as well, no longer the net; the reactivated e-mail states the same figure, also after a technician visit.
• The order preview (GET /partner/subscriber/me/orders/preview) quotes the first invoice’s gross on the provision route: the setup fee plus the partial month from today, tax included, before credits — no longer the setup fee plus a whole month.
• billing.has_payment_method reads the customer’s default card in the provider’s Stripe account (the card every charge uses), no longer a stored column.

​

2026-10-26 — Wi-Fi set-up for anonymous lines

• kurnl now mails the household of an anonymous line a link to set up its Wi-Fi, once per line, to the contact_email you sent. It goes out when the router first makes contact, or when the line goes live.
• New: POST /partner/subscriptions/{id}/wifi-link sends a new link (works once, 7 days, at most 5 per line in 24 hours). PUT /partner/subscriptions/{id}/wifi sets the network name and password yourself. Both need the provisioning:write scope on X-API-Key, and accept ?by=external_subscription_id.
• Errors: 404 for a line that is not yours, 409 with named_line, no_contact_email, no_portal or the reason the line cannot carry Wi-Fi, 422 invalid_wifi, 429 wifi_link_limit. Passwords are never returned.

​

2026-10-26 — Campaign discounts are billed; plan lists carry promo; discount codes work on every marketplace order

• A plan’s campaign discount was shown to the customer but never billed. A line created with one is now billed at the promotional price from activation, for the duration’s full calendar months (the first, partial month is at the promotional price too), then at the plan’s price. A plan change ends the promotion; a cancelled line keeps it until it is reactivated, which ends it. The invoice’s plan line names the campaign, for example Spring 20 % promotion · regular price $80.00/mo.
• Plan versions from GET /partner/marketplace/plans/me and GET /partner/marketplace/plans/{id} carry promo: price_monthly (null for a campaign that only overrides the setup fee), list_price_monthly, label, campaign_name, duration_months (null = for as long as the line runs) and setup_fee (only when overridden); null without a promotion. GET /partner/plans/versions, the plan-change list and the plans of POST /serviceability/check carry no promotion (promo is null or absent) — read it from the marketplace plan reads — a plan change ends the promotion and charges the new plan’s regular price. The customer portal’s GET /partner/subscriber/me/orders/options carries promo for its plans too. The order preview (GET /partner/subscriber/me/orders/preview) gains plan.promo_setup_fee and plan.promo_ends_after_months.
• Partner provisioning creates apply the plan version’s campaign (never a code). The discount code, which replaces the campaign, now works on all three marketplace order kinds: POST /partner/checkout/home-drop-checkout and /unit-checkout gained the optional discount_code that /create-subscription-checkout already took.
• The discount types are PERCENTAGE, FIXED_MONTHLY and OVERWRITE_MONTHLY; any other value is refused with 422. The docs showed "percentage" in the discount-code check; the value is PERCENTAGE.

​

2026-10-26 — Anonymous lines receive kurnl service mails

• For an anonymous line, kurnl now sends service mails to the contact_email you send: outage, service restored, router shipped and ticket received, together with the visit booking mails.
• Where the provider switched a template on for anonymous lines, lifecycle mails (welcome, plan changed, cancellation, service deactivated, visit completed) go there too. Billing and account mails are never sent to an anonymous line.
• The greeting uses the name from the installation booking, or “Hello,” when there is none.

​

2026-10-26 — Anonymous lines: activation and visit events, partner cancel, backup e-mail

• New webhook install.booked: a technician visit was booked or moved. Fields: appointment_start, appointment_end (ISO 8601 with offset), booked_by (customer or staff), rebooked.
• subscription.activated now fires whenever a line goes live, including the home-drop, confirm-install and pre-order paths, which sent nothing before. It carries kind (first or reactivated), activated_at and plan_version_id. A line kurnl brings back sends it again with kind: "reactivated"; a restore you request through the status call does not.
• Every webhook event now also carries external_subscription_id and is_anonymous.
• POST /partner/external-checkout/subscription-status accepts action: "cancel" with an optional end_date (YYYY-MM-DD, the first day without service; default today) and reason. The response gains ended_at. A past date answers 422; a line already cancelled answers 409 with detail.code = "already_cancelled" (an object, unlike the other 409s on this route).
• New dashboard setting Backup notification e-mail (Checkout page): for anonymous lines kurnl mails every partner event to this address as well, with a switch to turn it off.

​

2026-10-23 — Retries of a provisioned order answer the replay again; a second line provisions; an occupied port is refused

• A retry of an order that was already provisioned answered 400 “Subscriber already has an active subscription. Only one subscription per subscriber is allowed.” instead of the documented replay. It now answers 200 with the existing subscription and "Subscription already exists (idempotent replay)" (or "Provisioning already in progress"), as documented. This covers POST /partner/provisioning/provider-initiated, every POST /partner/provisioning/bulk item and POST /partner/external-checkout/complete.
• A customer who already has a line (with you or with another provider) gets a second line at another location; the same check refused it with that 400.
• A port that already carries another live order — another subscriber’s, or another plan version of the same subscriber — is refused with 409 {"detail": {"code": "port_in_use", "message": "This port already has a live subscription."}}, and a bulk item fails with error_code: "port_in_use". Before, nothing checked the port and a second line was created on it. When the port cannot be read, the order answers 503 Could not check whether the port is free; try again. Nothing is created in either case. A retry of an order whose line is in PAYMENT_FAILED answers port_in_use too, not the replay.

​

2026-10-23 — Providers choose plans per region and building; orders for a plan the building does not offer are refused

• Every order path refuses a plan the building does not offer with 422 {"detail": {"code": "plan_not_offered", "message": "<Plan> is not offered in this building.", "building_id": "…"}}: POST /partner/checkout/home-drop-checkout, /unit-checkout and /create-subscription-checkout, external-checkout completion (CKO-03, named and anonymous) and provider-initiated provisioning (CKO-04). When the offer cannot be read, they answer 503 Could not verify the building's plan offer; try again. and create nothing. Sandbox keys are not checked.
• GET /partner/marketplace/plans/me lists only plans you offer in at least one region or building. A plan with no plan selection anywhere is not listed until you offer it. Bulk and external plan versions are listed as before, and sandbox keys are not narrowed.
• POST /serviceability/check lists your provider at a normal building only when it has a plan selection there or offers an external plan, and plans holds only the live plans it offers at that building. A normal building you cover but have no plans for is no longer serviceable; Bulk Deal buildings stay listed with their fixed plans.
• A plan change (POST /partner/subscriptions/{id}/change-plan) is unaffected while no plan selection exists for the building: every plan of yours stays allowed. Once a selection exists, it binds: a plan left out is a 422 plan_not_offered and is missing from eligible_plan_versions.
• On the first rollout, every plan you had was offered in every region you covered, so no building lost its listing.

​

2026-10-23 — One reactivation at a time, an unconfirmed payment says so, and paying a failed invoice is documented

• POST /partner/subscriber/me/subscriptions/{id}/reactivation answers 409 reactivation_in_progress while another request brings the same line back (a double submit, or the provider’s dashboard at the same time). Nothing is done; try again in a few minutes.
• A charge Stripe did not confirm answers 409 payment_unconfirmed — on the activate path and on POST /partner/subscriber/me/invoices/{id}/pay — instead of a failure (402) or a server error. The invoice stays open and the provider checks the payment.
• POST /partner/subscriber/me/invoices/{id}/pay is documented now, with its refusals.
• On the activate path the first invoice covers today to the end of the month; before, it was dated from the day the cancelled order was placed.
• The reactivation refusal list names every code the route returns (card_declined, no_payment_method, payment_unconfirmed, activation_incomplete, reactivation_incomplete, reactivation_in_progress, path_changed).

​

2026-10-21 — Every order path checks the building: coverage, speed tier and bulk offer

• POST /partner/checkout/home-drop-checkout and /unit-checkout now refuse with 422 speed_tier, bulk_plan and not_covered. They checked none of the three; the 2026-10-16 entry’s “every order path refuses a mismatch” was not true for these two.
• POST /partner/checkout/create-subscription-checkout checks coverage whenever the location resolves to a building, also without an invoice postal code. Its coverage refusal is now an object, {"detail": {"code": "not_covered", "message": "This building is not covered by <provider>. …", "building_id": "…"}}, instead of a plain string; an address with no building keeps the postal-code sentence, as {"detail": {"code": "not_covered", "message": "Postal code … is not in the service area for this provider. …"}}.
• External-checkout completion (CKO-03, named and anonymous) and provider-initiated provisioning (CKO-04) add 422 not_covered. When the line’s building cannot be read, they answer 503 Could not read the line's building; try again. instead of skipping the check.
• GET /partner/subscriptions/{id}/change-plan/preview lists only plans within the building’s speed tier.
• A plan change (POST /partner/subscriptions/{id}/change-plan) never asks about coverage: a customer keeps changing plan in a building your provider no longer covers.
• When coverage cannot be read on a write, the API answers 503 Could not verify the building's coverage; try again. Nothing is created.

​

2026-10-21 — A line cancelled before its install keeps its port and sends no deactivation e-mail

​

2026-10-19 — Agent tickets: the create names the state, the list’s priority is bare

​

2026-10-19 — Audit log: provider admins only

​

2026-10-17 — First-line orders start on the move-in date

• When requested_start_date is ahead of the provider’s today, or the building is not orderable yet, the returned checkout_url is a Stripe setup-mode session (card saved, nothing charged) instead of a payment session. payment_required stays true.
• invoice_ninja_invoice_id and first_invoice_total are now nullable: they are null for a waiting order, because no invoice exists yet.
• New optional response field starts_on (ISO date): present when the order waits for its move-in day (or for the building’s go-live day); absent or null when the line starts at checkout.

​

2026-10-16 — Bulk buildings: plans included in the rent

• GET /partner/serviceability/check gains "bulk": true|false next to presale, and each object in plans gains "is_bulk": true|false. In a bulk building plans holds only your bulk plan versions, at "retail_price_monthly": 0.0.
• Every plan version the partner API returns gains "is_bulk": boolean. Bulk versions are not in GET /partner/marketplace/plans/me, which has no building context.
• Every order and plan-change path (session create and patch excepted; the refusal comes at completion) refuses a mismatch with 422 {"detail": {"code": "bulk_plan", "message": "…", "building_bulk": true|false, "plan_bulk": true|false}}: a paid plan in a bulk building, or a bulk plan anywhere else.
• When the building’s bulk configuration cannot be read on a write, the API answers 503 Could not verify the building's bulk offer; try again.
• GET /partner/reports/billing (the wholesale billing CSV) no longer lists bulk lines — they are billed to the building owner, not to you.

​

2026-10-16 — Cancel preview: payment-failed lines and the open balance

​

2026-10-16 — Usage months follow the provider’s time zone

​

2026-10-16 — Usage and the connection timeline per line; every running line in the order options

• GET /partner/subscriber/me/usage and GET /partner/subscriber/status-history take an optional subscription_id. Without it, usage reads the primary line and the timeline lists every line’s events, as before. An id that is not one of the caller’s own subscriptions answers 404 Subscription not found.
• Usage now stops where the line does: a line that has ended or been switched off lists no months after the earlier of its ended_at and deprovisioned_at, and its last month counts only up to that moment. Before, the current month was always read up to now.
• Each event in status-history carries subscription_id (null on older events). With ?subscription_id= the timeline holds that line’s events only.
• GET /partner/subscriber/me/orders/options gains running_lines, every running line a mover may end (ACTIVE first, then the newest start, then by id). current_subscription stays and is its first entry. end_current_subscription_id on the preview and the order accepts any of them.

​

2026-10-15 — Plan versions no longer carry a term or a cancellation charge

​

2026-10-14 — Plan audience: plans for new or existing customers

• Every public plan response carries target_audience: ALL, NEW_SUBSCRIBERS or EXISTING_SUBSCRIBERS (plans).
• GET /partner/marketplace/plans/me, the storefront lists and the serviceability plans return only versions offered to new customers. The plan-change preview’s eligible_plan_versions returns only versions offered to existing customers.
• POST /partner/subscriptions/{subscription_id}/change-plan now refuses a plan version outside its effective window with 400 Plan version not active, and a version for new customers only with 422 plan_audience (plan change). eligible_plan_versions is now what the POST accepts, apart from the building’s speed tier.
• Ordering a plan for existing customers only — provider-initiated, bulk, and the CKO-03 callbacks — answers 422 with {"detail": {"code": "plan_audience", "message": "…", "target_audience": "EXISTING_SUBSCRIBERS"}} before anything is created.
• A plan change booked for a later day is refused when the booking is made if the version is not on sale today. The hourly pass checks again on the day and cancels the change when the version has left its window or its audience no longer fits.

​

2026-10-15 — The return-page status says how the order gets connected

​

2026-10-15 — Bulk provisioning takes first-line buildings only; reactivation comes back remotely when the router is online

• Bulk provisioning POST /partner/provisioning/bulk: an item whose port is not in a first-line building (second or third line, an unclassified building, or a switch with no building) now fails with status: "error" and error_code: "install_required"; nothing is created for it and the rest of the batch runs. Order those suites one by one with CKO-04 and a unit_id. Each item result, in the POST response and in the poll GET /partner/provisioning/bulk/{batch_id}, gains an optional error_code (also speed_tier where that refusal applies).
• Reactivation and resume of a line in a second- or third-line suite whose router is online (it answered within the last 15 minutes, single connection) no longer book a visit. A cancelled-and-ended line comes back remotely (path: "remote") and charges the rest of the period at once; a never-installed order activates at once (path: "activate") and is billed as a first order. A suite whose router is not online still takes path: "technician". GET /partner/subscriber/me/reactivation reports the new path.
• POST /partner/subscriber/me/subscriptions/{id}/reactivation takes an optional body {"expected_path": "remote" | "technician" | "activate" | "none"} (the preview’s path; a withdrawal is none). When the path now differs it answers 409 path_changed and writes nothing; any other value answers 422. Without a body nothing changes.
• Operator-created lines on such a suite get an install job with no booking and no shipment; the operator confirms it in the dashboard. This does not change the partner API.

​

2026-10-15 — A suite whose router is already online is provisioned on every path

• CKO-03 POST /partner/external-checkout/complete, with and without a session: such a suite answers 200 with a job_id, as on a first-line building.
• CKO-04 POST /partner/provisioning/provider-initiated: such a suite answers route: "provision".
• GET /partner/serviceability/units gains cpe_ready per suite: true when the suite’s router is already online, always false for a suite with several connections. It is a snapshot; the order decides again when it arrives.
• CKO-03 anonymous POST /partner/external-checkout/anonymous-complete now routes by the building, like every other path, instead of by the delivery_mode of the session or of your payload:
  • a direct order (a port, no suite) on a building that is not first line answers 422 (Building line type '…' requires an operator install job, but the session has no unit_id — refusing to provision.). A port whose switch belongs to no building counts as unclassified and is refused the same way;
  • a home_drop order on a first-line suite is provisioned at once and answers delivery_mode: "direct", subscription_status: "ACTIVE" instead of becoming an install. A first-line suite with several connections keeps its held install;
  • delivery_mode in the response reports the path taken (direct = provisioned, home_drop = install job).
• Customer portal orders: GET /partner/subscriber/me/orders/options gives each unit cpe_ready and route; the building’s route stays the default for a suite whose router is not online. POST /partner/subscriber/me/orders takes an optional route (the preview’s) and answers 409 route_changed when the suite’s route changed since the preview; nothing is written.

​

2026-10-15 — Anonymous orders that need a visit require contact_email

• The answer is 422 before anything is written (no subscription, no install job, no ticket): {"detail": {"code": "contact_email_required", "message": "This order needs a technician visit or a shipped router. Send contact_email so the household gets the booking link."}}.
• It applies to both the session and the no-session payload. A retry of an order that already exists still answers its idempotent replay, with or without contact_email.
• First-line orders, and second- or third-line suites whose router is already online, need no e-mail; it stays optional there.

​

2026-10-15 — Cancelling for today switches the line off at once

• POST /api/v1/subscription/{id}/cancel with requested_end_date set to today (in the provider’s time zone) resets the port, resets the CPE’s Wi-Fi handover and sends the customer’s e-mail within seconds of the call. The call does not wait for the switch. The subscription.cancelled webhook still comes first, then subscription.deprovisioned. If the reset fails, the hourly pass retries it. A later date is unchanged: the line runs through its last day and is switched off when that day ends. A line that was never live (PENDING, PENDING_INSTALL) cancelled for today is also switched off at once.
• The cancel response (and the customer portal’s) gains last_service_day (YYYY-MM-DD, the last day of service in the provider’s time zone) and ended_immediately (true when the cancel was for today; last_service_day is then the day of the call). GET /partner/subscriber/me subscriptions carry both too, plus deprovisioned_at (null until the port is switched off); the reactivation read’s cancellation carries both.
• A customer may now cancel for today in the portal (POST /partner/subscriber/me/subscriptions/{id}/cancel).
• Portal orders: POST /partner/subscriber/me/orders and its preview take end_current_on, required with end_current_subscription_id: the day the running line ends, earliest today in its provider’s time zone. It replaces the move-in date as the old line’s end date. Missing or past, the order answers 422 and creates nothing. ends_current and ended_subscription carry last_service_day and ends_immediately / ended_immediately.
• The cancellation e-mail names the last day of service (or says the service ended when you cancelled) instead of the exclusive end date.

​

2026-10-14 — Checkout orders never reuse an existing account

• An e-mail that already has an account answers 409 before anything is written: {"detail": {"code": "account_exists", "message": "This e-mail already has an account. Sign in to your provider's portal to order another line."}}. An existing customer orders another line in their portal. The answer says nothing about the account’s lines.
• Each successful response carries a new field status_token (in subscription_details on create-subscription-checkout, at the top level on the other two). The kurnl marketplace uses it for its order progress page; an integration can ignore it.
• The three routes are limited to 30 requests / minute per client IP and answer 429 above it.
• The consent and contract records take the address the request came from; a client_ip in the body is ignored.

​

2026-10-13 — Public checkout helpers, location lookup and notice feed tightened

• POST /partner/checkout/validate-discount-code accepts only a code of the provider whose plan_version_id you send. Another provider’s code now answers valid: false with the same error as an unknown code.
• POST /partner/checkout/check-email still answers is_taken; its message no longer repeats the address ("Email is available" / "Email is already registered").
• The three checkout helpers and POST /partner/location/ are limited to 60 requests / minute each (per API key with X-API-Key, otherwise per client IP) and answer 429 above it.
• POST /partner/location/ returns only the listed address fields; the address record’s own id and its free-text description are gone.
• GET /partner/status/notices no longer returns service_notice_buildings / service_notice_areas. Without service_provider_id it returns only the network-wide notices, not every provider’s. A query parameter that is not a UUID answers 422.

​

2026-10-13 — Only leads with marketing consent receive the provider’s campaigns

​

2026-10-12 — The anonymous CKO-03 callback refuses plans the building cannot deliver

​

2026-10-07 — Plans a building cannot deliver are no longer offered

​

2026-09-29 — Customer numbers are digits only

​

2026-09-22 — A CKO-04 order can hand the billing to kurnl

​

2026-09-17 — Partners can change a subscription’s plan directly

​

2026-09-17 — A first-line building can be ordered by suite

422 First-line building requires a resolvable port (location_hash);
    a unit-only session is invalid for first-line checkout.

422 First-line building requires a resolvable port (location_hash) or a unit;
    the session carries neither.

​

2026-09-16 — Customers book their own installation

​

2026-09-15 — Per-provider Stripe connection

​

2026-09-05 — Calendar-month billing

​

2026-08-25 — External checkout starts on the marketplace (correction)

​

2026-08-17 — Documentation re-verified against the code

​

2026-08-13 — No WordPress plugin; integrate against the API