Testing & the sandbox

TreasurySpring provides a sandbox environment so you can build and validate integrations without touching production data. This page covers how to get credentials, along with what the sandbox can and cannot do.

Getting sandbox credentials

Sandbox credentials are self-serve from the TreasurySpring portal:

1. Log in to the portal at https://portal.treasuryspring.com.
2. Navigate to Account Information → Developer Settings.
3. Generate a client_id / client_secret pair (Client Credentials grant) or request an authorisation-code-flow client.
4. Use those credentials against the sandbox base URL.

Base URLs

Environment	Base URL
Sandbox	https://api.sandbox.treasuryspring.com/api/v1
Production	https://api.treasuryspring.com/api/v1

OAuth token endpoints are at the root of each environment, not under /api/v1:

Environment	OAuth token endpoint
Sandbox	https://api.sandbox.treasuryspring.com/oauth/token
Production	https://api.treasuryspring.com/oauth/token

Exchanging credentials for an access token

cURL

Sandbox token exchange

curl --location 'https://api.sandbox.treasuryspring.com/oauth/token' \
  -H 'Authorization: Basic <base64(client_id:client_secret)>' \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'grant_type=client_credentials' \
  --data-urlencode 'client_id=<client_id>' \
  --data-urlencode 'client_secret=<client_secret>'

Python

Sandbox token exchange

import base64
import requests

basic = base64.b64encode(b"<client_id>:<client_secret>").decode()
resp = requests.post(
    "https://api.sandbox.treasuryspring.com/oauth/token",
    headers={
        "Authorization": f"Basic {basic}",
        "Content-Type": "application/x-www-form-urlencoded",
    },
    data={"grant_type": "client_credentials"},
)
token = resp.json()["access_token"]
expires_in = resp.json()["expires_in"]   # seconds until token expires

The response contains an access_token and an expires_in value (in seconds). Cache the token and refresh before it expires; tokens are not single-use.

What the sandbox is

• A separate API and database from production.
• Pre-loaded with representative entities, indications, holdings, and subscriptions so you can exercise every read endpoint.
• Functional for POST /subscribe — you can submit subscriptions and they'll be accepted into the sandbox's data set.
• Suitable for end-to-end client-flow testing of the call patterns (auth, request shape, response shape, error handling).

What the sandbox is NOT

Sandbox is a static numerical snapshot

The sandbox does not run TreasurySpring's daily processing pipeline. Practically, this means:

• Holdings do not mature in the sandbox. A holding with a maturity date in the past stays in its current status.
• Cut-off times do not fire. Issuance does not happen on a schedule.
• Subscriptions you submit are accepted but do not progress through Pending → Issued → CutOff → Redeemed automatically.
• Indications do not refresh — the same set of UIDs persists day-to-day, including for products that are re-issued daily in production.

If you need to validate the full lifecycle (subscribe → issue → roll, or split → adjust → redeem), please coordinate a test in a real (production-data) account with TreasurySpring.

Product minimums still apply

Product minimums apply in the sandbox as well as in production. A subscription with amount: 1 will be rejected for being below Indication.minimum, so please test with realistic amounts.

Which dataset for what use case

When bootstrapping a historical dataset, the choice of endpoint matters a little more in sandbox than in production:

Use case	Primary endpoint	Notes
Initial bulk load of current positions	GET/holding	Authoritative; paginated.
Initial bulk load of past subscriptions	GET/subscription	History of intent — terms may differ from the resulting holding.
Ongoing T+1 deltas	GET/event	Event stream is reliable from 2026-04-01 onward. For events older than that, use the holdings/subscriptions endpoints.
Historical security-master fallback	GET/indication/{code}	What was on offer to this entity.
Reference data (cells, obligors, calendar)	GET/cell, GET/obligor-exposure, GET/holiday/{year}	Mostly static.

A typical sandbox session

1. Exchange credentials for an access token (above).
2. Call GET/entity to discover entity codes available to this user.
3. Call GET/indication/{code} to see what products this entity could subscribe to.
4. Submit a test subscription via POST/subscribe.
5. Inspect GET/subscription for the resulting record.
6. Hit GET/holding for the existing holdings dataset — these are pre-loaded and will not change as a result of your subscription.

If you'd like a holding to actually mature for testing, please reach out to your account manager and we can arrange a controlled scenario.

Next steps

• Authentication — full OAuth grant-type reference.
• Errors & responses — what failures look like and how to recover.
• Quickstart — end-to-end walkthrough using the sandbox.