Shop API: Provision NTRIP Licenses from Your Shop
Provision RTKdata NTRIP licenses straight from your own shop: API keys, test and live mode, idempotent provision, update, renew, suspend, reactivate, cancel and auto renew calls, signed webhooks and a
The Shop API lets your own storefront provision licenses without anyone opening the portal. A customer checks out in your shop, your backend calls the API, and the NTRIP credentials come back in the response while the order confirmation is still on screen.

The Shop API is optional and has to be enabled for your account by RTKdata. Until then, the API area in your sidebar says so. Ask support@rtkdata.com if you want it switched on.
The API area
API is your control room: the Active Keys, Calls, Error Rate and Webhook Endpoints tiles, a setup checklist, your keys and webhooks, charts of your API traffic, and the request history. API > Docs is the full reference, with a copyable curl example for every endpoint.

API keys
Keys lists the keys issued to your account. Each one is either Test or Live, and only a short preview is shown after creation, with when it was last used.
New key creates one. Copy it at that moment, it is not shown again in full.
Revoke kills a key immediately. Revoked keys are hidden behind Show revoked keys, so their history in the request log stays readable.
A test key (rtk_test_...) runs in a sandbox: no real license, customer, caster account or bill line is created, and it only sees test licenses. Build against a test key, and switch to a live key (rtk_live_...) only when the flow works end to end.
The endpoints
The base URL is https://reseller.rtkdata.com/v1. Every call takes your key as a bearer token: Authorization: Bearer rtk_test_....
POST /provision
Creates a license (or a trial) for a customer and returns their credentials
GET /licenses/{id}
Reads a license as it is now, including its credentials
POST /licenses/{id}/update
Adds data streams or lengthens the term of a paid license. Values can only go up. On a trial, converts it to a paid license
POST /licenses/{id}/renew
Renews a paid license for one more term of its current length, for example when the customer pays for another month
POST /licenses/{id}/suspend
Stops the credentials working, for example on a chargeback. Also switches auto renew off
POST /licenses/{id}/reactivate
Resumes a suspended license. Auto renew comes back if it was on before and the term has not run out
POST /licenses/{id}/cancel
Stops the license from renewing by switching auto renew off. It keeps working until its end date, then expires. To cut access immediately, suspend it
POST /licenses/{id}/auto-renew
Switches auto renew on: at its end date the license renews for another term of the same length. Only for a running paid license
Provisioning looks like this:
customerName, customerEmail
At least one is required. The customer is found by email, then by customerReference, then (only if you sent neither) by name, and created if none matches
customerReference
Optional. Your shop's own customer id, not the order number
product
ntrip_license (paid) or ntrip_demo (trial)
seats
Data streams, 1 to 999, default 1
term, termAmount
term is monthly or annual, termAmount how many of it: 1 to 11 months, or 1 to 5 years. termAmount defaults to 1, and a license ordered without a term runs one year
termMonths
The older way to send the term (1 to 11, or 12, 24, 36, 48 or 60). Still accepted in place of term and termAmount, but not together with them
trialDurationDays
For a trial: 7, 14 or 30, default 30. A trial always has one data stream, and each customer gets one trial, ever. seats and the term are ignored for a trial
A paid license starts with auto renew off. Switch it on with POST /licenses/{id}/auto-renew.
The response carries the license and its credentials (host, username, password, the default mountpoint and every mountpoint the login works on). Credentials are read live from the caster; if they cannot be read at that moment they come back as null, and a GET /licenses/{id} a little later returns them.
Every answer names the term both ways, as term and termAmount and as termMonths. A trial has no term: its answer carries trialDurationDays, and the three term fields are null. A paid license answers the other way round, with its term and trialDurationDays as null.
The API does not email your customer. Deliver the credentials in your own order confirmation, or send them a customer portal login link from the Reseller Hub.
A lifecycle change looks like this:
Update takes seats, a term (term and termAmount, as in provisioning) or both. On a paid license both can only go up: more streams, or a longer term. Extra streams are billed pro rata for the paid time left, a longer term starts when the current one ends, and both appear on your next monthly bill. On a trial, one update converts it to a paid license: send both seats and the term the customer bought. The login stays the same and the paid term starts now. An update with only seats or only a term on a trial returns 400.
Renew takes no body and adds one more term of the license's current length: a monthly license moves one month on, a two year license two years. Renewed before the end date, the new term starts there and no paid time is lost; renewed after the license ran out, it starts now. Only a paid license that is active or has run out can be renewed: convert a trial with update, and reactivate a suspended license first. Each Idempotency-Key renews once, so use a new key for each renewal.
The Docs page lists the error responses (400, 401, 403, 404, 409 and 5xx) and what each one means.
Idempotency
Every call that changes something requires an Idempotency-Key header (up to 200 characters). Use something stable from your own system, your order number is ideal. Keys are yours alone: another account using the same key does not affect you.
Sending the same request with the same key again returns the license as it is now instead of doing it twice. That matters more than it sounds: a timeout on your side, a shopper double clicking checkout, or a retry in your queue would otherwise each cost a license and a line on your bill.
A key belongs to one request. Reusing it with a different body, action or license returns 409, and so does a retry while the first request is still running. Use a new key for each new request. After a 5xx error, retry with the same key: a request that already went through is never repeated.
A 409 can also mean the customer already had a trial, or that your account does not allow new licenses right now, for example while a bill is overdue. The response body says which.
Webhooks
Webhooks registers the endpoints in your shop that should hear about license events: license.activated, license.updated, license.suspended, license.reactivated, license.cancelled, license.renewed, license.expiring and license.expired.
Add endpoint registers a URL and shows its signing secret once. Every delivery carries an
RTK-Signatureheader, an HMAC over the payload with that secret, so your handler can verify it came from RTKdata.Each endpoint shows Active or Failing, based on its most recent delivery or test.
Send test fires a
webhook.pingevent so you can verify your handler without a real order.The row also has the delivery log, Roll secret and remove.
An endpoint stuck on Failing means your handler is not returning a success response. Fix it there, then send a test to confirm.
Request history
Every call your keys make is logged with its time, endpoint, key, environment, status, latency and idempotency key. Search by key or idempotency key, and filter by environment, status (2xx, 4xx, 5xx) or endpoint.
This is where you look when a customer says their credentials never arrived. The log tells you whether the call reached us at all, which key it used, and what it returned.
Suggested integration order
Create a test key.
Call
provisionfrom your staging shop with a real idempotency key, and check the request history.Register a webhook endpoint and use Send test until it reports Active.
Wire up
update,renew,suspend,reactivate,cancelandauto-renewto your upgrade, renewal, refund, return and subscription flows.Create a live key, switch your production shop over, and revoke anything you no longer use.
Coming from the previous RTKdata reseller portal? Its
/api/v1endpoints keep working for existing integrations. New integrations should use the API described here.
Next
Licenses & Provisioning - the same lifecycle, done by hand
Customer Portal - where an API provisioned customer reads their credentials
Last updated
Was this helpful?