For the complete documentation index, see llms.txt. This page is also available as Markdown.

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 area

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.

The API docs

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_....

Endpoint
Purpose

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:

Field
Meaning

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-Signature header, 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.ping event 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

  1. Create a test key.

  2. Call provision from your staging shop with a real idempotency key, and check the request history.

  3. Register a webhook endpoint and use Send test until it reports Active.

  4. Wire up update, renew, suspend, reactivate, cancel and auto-renew to your upgrade, renewal, refund, return and subscription flows.

  5. 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/v1 endpoints keep working for existing integrations. New integrations should use the API described here.


Next

Last updated

Was this helpful?