Validate connection

A cheap endpoint that returns your workspace metadata. Use it to validate an API key and workspace ID before doing real work. It is also what Make calls to render the connection chip.

Get current workspace

GET /api/v1/public/me

Authenticated with the X-Sender-Tenant + X-API-Key headers. It takes no path, query or body parameters.

The workspace is resolved from the API key, never from a value you send in a body. Two different keys pointed at the same URL return two different workspaces.

Response

object

Hide tenant

string

Workspace UUID. Stable, and accepted in X-Sender-Tenant.

string

Workspace slug, the public Workspace ID shown in the app. Also accepted in X-Sender-Tenant.

string

Workspace display name.

string

Raw plan key. One of unpaid, trial, free, c500, c1000, c2500, c5000, c10000, c15000, c25000, c50000, enterprise.

string

Raw workspace status. One of active, paused, suspended, cancelled.

string

The public API version this server speaks. Currently 2026-01.

plan and status are raw internal keys, not display strings. Do not string-match them for a user-facing label, and do not assume a numeric plan key maps to a contact allowance you can parse. New plan keys are added without a version bump.

curl https://api.senderz.app/api/v1/public/me \
  -H "X-Sender-Tenant: your-workspace-slug" \
  -H "X-API-Key: your-api-key"

const res = await fetch("https://api.senderz.app/api/v1/public/me", {
  headers: {
    "X-Sender-Tenant": process.env.SENDERZ_WORKSPACE,
    "X-API-Key": process.env.SENDERZ_API_KEY,
  },
});

if (res.status === 401) throw new Error("Bad workspace ID or API key");
const { data } = await res.json();
console.log(data.tenant.name, data.tenant.plan, data.apiVersion);

import requests

res = requests.get(
    "https://api.senderz.app/api/v1/public/me",
    headers={
        "X-Sender-Tenant": WORKSPACE,
        "X-API-Key": API_KEY,
    },
)
res.raise_for_status()
data = res.json()["data"]
print(data["tenant"]["name"], data["apiVersion"])

{
  "success": true,
  "data": {
    "tenant": {
      "id": "0f1e2d3c-4b5a-6978-8a9b-0c1d2e3f4a5b",
      "slug": "acme-store",
      "name": "Acme Store",
      "plan": "c5000",
      "status": "active"
    },
    "apiVersion": "2026-01"
  }
}

Errors

Credentials are checked before the handler runs, so every credential problem is a 401, whatever the cause.

Status	Message	Cause
`401`	`Missing tenant or API key`	Either header is absent or empty.
`401`	`Invalid API key`	The key is wrong, or `X-Sender-Tenant` does not resolve to a workspace.
`429`	Rate limited	See rate limits.

401

{
  "success": false,
  "message": "Invalid API key"
}

An unknown workspace reference and a wrong key return the same 401 Invalid API key, deliberately. The response does not tell you which of the two headers was at fault, so an unauthenticated caller cannot use this endpoint to discover whether a workspace slug exists. When debugging a connection, re-check both headers together.

Using it as a health check

GET /public/me is the right call for a connection test: it is a single indexed read, it mutates nothing, and it is safe to retry.

On credential entry

Call it once when a user pastes a workspace ID and key. A 200 proves both headers, so you never need a second validation call.

Read the version

Store apiVersion alongside the credential. If it changes, re-read the reference before assuming a response shape still holds.

Check the status

A workspace whose status is suspended or cancelled authenticates normally here, but marketing sends are frozen at the send pipeline. Surface the status rather than treating a 200 as “everything will send”.

Authentication

How to mint an API key and what the two headers accept.

Introduction

Ingest & transactional

Public API

Validate connection

Get current workspace

Response

Errors

Using it as a health check

Authentication

​Get current workspace

​Response

​Errors

​Using it as a health check

Authentication

Get current workspace

Response

Errors

Using it as a health check