Developer GuidesIntegration API

Integration API

Connect your own systems to Neostra with scoped API tokens. Reference for authentication, scopes, and the endpoints available for each module.

The Integration API lets your own software work with Neostra without a user signing in. A CRM can file a privacy rights request on behalf of a customer, a service desk can check where a request stands, and an automation platform can keep its records in step with Neostra. Every call is authenticated with a tenant API token that carries only the scopes you grant it.

The API is organised by module. Each module exposes its own set of endpoints and scopes under a common base path, authentication scheme, and response format, which are described first on this page. Endpoints for further modules are added over time under the same conventions.

The Integration API is available to tenants whose subscription includes the corresponding module. Tokens are managed by users with the Super Admin role.

Getting started

Base URL and versioning

All endpoints live under /api/integration/v1 on the host you use to sign in to Neostra. The examples on this page use https://<your-neostra-host> as a placeholder.

The path carries the API version. Within a version, new fields may be added to responses; your client should ignore fields it does not recognise.

Create an API token

API tokens are tenant-level credentials that represent your systems rather than a person.

Open API Tokens

In Neostra, go to Integrations > API Tokens and click Create Token.

Name the token and select scopes

Enter a descriptive name, for example "CRM privacy requests". Select the scopes the calling system needs and no more. Create one token per system so that each can be rotated or revoked independently.

Set an expiry

Optionally choose an expiry date. An expired token is rejected until it is replaced. Leave the field empty for a token that does not expire.

Store the secret

The secret is displayed once. Copy it into your secret manager immediately; Neostra stores only a hash and cannot display it again. If a secret is lost, revoke the token and create a new one.

The API Tokens page lists each token's name, a masked value, scopes, status, last used time, and expiry. Revoking a token takes effect immediately and cannot be undone.

Authentication

Send the token as a bearer token in the Authorization header on every request.

Authorization: Bearer neo_sk_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Content-Type: application/json

Token secrets begin with neo_sk_ followed by an environment label and a random component. Treat the entire string as the secret.

API tokens are distinct from user sessions. A user session cannot call the Integration API, and an API token cannot be used anywhere else in Neostra. Call the Integration API from your servers only. Never embed a token in browser code, a mobile app, or a public form.

Scopes

A scope grants access to a specific capability within a module. A token may hold any combination of scopes. Holding the scope is sufficient to call the endpoint; no additional user permission applies.

ModuleScopeGrants
Privacy Rights Managerintegration:subject-request:createSubmit a privacy rights request
Privacy Rights Managerintegration:subject-request:readRead the status of a privacy rights request

Response format

Every response uses the same envelope. On success, success is true and the payload is in data. On failure, success is false and errors lists one or more messages; validation errors name the offending field.

{
  "success": false,
  "message": "Error",
  "errors": [
    { "field": "requestTypes", "message": "List must not be empty" }
  ]
}
StatusMeaning
200The request succeeded
400The body failed validation or referenced an unknown resource
401The token is missing, malformed, revoked, or expired
403The token does not hold the required scope, the resource belongs to another tenant, or a subscription limit has been reached
404No resource with that identifier exists in your tenant
500An unexpected error occurred; retry later and contact support if it persists

Limits and behaviour

  • Idempotency: requests are not deduplicated by the API. Each successful create call produces a new record. If your client retries after a timeout, check the record's status first or deduplicate on your side.
  • Rate limits: no per-token rate limit is enforced today. Keep call volumes reasonable and poll for status no more often than your use case requires.
  • Subscription limits: records created through the API count towards the same allowances as records created in the application.
  • Auditing: every action performed with a token is recorded in the audit trail under the token's name.

Endpoints by module

The Privacy Rights Manager endpoints let you submit privacy rights requests on behalf of individuals and follow their progress. Requests created through the API enter the same intake, verification, and workflow process as requests submitted through a published intake form, and appear in the Request Queue alongside them.

MethodPathRequired scope
POST/api/integration/v1/subject-requestintegration:subject-request:create
GET/api/integration/v1/subject-request/{id}integration:subject-request:read

Submit a request

POST /api/integration/v1/subject-request

