RSX-DEV-01
Developing on
the platform.
Conditions for building on the RSX Platform. Covers API keys, rate limits, webhook delivery, RSX ID integration, AI Portal use, branding, security disclosure, and how we handle deprecation.
- Effective
- 10 August 2026
- Version
- 1.0
- Applies to
- Anyone using the API, webhooks, SDKs, or RSX ID
01Scope
1.1
These Developer Terms govern development on the RSX Platform: the API, webhooks, SDKs and client libraries, RSX ID integration, the AI Portal, and the documentation and sample code we publish for them.
1.2
They apply in addition to the Terms of Service and the Privacy Policy. Everything prohibited by section 5 of the Terms of Service is also prohibited here. Where this document is more specific about a developer matter, this document controls.
1.3
You accept these terms when you generate an API key, register an application, receive a webhook delivery, or call any RSX endpoint. Developer and “you” mean the person or organisation doing so; where you act for an organisation, you confirm you can bind it.
1.4
Application means any software, service, experience, bot, or script you operate that uses the RSX Platform. You are responsible for your Application, including code and infrastructure operated on your behalf by contractors or third parties.
02Access and credentials
2.1
Access is open. Any eligible account holder may register an application and generate keys through the ID Portal without prior approval, at no charge.
2.2
Access is revocable at our discretion. We may reduce, restrict, suspend, or withdraw your access to any endpoint, key, or feature, with or without notice, where section 14 applies. Open availability today is not a commitment to future availability.
2.3
Keys are secrets. Treat every API key, client secret, and signing secret as a credential:
- —use keys only from server-side code you control — never in client-side JavaScript, Roblox LocalScripts, mobile bundles, or anything shipped to end users;
- —never commit keys to a repository, paste them into a support ticket, issue, or chat, or embed them in a public asset;
- —use separate keys per application and per environment, so one can be revoked without breaking the others;
- —rotate keys promptly when a person with access leaves, or when exposure is suspected;
- —do not attempt to use a key issued to somebody else.
2.4
You are responsible for every request made with your credentials, including requests made by a third party who obtained them through your act or omission.
2.5
Report suspected key exposure to security@rsx.group without undue delay. We may revoke a key immediately, without notice, where we believe it has been exposed or is being abused — including where we detect it in a public source.
2.6
Requests must identify your Application through a stable, honest User-Agent including a contact address. Requests that are unidentifiable, or that misrepresent their origin, may be blocked.
03Rate limits and fair use
3.1
Endpoints are rate-limited. Current limits are published in the documentation and are communicated per response through rate-limit headers. Limits may change; treat the headers, not the documentation, as authoritative at runtime.
3.2
Your Application must handle limiting correctly:
- —respect HTTP 429 and honour Retry-After;
- —back off exponentially with jitter on 429 and 5xx responses, rather than retrying immediately or in a tight loop;
- —cap retries, and fail gracefully instead of queueing unbounded work;
- —spread scheduled work rather than firing every job at the top of the hour.
3.3
You must not spread requests across multiple accounts, keys, applications, IP addresses, or proxies in order to obtain more capacity than a single set of limits allows. Ask instead — see clause 3.5.
3.4
Even within published limits, usage must be reasonable in relation to what your Application actually needs. Polling an endpoint that has a webhook, requesting data you discard, or re-fetching unchanged resources are not reasonable use.
3.5
If you need higher limits, write to developers@rsx.group describing the use case and expected volume. We may grant, condition, or decline the request.
3.6
We may apply emergency throttling to protect the platform. Where we do, we will restore normal limits as soon as it is safe to.
04Permitted use of API data
4.1
You may use data returned by the API only to operate the Application you registered it for, and only for as long as you need it for that purpose.
4.2
Caching. Cache responses where doing so reduces load, but respect cache headers, do not serve stale data as current, and refresh or discard cached personal data at least every 24 hours unless the documentation states otherwise.
4.3
You must not:
- —build or maintain a general mirror, archive, or replica of RSX data;
- —resell, sublicense, or redistribute API data as a data product, feed, or lookup service;
- —combine RSX data with other sources to build profiles of individuals beyond what your Application needs to function;
- —use API data to train, fine-tune, or evaluate a machine learning model;
- —use the API to build a service that substitutes for, or directly competes with, the RSX Platform.
4.4
Delete API data when your Application stops using it, when a user disconnects from your Application, when we revoke your access, or when we ask you to because a user has exercised a deletion right.
4.5
Undocumented endpoints, fields, and behaviours are not part of the API. Using them is at your own risk and gives you no rights under the deprecation policy in section 13.
05Webhooks
5.1
Webhooks deliver platform events to an HTTPS endpoint you register. You are the controller of anything you receive and store from a delivery.
5.2
Your endpoint must:
- —be served over HTTPS with a valid certificate;
- —verify the delivery signature against your signing secret on every request, using a constant-time comparison, and reject anything that fails;
- —reject deliveries whose timestamp falls outside the documented replay window;
- —acknowledge with a 2xx status within the documented timeout, doing slow work asynchronously after acknowledging;
- —handle deliveries idempotently, keyed on the delivery ID, because retries and duplicates will occur;
- —tolerate events arriving out of order, and tolerate new fields being added to a payload.
5.3
An endpoint that fails to verify signatures is a security defect on your side. We are not liable for the consequences of acting on an unverified or forged payload.
5.4
Delivery is best effort. We retry failed deliveries with exponential backoff for the period stated in the documentation, then drop the event. We may disable an endpoint that fails persistently, is unreachable, returns errors at a sustained rate, or is slow enough to affect our delivery infrastructure. We will notify the registered contact where we do.
5.5
Do not use webhook endpoints for anything other than receiving RSX events, and do not register endpoints on infrastructure you do not control.
5.6
Rotate signing secrets when your team changes or exposure is suspected. Both the old and new secret remain valid during the documented overlap window.
06RSX ID integration
6.1
If your Application signs users in with RSX ID, you act as a relying party and must follow this section in addition to the documented authorisation flow.
6.2
Request the minimum scopes your Application needs, at the point you need them. Do not request scopes speculatively, and do not use data obtained under one scope for a purpose that would have required another.
6.3
Present the sign-in clearly and honestly. You must not:
- —obscure, restyle, or misrepresent the consent screen, or interpose your own screen that imitates ours;
- —make consent a precondition for unrelated functionality, or use dark patterns to obtain it;
- —ask users for their RSX password, session token, or two-factor code under any circumstances;
- —imply that RSX endorses, vouches for, or has reviewed your Application.
6.4
Handle tokens correctly: store access and refresh tokens encrypted at rest, never expose them to a browser or game client, never log them, and never share them between applications or with third parties.
6.5
Honour revocation. When a user disconnects your Application or an access grant is revoked, stop using the tokens immediately, delete them, and delete the personal data you obtained through them unless you have an independent lawful basis to keep it.
6.6
Do not use RSX ID as a way to determine a user’s identity for age verification, background screening, employment, credit, insurance, or any similar consequential decision.
07AI Portal
7.1
AI Portal inference runs on infrastructure we control. Prompts and outputs are not sent to third-party model vendors and are not used to train models. See section 5 of the Privacy Policy.
7.2
You are responsible for what you submit. Do not send credentials, payment details, special category personal data, or another person’s personal data that you have no lawful basis to process.
7.3
Output is generated automatically and may be wrong. Your Application must not present it as verified fact, and must not use it as the sole basis for moderation, enforcement, safety, financial, or legal decisions affecting a person. Where output influences such a decision, a human must review it first.
7.4
Where output is shown to your end users, disclose that it is AI-generated.
7.5
You must not resell raw inference capacity, expose the AI Portal as a general-purpose model endpoint to your own users, or use it to generate anything prohibited by clause 5.6 of the Terms of Service.
7.6
We may apply content filtering, quotas, and abuse detection to AI Portal traffic, and may refuse or truncate a request.
08Your Application and your end users
8.1
Your relationship with your end users is yours. You are responsible for your Application’s terms, its support, its security, and its compliance with law.
8.2
You must publish an accessible privacy notice that states, at minimum: what data your Application collects through RSX, why, how long you keep it, who you share it with, and how a user can request deletion.
8.3
Do not state or imply that RSX operates, endorses, secures, or is responsible for your Application, and do not direct your users to RSX support for issues with it.
8.4
If your Application is available to minors on Roblox, you are responsible for handling their data lawfully. RSX accounts and developer access remain restricted to 16+ under section 2 of the Terms of Service.
8.5
Keep an accurate technical and security contact on your registered application. We use it for breach notice, deprecation notice, and enforcement contact, and an unreachable contact is itself a ground for suspension.
09Data protection
9.1
Where we provide data about identifiable people through the API or webhooks, each of us acts as an independent controller for our own processing, unless we have signed a written agreement stating otherwise.
9.2
You must have a lawful basis for everything you do with that data, process it only for the purposes your users would expect, and apply the data minimisation and storage limitation principles.
9.3
You must apply appropriate technical and organisational security measures, including encryption in transit, encryption of credentials at rest, access control on a least-privilege basis, and logging sufficient to investigate an incident.
9.4
Incident notification. If you suffer a security incident affecting data obtained from RSX, or affecting RSX credentials, notify security@rsx.group without undue delay and in any event within 48 hours of becoming aware. Include what happened, what data and how many people are affected, what you have done, and your contact. This is in addition to your own regulatory notification duties.
9.5
Assist us within a reasonable period, and at your own cost, where we need your cooperation to answer a data subject request, a regulator, or a court order concerning data you received from us.
9.6
Do not transfer data obtained from RSX outside the EEA or the UK without a valid transfer mechanism.
10Branding and attribution
10.1
We grant you a limited, revocable, non-exclusive, non-transferable licence to use the RSX name and mark solely to state factually that your Application uses the RSX Platform.
10.2
Permitted: “Built on RSX”, “Powered by RSX”, and “Sign in with RSX” on the sign-in control, using the assets and clear-space rules in the brand documentation, without recolouring, rotating, distorting, or animating the mark.
10.3
Not permitted:
- —using RSX, Whitehill, or a confusingly similar name in your product name, company name, domain, social handle, or Roblox group name;
- —using our marks as your icon, avatar, or primary visual identity;
- —implying partnership, certification, official status, or endorsement;
- —using our marks in a way that suggests your Application is the RSX Platform itself.
10.4
The licence ends automatically when your access ends, or on notice from us. Remove our marks promptly when it does.
10.5
We may ask you to stop a specific use at any time. Comply within 14 days.
11Prohibited Applications
11.1
You must not build or operate an Application whose purpose or predominant effect is to:
- —harvest, aggregate, or resell data about Roblox users or RSX users;
- —monitor, track, or profile individuals, including minors, beyond what your Application's stated function requires;
- —collect RSX credentials, or imitate RSX sign-in, support, or moderation;
- —distribute cheats, exploits, or tooling that breaches the Roblox Terms of Use;
- —automate account creation, ban evasion, or the circumvention of moderation on any platform;
- —carry out scams, phishing, trading fraud, or unlicensed gambling;
- —mirror or proxy the RSX Platform for third parties, or resell access to it.
11.2
We may require changes to an Application that presents a material risk to users or to the platform, even where no clause above is squarely breached. If you decline, we may withdraw access.
11.3
We do not review or approve Applications. Our silence is not approval, and does not waive any breach.
12Security research and disclosure
12.1
We welcome good-faith security research and will not pursue legal action against researchers who stay within this section. Report findings to security@rsx.group.
12.2
In scope: systems on domains we operate, our public API endpoints, and our published client libraries. Out of scope: third-party services we use, applications built by other developers, findings that require physical access, social engineering of our staff or users, and reports generated by automated scanners without validation.
12.3
While testing you must:
- —use only accounts and data you own, or test data you created;
- —stop as soon as you have confirmed a vulnerability, and not pivot further into our systems;
- —not access, modify, exfiltrate, or retain anyone else's data — if you encounter it, stop and tell us;
- —not degrade the service: no denial-of-service testing, load testing, or spam;
- —not use a finding for any purpose other than the report.
12.4
Give us 90 days from acknowledgement before publishing, or longer where a fix reasonably requires it. We will confirm receipt within 5 working days, keep you updated, and credit you if you want to be credited.
12.5
We do not currently operate a paid bounty programme. Anything we offer is discretionary.
13Versioning, deprecation, and changes
13.1
The API is versioned. Pin your Application to a version and read the changelog before upgrading.
13.2
Additive changes are not breaking and may ship at any time. These include new endpoints, new optional request fields, and new fields in a response. Your Application must tolerate them.
13.3
Notice periods for changes we initiate:
| Change | Notice | Channel |
|---|---|---|
| Breaking change to a stable endpoint | 90 days where practicable, 30 days minimum | Email to the registered technical contact, plus changelog |
| Removal of a deprecated endpoint or version | 90 days from the deprecation notice | Email, changelog, and deprecation headers on responses |
| Change to rate limits or quotas | 30 days, unless applied as emergency protection | Changelog and response headers |
| Change to a webhook payload's existing fields | 30 days | Email and changelog |
| Change required for security or legal compliance | As much as is safely possible, possibly none | Email and changelog |
| Change to beta or preview features | None | Changelog where practicable |
13.4
We may update these Developer Terms. Material changes take effect 30 days after notice to your registered contact; continued use after that date is acceptance.
13.5
Where a change breaks your Application and you tell us within the notice period, we will make a reasonable effort to help you migrate. We are not liable for the cost of your migration work.
14Suspension of developer access
14.1
In addition to section 8 of the Terms of Service, we may restrict, suspend, or revoke developer access where:
- —your Application breaches section 11, or your use breaches sections 3 to 7;
- —your traffic threatens the stability of the platform, whether deliberately or through a defect;
- —your credentials are exposed, shared, or being used by an unauthorised party;
- —your registered contact is unreachable, or you do not respond to a security or compliance enquiry within 7 days;
- —your Application handles user data in a way that presents a material risk to those users;
- —you continue to call a removed or deprecated interface after its retirement date;
- —we are required to act by law or by a platform we depend on.
14.2
Where the risk allows, we will contact you before acting and give you a chance to fix the problem. Where it does not — active abuse, an exposed key, an ongoing incident — we will act first and explain afterwards.
14.3
Suspension may be scoped: a single key, a single endpoint, an application, or the whole account. We use the narrowest measure that addresses the problem.
14.4
Appeal to appeals@rsx.group under clause 8.5 of the Terms of Service.
15No warranty and no support commitment
15.1
The RSX Platform is provided as is and as available. There is no uptime commitment, no service level, and no guarantee that any endpoint will continue to exist. Do not build anything safety-critical on it.
15.2
Support is provided on a best-effort basis through developers@rsx.group and our documentation. No response time is guaranteed.
15.3
Sample code, SDKs, and snippets in our documentation are provided for illustration. You are responsible for reviewing and testing anything you deploy.
15.4
The disclaimers and liability limits in sections 10 and 11 of the Terms of Service apply in full to your development use.
16Termination
16.1
You may stop at any time: delete your keys, remove your webhook endpoints, and close your registered applications in the ID Portal.
16.2
On termination, by either of us, you must promptly stop calling the API, delete stored credentials, delete data obtained from the platform unless you have an independent lawful basis to keep it, and remove RSX marks from your Application.
16.3
Sections 9, 10, and 15, and any clause that by its nature should survive, continue to apply after termination.
17Contact
17.1
RSX is an unincorporated group operating from Silesia, Poland, under the Whitehill Group banner. Responsible operator: paige@rsx.group. Polish law governs, as set out in section 14 of the Terms of Service.
17.2
Developer support and limit requests: developers@rsx.group · Security and disclosure: security@rsx.group · Data protection: privacy@rsx.group · Legal: legal@rsx.group.