Postman collection

Every SP endpoint, ready to send, with the idempotency key handled for you.

• Download the collection
• Download the environment

You need both files. The collection holds the requests; the environment holds your host, your token and the values the requests read.

The collection carries a build id. Open its description in Postman and the first line reads Spec 1.0.0 · build followed by eight hex characters. Quote that id in any support request: it tells us exactly which copy you are holding, which is otherwise the first thing we have to guess at. It changes when the requests change and at no other time, so re-downloading and getting the same id means you already had the current collection.

Postman will be refused from your laptop

Requests are checked against your registered source addresses before your credential is even considered, so a call from a laptop returns IP_NOT_ALLOWLISTED no matter how correct your token is.

Run the collection from a server whose public address is registered, or ask the operator team to register the address you are testing from. See IP allowlisting.

Setting it up

1. Import both files into Postman.
2. Select the Tornet SDP v1 environment.
3. Fill in four values:

Variable	Where it comes from
apiHost	The operator team. No host is published in these docs.
token	Your bearer token. Stored as a secret variable and shipped empty.
shortCode	The short code your credential is bound to.
serviceId	The service, as the number the operator team issued you.

4. Send Read whether a number is subscribed first. It changes nothing, and it exercises your token, your allowlisted address, your grant and your capability in a single call. If it succeeds, your integration is authorised and the rest of the collection will work.

msisdn, pin, ti, ts, te, flow, language and message are also variables, so you fill a value once rather than editing it in each request.

spTransactionId is generated for you

Every send gets a fresh one, before the request leaves Postman.

This matters because the API requires it to be unique per attempt. A static value in a saved request would work once and then return DUPLICATE_TRANSACTION_ID on your second click, which looks like a broken endpoint and is not.

To test idempotent replay deliberately, set replayLastTransactionId to true. The next send reuses the previous id, and you should get the original stored outcome back rather than a second operation. Set it back to false afterwards, or every subsequent send replays too.

What the tests tell you

Each response is checked against the envelope, and code and requestId are written to the Postman console first, because those are the two fields that resolve a support question. Keep the requestId: it points at a specific row in the platform's logs.

Three refusals that are commonly misread get an explicit note in the console:

• IP_NOT_ALLOWLISTED, with the reminder above.
• DUPLICATE_TRANSACTION_ID, which usually means replayLastTransactionId was left on.
• FRAUD_TRANSACTION_UNKNOWN, which is not a fraud decline: the ti was never registered by a script call, so retrying cannot help.

Two things the collection does not contain

Header enrichment. GET /he/v1/subscribe is a redirect the subscriber's browser follows, not a server-to-server call. Sending it from Postman proves nothing about your integration. See the redirect contract.

DataSync. Events are delivered to you, so there is no request to make. You stand up a receiver, verify the signature over the raw body before parsing, and acknowledge with any 2xx. For end-to-end testing the operator team can point a test short code at your URL and drive a real opt-in.

Keeping it current

The collection is generated from an OpenAPI description that lives in the documentation repository, and it is rebuilt on every deploy of this site. Re-download it after a changelog entry that adds or changes an endpoint, rather than editing your local copy: hand edits are lost on the next import.