> ## Documentation Index
> Fetch the complete documentation index at: https://docs.spenza.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Getting Started

> Prerequisites, credentials, and configuring your environment before your first call.

## Prerequisites

* **A Spenza partner account.** The Partner API is provisioned per account by Spenza — self-serve signup isn't available yet. If you don't have an account yet, contact [support@spenza.com](mailto:support@spenza.com) or your Spenza account representative.
* **An API key and secret** for that account (see below).
* **An HTTPS client.** Any language that can make HTTPS requests and parse JSON works — the examples throughout these docs use cURL, JavaScript (`fetch`) and Python (`requests`).

<Note>
  **No sandbox environment yet.** Every example in this documentation targets `https://api.spenza.com` — the only base URL available for the Partner API today. A sandbox is planned; until it ships, confirm with your Spenza account representative before writing code against production if you expect a separate test environment. See **[Environments & Versioning](/environments-versioning)**.
</Note>

## Obtaining API credentials

Your API **key** and **secret** are issued by Spenza when your partner account is set up. They identify your account and are the only credentials you use to obtain a bearer token — there's no separate developer-portal signup step in this API.

Treat the secret like a password:

* Never commit it to source control or client-side (browser/mobile) code.
* Store it in a secrets manager or environment variable on your server.
* If you believe it's been exposed, contact Spenza support to have it rotated.

See **[Security & Best Practices](/security)** for more on credential handling.

## Environment configuration

Set your credentials as environment variables rather than hardcoding them:

```bash theme={null}
export SPENZA_API_KEY="your-api-key"
export SPENZA_API_SECRET="your-api-secret"
```

Every code sample in these docs assumes `SPENZA_TOKEN` holds a valid bearer token obtained from the exchange described below — treat it as a short-lived value you refresh, not something you export once and forget.

## Making your first API request

Every call starts by exchanging your key and secret for a bearer token:

```bash theme={null}
curl -X POST "https://api.spenza.com/api/v1.1/auth/token" \
  -H "Content-Type: application/json" \
  -d '{
    "key": "'"$SPENZA_API_KEY"'",
    "secret": "'"$SPENZA_API_SECRET"'"
  }'
```

## Verifying the response

A successful exchange returns `200 OK` with an access token and its expiry — the response fields are deliberately **snake\_case** (OAuth2-style), unlike every other endpoint in this API:

```json theme={null}
{
  "success": true,
  "data": {
    "access_token": "eyJhbGciOiJI…",
    "token_type": "Bearer",
    "expires_in": 3600,
    "expires_at": "2026-07-31T12:00:00.000Z"
  },
  "meta": { "timezone": "UTC" }
}
```

Save `data.access_token` and send it as `Authorization: Bearer <token>` on every subsequent request. Request a fresh token before `expires_at` passes — this endpoint doesn't currently document a separate refresh-token flow, so re-authenticating with your key/secret is the way to get a new one.

If you get an error instead, `success` is `false` and `error.code` tells you what went wrong — most commonly `UNAUTHORIZED` (bad key/secret) or `VALIDATION_ERROR` (key or secret omitted from the body). See **[Authentication](/authentication)** and **[Errors](/errors)** for the full picture.

## Next steps

* Walk through a complete integration in the **[Quickstart](/quickstart)**.
* Understand the envelope, pagination and async patterns in **[Core Concepts](/core-concepts)**.
* Browse every endpoint in the API Reference (sidebar).