> For the complete documentation index, see [llms.txt](https://docs.rtkdata.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rtkdata.com/reseller-hub/api.md). # Reseller API: Provision NTRIP Licenses from Your Shop Provision RTKdata NTRIP licenses from your own shop: the API area, keys, webhooks, the request log, and which API version fits your integration. The **API** lets your own storefront or back office do what you would otherwise do in the portal. A customer checks out in your shop, your backend calls the API, and the NTRIP credentials are ready while the order confirmation is still on screen. Deeper integrations go further: they follow every license, read bills and connections, and react to events as they happen. ![The API area](https://3957820804-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJflLSSoC9TU9MkwT5lbC%2Fuploads%2Fgit-blob-3d8f2546a9afa4116572f5d190a0bbcebcab7071%2Freseller-hub-shop-api.png?alt=media) > The API is optional and has to be enabled for your account by RTKdata. Until then, the **API** area in your sidebar says so. Ask if you want it switched on. *** ## Two versions, pick one The API comes in two versions. Both use the same keys, the same test and live environments, the same `Idempotency-Key` header and the same signed webhooks, so the sections further down apply to either. They differ in how much of your account they cover. | | [API v1](/reseller-hub/api/api-v1.md) | [API v2](/reseller-hub/api/v2.md) | | ------------- | --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | | Made for | **Simple shop integrations**: provision a license at checkout, renew it, switch it off and on | **Deeper integrations**: your whole account, driven from your own systems | | Covers | 8 calls around one license: provision, read, update, renew, suspend, reactivate, cancel, auto renew | Licenses, customers, the purchase ledger and bills, an event feed, webhook and key management, sessions and tracks, stats, your team and inbox | | License model | A term that renews, or not | A license with an end date that you extend after each payment, with trials, holds and a 30 day reinstatement window | | Credentials | In every license answer | On their own call, with their own key scope | | Reading state | One license at a time | Lists with filters and cursors, CSV on request, ready-made roll-ups | | Events | 8 webhook event types | 40+ event types, a readable feed, webhooks per event type | | Errors | HTTP status plus a message | One body shape with a stable `code`, a request id and a link to its documentation | | Rehearsal | A sandbox that mirrors live | Plus a test clock per license, rehearsed connections and a bill preview | | Base URL | `https://reseller.rtkdata.com/v1` | `https://reseller.rtkdata.com/v2` | | Reference | [API v1](/reseller-hub/api/api-v1.md) and **API > Docs** | [API v2 guide](/reseller-hub/api/v2.md), [error catalogue](/reseller-hub/api/v2/errors.md) and **API > Docs**, generated from the API itself | **Choose v1** when all your shop has to do is hand a customer a license after checkout and keep it in step with their subscription. It is a handful of calls, the credentials come back in the provisioning answer, and the whole integration fits in an afternoon. **Choose v2** when the API should be the way you run your RTK business: your own customer records and references, licenses with an end date you control, every purchase matched against your monthly bill, connections and usage on your own dashboards, and an event feed your systems react to. v2 is the version RTKdata develops further. If you already run v1, it keeps working as it is. The [moving from v1](/reseller-hub/api/v2.md#moving-from-v1) section of the v2 guide tells you what changes when you switch. *** ## The API area **API** is your control room. Its header carries a **version switch**, v1 or v2, and the page below follows the version you pick. **v1** shows 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. **v2** adds a **Test / Live** toggle that applies to everything on the page, and splits the page into tabs: * **Overview**: tiles for calls, error rate, p95 latency, rate limited calls, pending operations, active keys, endpoints and events, a **Needs attention** list (failing endpoints, keys about to expire, keys unused for 90 days, calls refused by an IP allowlist, operations stuck for more than ten minutes), a **Go-live readiness** checklist that ticks itself off as you progress, and a **Docs and tools** card. * **Keys**, **Webhooks**, **Events**, **Requests**: one table each, described below. * **Test data**: everything your test keys created (customers, licenses, grants, devices, claim codes, extension requests), so you can check a rehearsal without a live key. **API > Docs** is the reference. For v1 it is the [API v1](/reseller-hub/api/api-v1.md) page in more detail, with a copyable curl example per call. For v2 it is rendered from the API's own OpenAPI document, so it can never drift from what the API does: a quickstart, the basics, every endpoint with its fields, a working curl and the errors it answers, the error catalogue and the event types. **Build with AI** on that page downloads the whole v2 reference as one Markdown file for your AI coding assistant. ![The API docs](https://3957820804-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJflLSSoC9TU9MkwT5lbC%2Fuploads%2Fgit-blob-2d73ddf6c14eb540e027599cb047d8ccfe710def%2Freseller-hub-shop-api-docs.png?alt=media) *** ## API keys **Keys** lists the keys issued to your account. Each one is either **Test** or **Live**; 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 data. Build against a test key, and switch to a **live key** (`rtk_live_...`) only when the flow works end to end. The two environments never mix: an id from the other environment answers 404. On the v2 page a key has more to it, and the same attributes apply when the key calls v1: | Attribute | Meaning | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Scopes** | What the key may do, one scope per area (`licenses:provision`, `bills:read`, `webhooks:manage`, ...). The form offers the presets **Read only**, **Provisioning** and **Full**. A key created on the v1 page carries every integration scope and none of the administrative ones (keys, team, webhooks, notification settings). | | **Principal** | Free text naming the system or person that holds the key, for your own records. | | **Expiry** | The key stops working at that moment. Pair it with **Rotate**. | | **IP allowlist** | Up to 50 CIDR entries. Calls from any other address are refused with `ip_not_allowed`, and the refusal shows up under **Needs attention**. | | **Rate limit tier** | 60 requests per minute by default. Higher tiers exist; RTKdata sets the ceiling your account may use. | | **Rotate** | Issues a successor with the same settings and a new secret. The old key keeps working for an overlap you choose (24 hours by default, up to a week), then expires. | Everything the key form does is also available through the API itself, under `/v2/api-keys`, so a key can be managed by your own tooling. *** ## Webhooks **Webhooks** registers the endpoints in your shop that should hear about what happens to your licenses, customers, bills and integration. Webhooks are shared by both API versions. * **Add endpoint** registers a URL, picks the **event types** it should receive (presets: the eight v1 types, all, none) and shows its signing secret once. Every delivery carries an `RTK-Signature` header, an HMAC-SHA256 over the delivery time and the raw body with that secret, so your handler can verify it came from RTKdata. * **Payload version** decides the shape of the body: `v1` carries the license as `GET /v1/licenses/{id}` returns it, `v2` the event envelope with the v2 object. Endpoints created on the v1 page are `v1`. * Each endpoint shows **Active**, **Failing** or **Off**, based on its recent deliveries and tests. Switch an endpoint off while you work on it; nothing is sent to it until you switch it back on. * **Send test** fires a `webhook.ping` event so you can verify your handler without a real order. * The row also has the delivery log (every attempt with the answer it got, and a **Retry** per delivery), **Roll secret** and remove. After a roll, the old secret keeps signing as well for 24 hours, so you can switch without a gap. The eight event types v1 integrations know are still there: `license.activated`, `license.updated`, `license.suspended`, `license.reactivated`, `license.cancelled`, `license.renewed`, `license.expiring` and `license.expired`. v2 adds the rest, from `license.created` and `license.converted` to `invoice.issued`, `account.past_due`, `session.started` and `webhook.failing`; see [events and webhooks](/reseller-hub/api/v2.md#events-and-webhooks) in the v2 guide. Answer every delivery with a 2xx within 10 seconds and do the work afterwards. A failed delivery is retried with growing pauses for about three days before the endpoint is marked **Failing** and you get a notification; a 4xx answer counts as a rejection and is not retried. 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, idempotency key and the request id the answer carried (`RTK-Request-Id`). Search by key, idempotency key or request id, and filter by environment, status (2xx, 4xx, 5xx) or endpoint. The v2 **Events** tab shows the other side: every event your account produced, with its payload. 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. Quote the request id when you contact support. *** ## Suggested integration order 1. Create a **test** key, with the v2 presets **Provisioning** or **Full** if you integrate v2. 2. Make a first call from your staging shop with a real idempotency key, and check the request history. 3. Register a webhook endpoint, pick its event types and use **Send test** until it reports **Active**. 4. Wire up the rest: for v1 `update`, `renew`, `suspend`, `reactivate`, `cancel` and `auto-renew`; for v2 `convert`, `extend`, `seats`, `end`, `suspend` and `reactivate`, driven by your payment, refund and return flows. 5. With a v2 test key, rehearse a whole license life in minutes with the [sandbox helpers](/reseller-hub/api/v2.md#sandbox-helpers): advance the clock, record a connection, preview the bill. 6. Create a **live** key with only the scopes your integration needs, give it an expiry or an IP allowlist, switch your production shop over, and revoke anything you no longer use. The **Go-live readiness** card on the v2 overview follows these steps and ticks each one off as your account reaches it. *** ## Next * [API v1](/reseller-hub/api/api-v1.md) - the simple shop integration: provision, update, renew, suspend, reactivate, cancel * [API v2 guide](/reseller-hub/api/v2.md) - the deeper integration: concepts, every endpoint, events, sandbox, moving from v1 * [API v2 error catalogue](/reseller-hub/api/v2/errors.md) - every error code and what to do about it * [Licenses & Provisioning](/reseller-hub/licenses.md) - the same lifecycle, done by hand * [Customer Portal](/reseller-hub/customer-portal.md) - where an API provisioned customer reads their credentials --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.rtkdata.com/reseller-hub/api.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.