Postman & OpenAPI

Import every endpoint into Postman, fill in one variable, and send a real request.

Import the collection

The collection is generated from the same openapi.yaml that these pages are checked against, so it describes the API that exists today — not a copy of it that fell behind.

Download collection Download OpenAPI

Postman imports a collection from a file or from a URL. The button above gives you the file — in Postman, Import and drop it in.

To import by URL instead, so that a re-import picks up changes: Import → Link in Postman, then paste:

text

/selanim-sms.postman_collection.json

Postman on the web can only reach a URL that is reachable from the internet. A collection served from your own machine, or from behind a VPN, has to go in as a file.

Importing the OpenAPI file instead

Postman accepts openapi.yaml directly (Import → Link → the same URL with /openapi.yaml), and so do Insomnia, Bruno, Hoppscotch and every client generator. What you lose by doing that is the setup below: the auth, the variables and the chaining are built into the Postman collection, not into the spec.

Add your API key

Open the collection, go to the Variables tab, and put your key in apiKey. Every request inherits Authorization: Bearer {{apiKey}} from the collection, so no request carries a key of its own and none of them needs editing.

Keys are created in the portal under Developer API.

Variable	Type	Description
`apiKey`required	string	Your key. Empty on purpose — a shipped placeholder just fails with invalid_api_key later.
`baseUrl`required	string	Defaults to https://bulksmsapi.selanim.com/v1. Change it to run against a local stack.
`messageId`	string	Written by “Send a message” from its response, and read by “Fetch one message”.
`contactId, groupId`	string	Written the same way by the requests that create a contact or a group.

Start on a test key

A sbs_test_ key runs the whole path — validation, sender ID checks, delivery webhooks — and bills nothing. Swap it for sbs_live_ once the requests do what you expect. See Authentication.

Environments

The collection works on its own. Environments are for keeping the key out of it — useful when the collection is shared with a team, or when you switch between production and a local stack without editing anything.

Production environment Local stack environment

Send your first request

Open Messages → Send a message, change to to your own number, and press Send. A 202 comes back with one message per recipient, and the test script on that request stores the first id so Fetch one message works straight afterwards.

Prefer the terminal? Postman exports any request as cURL from the code icon on the right, or start here:

bash

curl -X POST https://bulksmsapi.selanim.com/v1/sms/send \
  -H "Authorization: Bearer $SBS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "senderId": "SELANIM",
    "to": ["255712345678"],
    "message": "Karibu Selanim Bulk SMS!"
  }'

Sending is real

Requests from Postman are ordinary API calls. On a live key they reach handsets and debit your wallet, and there is no undo — a scheduled send can be cancelled, a delivered one cannot.

What is in the collection

Every operation in the contract, grouped the way the reference is. Requests with more than one documented example are imported once per example, so “Send a message” arrives as three: plain, personalised and scheduled.

Reading the collection…

Regenerating it

The collection is built by npm run postman in docs/, and again on every build. Edit openapi.yaml — never the JSON, which is overwritten.