Creates a privacy rights request against one of your published intake forms. The form determines the brand, the request types available, the verification rules, and the workflows that will handle the request.

FieldTypeRequiredDescription
intakeFormIdstringYesIdentifier of the published intake form the request is filed against. See Finding identifiers.
requestTypesarray of stringYesIdentifiers of the request types being exercised, as enabled on that form, for example your Access or Erasure type.
userEnteredDataarray of objectYesThe form field values. Each item has a key, which is the field's label on the intake form, and a value, which is a string or an array of strings for multi-select fields.
userInfoobjectNoStructured identity of the individual: email, firstName, lastName, phone (an object with countryCode and phoneNumber), country, and state.
localestringYesLanguage code for emails sent to the individual, for example en. Use a language configured on the form.
emailstringNoEmail address of the individual. Verification and confirmation emails are sent to this address.
curl -X POST "https://<your-neostra-host>/api/integration/v1/subject-request" \
  -H "Authorization: Bearer <your-api-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "intakeFormId": "<intake-form-id>",
    "requestTypes": ["<request-type-identifier>"],
    "locale": "en",
    "email": "data.subject@example.com",
    "userEnteredData": [
      { "key": "Email", "value": "data.subject@example.com" },
      { "key": "First Name", "value": "Asha" },
      { "key": "Last Name", "value": "Rao" }
    ],
    "userInfo": {
      "email": "data.subject@example.com",
      "firstName": "Asha",
      "lastName": "Rao",
      "phone": { "countryCode": "+91", "phoneNumber": "9000000000" },
      "country": "IN",
      "state": "KA"
    }
  }'
{
  "success": true,
  "message": "Success",
  "data": {
    "id": "66c0a1f2e4b0a1b2c3d4e5f6",
    "status": "INITIATED",
    "requestVerified": false,
    "requestTypes": ["<request-type-identifier>"],
    "createdAt": "2026-06-18T09:41:12.318Z"
  }
}

Store data.id. It is the identifier used to read the request's status and the identifier shown in the Request Queue.

Read a request

GET /api/integration/v1/subject-request/{id}

Returns the current status of a request. Identifiers belonging to another tenant return 404.

curl "https://<your-neostra-host>/api/integration/v1/subject-request/<request-id>" \
  -H "Authorization: Bearer <your-api-token>"
{
  "success": true,
  "message": "Success",
  "data": {
    "id": "66c0a1f2e4b0a1b2c3d4e5f6",
    "status": "ACTIVE",
    "requestVerified": true,
    "requestTypes": ["<request-type-identifier>"],
    "createdAt": "2026-06-18T09:41:12.318Z"
  }
}
FieldTypeDescription
idstringRequest identifier
statusstringOne of INITIATED, ACTIVE, FULFILLED, REJECTED, ABANDONED, DUPLICATE
requestVerifiedbooleantrue once the individual has completed any required email or affidavit verification
requestTypesarray of stringRequest type identifiers on the request
createdAtstringCreation time in ISO 8601 format

Request lifecycle

A request submitted through the API follows the same path as one submitted through the hosted form.

  • When a selected request type requires email verification, or the form has affidavit verification enabled, the request is created with status INITIATED. Neostra emails a verification link to the individual, and the request becomes ACTIVE once verification is complete.
  • When no verification is required, the request is created as ACTIVE, workflows start immediately, potential duplicates are flagged, and a confirmation email is sent.
  • The request appears in Privacy Rights Manager > Request Queue under the form's brand and is handled like any other request. Workflow rules, including any Call API actions, run as usual, so you can receive status changes back through webhooks.

Finding identifiers

  • Intake form: open Privacy Rights Manager > Intake Forms, select the form, and open its Embed Script page. The public form URL ends with the form identifier.
  • Request types: Privacy Rights Manager > Request Types lists each type with its display name and identifier. Use the identifier, and only for types enabled on the chosen form.
  • Field keys: use the field labels as they appear in the intake form builder. Include every field marked as required on the form.

Notes

  • File attachments are not accepted through the API. Individuals can attach files through the hosted intake form where the form allows it.
  • The DELETION status may appear in older records and indicates a request whose data has been removed under retention.