Online Resources API

The Online Resources Integration API lets an author grant, review, update, and revoke access to their own restricted resources from a trusted server-side app.

Use HTTPS from a backend service. Do not call this API from browser JavaScript, ship a key in a desktop or mobile app, place it in source control, or share it with another person.

Create a Personal Key

Your Input Sense account must have both a linked Discord account and a verified email. Link them under Preferences → Account before managing integration keys. Recipients can use an Input Sense account without linking Discord.

Step Action
1 Sign in to Helios and open Online Resources.
2 Click the key icon beside Refresh, then choose Create.
3 Copy the key from the one-time display and store it in your service's secret manager.
4 Open one of your restricted resources, choose Manage Access, and copy its Resource ID.

An account has one personal integration key. A key expires after 365 days. Rotating or revoking it invalidates the old key immediately. If a key is exposed, rotate it before doing anything else.

Endpoint and Authentication

Send requests to:

text
https://www.inputsense.com/api/scripts/integration_v6.php

Authenticate every request with the complete key:

http
Authorization: Bearer YOUR_PERSONAL_INTEGRATION_KEY

The endpoint returns JSON and does not support browser CORS. POST requests require Content-Type: application/json; unknown fields and query parameters are rejected.

Routes

The route is supplied in the route query parameter. Replace {resource_uuid} with the Resource ID copied from Helios and {account_identifier} with either a 17–20 digit Discord ID or a 21-digit Input Sense ID. Users can copy their Input Sense ID from Preferences → Account. Keep all IDs as strings.

Method and route Purpose
GET items/{resource_uuid}/authorized-users List authorized users
GET items/{resource_uuid}/authorized-users/{account_identifier} Check one user's current authorization
POST items/{resource_uuid}/authorized-users Create an author-managed grant, or replace its notes and expiry if it already exists
POST items/{resource_uuid}/authorized-users/{account_identifier}/update Change notes or expiry on a manageable grant
POST items/{resource_uuid}/authorized-users/{account_identifier}/revoke Revoke a manageable grant; repeating a completed revoke is safe

For the list route, limit defaults to 250 and accepts 1–500. offset defaults to 0 and accepts 0–1,000,000. The single-user route does not use pagination.

Rate Limits

Each author account has separate rolling limits for authenticated integration requests:

  • authenticated GET requests: 600 per 5 minutes;
  • authenticated POST requests: 240 per 5 minutes.

API-key authentication is also limited to 420 attempts per 5 minutes per network address. Key status, create, rotate, and revoke actions inside Helios share a limit of 30 per hour per signed-in account.

Every authenticated request counts, including one that later fails route or body validation. Authentication attempts count whether the key is valid or not. A 429 response includes Retry-After and rate-limit headers; wait for the indicated interval instead of retrying rapidly.

Examples

List access records:

bash
curl --get 'https://www.inputsense.com/api/scripts/integration_v6.php' \
  --header 'Authorization: Bearer YOUR_PERSONAL_INTEGRATION_KEY' \
  --data-urlencode 'route=items/RESOURCE_UUID/authorized-users' \
  --data-urlencode 'limit=250' \
  --data-urlencode 'offset=0'

Check one user:

bash
curl --get 'https://www.inputsense.com/api/scripts/integration_v6.php' \
  --header 'Authorization: Bearer YOUR_PERSONAL_INTEGRATION_KEY' \
  --data-urlencode 'route=items/RESOURCE_UUID/authorized-users/12345678901234567'

For a registered, available account, this lookup returns has_access: true only for a current authorization. An expired authorization is returned with has_access: false and status: "expired". If that account has no authorization, the request succeeds with has_access: false and authorization: null. An unknown account returns 404; ask the user to sign in to the current Helios release and copy their ID again.

json
{
  "success": true,
  "request_id": "request identifier",
  "data": {
    "resource_uuid": "RESOURCE_UUID",
    "account_id": "123456789012345678901",
    "discord_id": "12345678901234567",
    "identity_id": "123456789012345678901",
    "has_access": false,
    "authorization": null
  }
}

When present, authorization includes account_id, nullable discord_id, identity_id, user names, authorization type, whether it is manageable, status, notes, expiry, and created/updated timestamps. identity_id is the Input Sense ID when available, otherwise the Discord ID. The list response contains authorized_users and pagination with offset, limit, total, and has_more.

Grant access:

bash
curl --request POST 'https://www.inputsense.com/api/scripts/integration_v6.php?route=items/RESOURCE_UUID/authorized-users' \
  --header 'Authorization: Bearer YOUR_PERSONAL_INTEGRATION_KEY' \
  --header 'Content-Type: application/json' \
  --data '{"discord_id":"12345678901234567","notes":"Customer order 1842","expires_at":"2027-01-31T18:30:00Z"}'

Update a grant:

bash
curl --request POST 'https://www.inputsense.com/api/scripts/integration_v6.php?route=items/RESOURCE_UUID/authorized-users/12345678901234567/update' \
  --header 'Authorization: Bearer YOUR_PERSONAL_INTEGRATION_KEY' \
  --header 'Content-Type: application/json' \
  --data '{"notes":"Renewed","expires_at":null}'

Revoke a grant:

bash
curl --request POST 'https://www.inputsense.com/api/scripts/integration_v6.php?route=items/RESOURCE_UUID/authorized-users/12345678901234567/revoke' \
  --header 'Authorization: Bearer YOUR_PERSONAL_INTEGRATION_KEY' \
  --header 'Content-Type: application/json' \
  --data '{}'

Request Rules

  • The grant body's field is named discord_id, but accepts either ID type as a JSON string. For example, {"discord_id":"123456789012345678901"} grants access by Input Sense ID. Do not rename the field to account_id.
  • All single-user routes require a registered, available account. A Discord ID must still be linked to that account; an Input Sense ID also works for an email-only recipient.
  • notes may be null or up to 1,000 Unicode characters without control characters.
  • expires_at may be null or an exact future UTC timestamp such as 2027-01-31T18:30:00Z, no later than 2038-01-19T03:14:07Z.
  • On the grant route, omitted notes or expires_at values are stored as null, including when replacing an existing grant. Use the update route when changing only one field.
  • An update body must include at least one of notes or expires_at.
  • Request bodies are limited to 16 KiB.
  • Access can be granted for resources you own that are Private, Locked, or awaiting review. An approved Public resource does not need an author-managed grant.
  • Only manual grants created by you are manageable. Purchases, gifts, administrative access, and grants managed by another source are protected from changes through this API.

Responses and Errors

Every response contains success and request_id. Successful responses place route data under data. An error has this shape:

json
{
  "success": false,
  "request_id": "request identifier",
  "error": {
    "code": "invalid_request",
    "message": "Description safe to show in an integration log"
  }
}

Handle 400, 401, 403, 404, 405, 409, 413, 415, 429, and 500. Keep the request_id with your logs, honor Retry-After when rate limited, and retry only when the operation is safe to repeat. A 404 can mean that the resource is unavailable to the authenticated author or the target account is not registered. A 409 can mean the account is unavailable, the resource is not restricted, the author already has access, or the grant is managed by another source.

New grants return 201; replacing an existing manageable grant returns 200. If upgrading an integration that used integration_v1.php, switch to integration_v6.php and create a current personal key in Helios. Keep both Discord and verified email linked while using the integration; if a key becomes invalid after account changes, check the key dialog before retrying.

Never log the Authorization header or full key.